**** BEGIN LOGGING AT Thu Jun 18 02:59:57 2020 Jun 18 11:32:55 m Jun 18 11:33:27 n Jun 18 12:58:02 I may have asked this before - does anyone know a nice aluminium case for the BBB that has about 2.5cm (1 inch) headroom for a cape? Jun 18 13:58:53 hello. How could i make the whole network services start AFTER everything else? Jun 18 14:01:30 i'm not getting how could i change the systemd service in etc, as there's .wants folder, and the network.service is mentioned in a lot of other files. Jun 18 14:28:43 Parduz: network.service does not do what you think it does Jun 18 14:28:57 why would you want to delay it anyway? generally you want networking up as early as possible Jun 18 14:29:36 'cause i don't need networking (often) and it slows down my app by 20 secs Jun 18 14:30:00 i mean, it takes 20 secs to ... run, or whatever it have to do Jun 18 14:30:44 oh wait I'm confusing network.service with network.target Jun 18 14:30:46 Hi, Can the BBB Image for sd Card to be used for USB bootable? Jun 18 14:31:14 i'm struggling to get the difference myself :D :D Jun 18 14:31:15 Parduz: network.service is for ifupdown I think? yeah ifupdown sucks, I don't use it myself for that reason: it slows down boot Jun 18 14:31:45 but normally on the bbb ifupdown only brings up the loopback interface since connman is used for the rest Jun 18 14:32:15 if you chose to use ifupdown for more than that, it's your own fault you now have slow boot :D Jun 18 14:32:18 Guest15998: no Jun 18 14:32:32 Guest15998: the BBB cannot boot from a usb drive Jun 18 14:32:52 no zmatt Jun 18 14:33:03 i don't even know what ifupdown do Jun 18 14:33:16 Parduz: can you please share the contents of /etc/network/interfaces ? (which is the config file for ifupdown) Jun 18 14:33:54 @zmatt, Thank you. Is there a prebuilt image to be downloaded for USB boot, and USB Flasher? Jun 18 14:34:29 Parduz: ifupdown is debian's old "network manager" (if you can call it that), a slow bunch of shell scripts to manage networking interfaces... slowly. Jun 18 14:34:54 Guest15998: which part about "the BBB cannot boot from a usb drive" was hard to understand? Jun 18 14:35:02 ok, the only uncommented lines are: allow-hotplug lo Jun 18 14:35:02 iface lo inet loopback Jun 18 14:35:21 zmatt: does enabling an interface once during boot need to be "fast"? Jun 18 14:35:22 and the iface USB0 inet Jun 18 14:35:23 Parduz: then it's not taking 20 seconds and you're probably misinterpreting something Jun 18 14:35:44 I mean, I've never seen those scripts take a noticeable amount of time Jun 18 14:35:45 Parduz: ah Jun 18 14:35:49 Parduz: so you _did_ modify it Jun 18 14:35:53 and now your boot is slow Jun 18 14:35:57 ? Jun 18 14:35:59 mru: I have Jun 18 14:36:16 do you have a million interfaces or something? Jun 18 14:36:25 Parduz: the usb interfaces are not configured in /etc/network/interfaces on the default beaglebone image Jun 18 14:36:46 those scripts are totally weird, but that's another matter Jun 18 14:37:14 .... i don't need it and i'm pretty sure i don't even be able to try something like this :) Jun 18 14:37:15 mru: no, last time I used ifupdown it seemed to synchronously block on dhcp, or until timeout if the link was down at boot Jun 18 14:37:47 oh, that's stupid Jun 18 14:38:30 mru: ifupdown _is_ stupid, it was the main motivation for me to switch to systemd-networkd and I've been very happy with it Jun 18 14:38:39 never looked back Jun 18 14:38:39 zmatt, Well. I created a USB bootable from a prebuilt image, it works for SD card, but not for USB. i.e. The same prebuilt image, I inserted in sd card slot with sd card, my BBBw is booted from SD, but if USB is inserted, it doesn't boot. Both cases, S2 is hold on. Jun 18 14:38:58 Guest15998: THE BEAGLEBONE CANNOT BOOT FROM A USB DRIVE Jun 18 14:39:03 I haven't used it much so I've probably not encountered the worst misbehaviours Jun 18 14:39:10 Guest15998: how hard is that sentence to understand? Jun 18 14:39:58 it doesn't matter what you put on a usb drive, bootrom does not have a usb host stack, it does not enable any usb host port, it will not look for or attempt to read a usb drive Jun 18 14:40:06 "traditional" debian looks almost as if it deliberately did everything poorly just to motivate the existence of systemd Jun 18 14:40:20 lol Jun 18 14:40:39 then again, the same could be said of redhad Jun 18 14:40:45 redhat Jun 18 14:41:14 Sorry, but menu says "BOOT modes: USB Boot... This mode supports botting from over USB port". What is exactly USB PORT? Jun 18 14:41:23 Guest15998: what menu? Jun 18 14:42:35 the only "usb boot" the AM335x supports is presenting itself as an RNDIS (usb networking) device/gadget on the usb0 port (the mini-usb port on the BBB), via which it will attempt bootp/tftp boot (same as Ethernet boot) Jun 18 14:42:56 needless to say, this has nothing to do with what most people understand as "usb boot" Jun 18 14:43:42 hello i am new to TI RTOS development and i want to ask that if i want to use the soft uart on the am335x pru do i have to use the BIOS ? Jun 18 14:44:03 amine88: TI RTOS is supported on their E2E forum (e2e.ti.com), not here Jun 18 14:44:16 for certain values of support Jun 18 14:44:26 okay thank you Jun 18 14:44:56 though I can say: I see no reason for using PRU as a soft-uart to require anything specific of the host OS Jun 18 14:45:20 well, commenting out that USB lines resulted in 20 secs faster boot Jun 18 14:45:21 well Jun 18 14:45:26 Parduz: lol Jun 18 14:45:28 the doccument: https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf in section 5.3.5 Boot Modes Jun 18 14:46:36 Guest15998: yeah they could have been clearer, although they do explicitly say in big red text that they do not support usb boot Jun 18 14:47:36 maybe the text should have been blinking and underlined as well Jun 18 14:47:52 wait TI's soft-uart uses McASP for I/O ... but why o.O Jun 18 14:48:11 how is that soft? Jun 18 14:48:15 Ok, I got you. But it's confusing to say USB Boot. Although it has USB port at the end. Jun 18 14:48:18 why would you still need pru? Jun 18 14:48:31 @zmatt: where could i share the analyze svg graph so i can ask to you to take a look at it? Jun 18 14:48:57 Parduz: that's a great question... I'm guessing it's too large for pastebin ? Jun 18 14:49:38 i'll try Jun 18 14:49:43 lol, or you could have googled "share svg" and clicked on the first hit: https://svgur.com/ Jun 18 14:51:53 https://svgshare.com/s/M8U Jun 18 14:52:11 I tend to restrain to link sites i don't know Jun 18 14:52:14 mru: I guess it might be tricky (but certainly not impossible) to have one pru do both uart tx and uart rx in pure software, and using mcasp to receive uart data needs continuous cpu time hence better to use pru than do it in C, I guess Jun 18 14:53:12 no fifo buffer? Jun 18 14:53:46 mru: you can use dma, but you still need to process all the received data to see if it contains a start bit Jun 18 14:54:29 Parduz: most of your startup time is caused by cape-universal Jun 18 14:54:42 and slow udev rules Jun 18 14:54:59 if your image is not super recent, make sure your bb-customizations package is uptodate Jun 18 14:55:16 since I fixed some udev rules a while back that was insanely slow (for no good reason) Jun 18 14:55:21 *that were Jun 18 14:55:35 ok Jun 18 14:56:29 it's bone-debian-9.9-iot-armhf-2019-08-03-4gb.img Jun 18 14:57:16 guess is not "super recent". Jun 18 14:57:57 I don't remember if it's recent enough. does /etc/udev/rules.d/80-gpio-noroot.rules say in a comment at the top it's been ReWritten ? Jun 18 14:58:10 (with that capitalization, for some reason) Jun 18 14:58:45 Hi, I built images based on the link: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian #Debian_Build_Instructions. And created SD card, but it doesn't boot from the SD. Jun 18 14:59:21 nope Jun 18 15:00:04 Parduz: then your bb-customizations is old and contains udev rules that are extremely slow, especially when cape-universal is enabled Jun 18 15:01:02 can i apt-get the updates, or have i to take a new images? i've done my share of customisations, here Jun 18 15:01:14 Parduz: you can update it with apt Jun 18 15:05:42 another thing that speeds up boot is disabling initramfs. to test this you can just move/rename the /boot/initrd.img-$VERSION image for your kernel out of the way and reboot. to make it permanent (keep it from being regenerated) you need to remove initramfs-tools, except you can't since rcn's kernel packages inexplicably have a dependency on initramfs-tools. my workaround has been to create an ... Jun 18 15:05:48 ...empty dummy initramfs-tools package with a version (1.0) that's much higher than the real initramfs-tools (0.133 in debian buster, 0.136 in debian sid): https://liktaanjeneus.nl/initramfs-tools_1.0_all.deb Jun 18 15:09:42 Parduz: replacing ifupdown+connman by systemd-networkd probably also helps Jun 18 15:10:52 disabling cape-universal and using an overlay instead probably helps, mainly by reducing the number of unnecessary devices (and the udev rules triggered by them) Jun 18 15:13:08 ok Jun 18 15:13:51 i remembered you warned me about the initframfs. I've renamed that file now, but without it the flashing script fails Jun 18 15:14:00 so i have to play with it Jun 18 15:14:36 ah yeah the flasher will require initramfs, truew Jun 18 15:15:18 i need to see if i can add something that rename the files before rebooting after flashing Jun 18 15:16:01 I use a different method of flashing myself, where the image to be flashed is just a file on the flasher card, instead of using the filesystem of the flasher itself as source Jun 18 15:16:17 the flasher card's filesystem is just something very minimal Jun 18 15:16:49 i'll try to do the same once this image will be promoted to "production" :) Jun 18 15:17:19 (which means "i'll be back " :D :D Jun 18 15:19:59 enable_uboot_cape_universal should be "=0" or the whole line commented? Jun 18 15:20:09 commented Jun 18 15:20:23 it looks at whether or not the variable exists, not its value Jun 18 15:20:29 i already have it commented Jun 18 15:20:47 how can be still active, then? Jun 18 15:21:07 maybe my assumption is wrong, not sure why else udev would be taking such a long time otherwise Jun 18 15:21:18 ok Jun 18 15:21:32 having, updating bb-customizations is still a good bet Jun 18 15:21:42 i'll try to update the bb-customization now Jun 18 15:22:36 sudo apt-get update && sudo apt-get install bb-customizations Jun 18 15:36:32 ok, done. Little question: is it normal that when i plug the usb-serial cable on the debug/log port, my serial (port 2) don't works anymore? Jun 18 15:37:45 I don't see generic-board-startup.service in your boot svg, so presumably you've disabled that to reduce boot time Jun 18 15:38:09 it's responsible for setting up the composite usb gadget (network/network/serial/mass-storage) Jun 18 15:39:00 wait maybe I misread yoru question Jun 18 15:39:11 uhh what Jun 18 15:39:18 I definitely misread your question Jun 18 15:39:42 in fact I think my eyes only read "usb" "serial" and "don't work" Jun 18 15:39:46 lol Jun 18 15:40:23 I have no idea then what you could possibly mean, there's not really any plausible mechanism for one serial port to be influencing another serial port Jun 18 15:41:20 ok Jun 18 15:41:29 i was wondering what your answer meant :D Jun 18 15:41:42 yeah ignore my first answer Jun 18 15:41:45 reading is hard apparently Jun 18 15:43:02 dunno how old you are, but in my case, can confirm :D Jun 18 15:44:43 not old enough for that to be a problem yet fortunately Jun 18 15:45:42 Good for you :) does booting from a 32GB SD changes a lot the booting time, or can i compare the previous times (from flash) with the current one from SD? Jun 18 15:46:07 booting from sd is much slower than booting from eMMC, regardless of size Jun 18 15:47:09 though for eMMC it'll depend a bit on the beaglebone, the eMMC chip used has changed over time and iirc the early ones were not that great performancewise Jun 18 15:48:40 k Jun 18 15:48:54 so, may i run the flashing script from the prompt, or i'm forced to edit the uEnv and reboot, to flash? Jun 18 15:51:08 not sure if it's safe to do from a booted system, it's definitely designed to be run from initramfs... the fact that it didn't work without an initramfs suggests to me it requires being run from initramfs Jun 18 15:51:28 you're right Jun 18 16:13:02 well, boot time is exactly the same :) Jun 18 16:13:17 before update http://svgur.com/s/M7v Jun 18 16:13:28 after update http://svgur.com/s/MAB Jun 18 16:19:03 well that at least confirms you have cape-universal disabled ;) Jun 18 16:19:46 so then the big question is, why does it take ages for udev to settle Jun 18 16:20:46 i'm listening to your thoughts Jun 18 16:31:21 btw out of curiosity I did some mmc read performance tests... https://pastebin.com/kVwDF1uy Jun 18 16:32:43 I know there are two other Kingstons in use, one older (Kingston KE4CN2H5A) which we don't seem to have at all and one newer which I don't have around right now Jun 18 16:33:54 the micron is around the same performance as a good sd card, the newer kingston is twice as fast Jun 18 16:34:46 (that's not an indictment of micron btw, it's just that the only micron eMMC devices you'll find on a BBB are really ancient ones) Jun 18 16:35:32 Parduz: I'm honestly not really sure how to debug this Jun 18 16:35:43 like, it's not normal for udev to take _that_ long to settle Jun 18 16:36:27 there's no way to add "log marker" to split that long time in "pieces"? Jun 18 16:40:02 there's probably some way to enable debug logging in udev Jun 18 16:41:44 try adding udev.log_priority=6 to your kernel parameters ("cmdline" in /boot/uEnv.txt) Jun 18 16:41:53 ok Jun 18 16:42:09 tomorrow i'll see Jun 18 16:42:09 or if that doesn't create enough spam in your log (journalctl), try setting the log priority to 7 Jun 18 16:42:12 thnx a lot Jun 18 22:37:31 zmatt: do I need to map before I write anything to memory using py-uio? Jun 18 22:37:45 not sure what memoryview means Jun 18 22:37:56 looking at your wiki Jun 18 22:39:22 MattB0ne: there are .write and .read methods you can use on e.g. core.dram or core.shared_dram, but mapping the memory using the appropriate ctypes type is usually the most convenient Jun 18 22:39:32 like I did in the example I gave Jun 18 22:39:35 depends on the situation I guess Jun 18 22:41:13 e.g. m.map( c_uint32, 0x00 ) where m is the memory, 0x00 is the offset in that memory, and c_uint32 is the type imported from the ctypes module Jun 18 22:41:33 I have to specify an offset for both but one I give the type does it make it faster Jun 18 22:42:14 then again length is similar to specifying the type I would do something like c_uint32*2 for a length Jun 18 22:42:30 so sort of type dependent Jun 18 22:42:45 c_uint32*2 is not a length, it creates an array-type Jun 18 22:43:08 (consisting of two 32-bit unsigned integers, i.e. being 8 bytes in size) Jun 18 22:43:43 what would be a length just saying 16 bytes Jun 18 22:43:54 but yeah, .read() accepts either a type or a length... but if you specify a length then you'll just get the raw bytes and need to decode it yourself Jun 18 22:43:57 16 Jun 18 22:44:13 m.read( 16, 0x00 ) would read 16 bytes from offset 0x00 Jun 18 22:44:18 in memory m Jun 18 22:44:37 ok so mapping would help since I am sort of casting what I would get or give to memory? Jun 18 22:45:07 mapping gives you direct access to the pruss memory, interpreted as the correct type Jun 18 22:45:08 sorry if this is dumb trying to make a dumb program to see if I got what is going on Jun 18 22:45:43 and read and write don't Jun 18 22:45:55 or it is the same Jun 18 22:45:58 just raw bytes Jun 18 22:46:02 that need to be processed Jun 18 22:46:03 so if counter = core.dram.map( c_uint32, 0 ) then any time you read counter.value you'll read from pru memory, any time you write to counter.value you write to pru memory Jun 18 22:46:17 aaaahhhh Jun 18 22:46:23 ok ok Jun 18 22:46:53 so the object returned by map actually represents a chunk of pru memory Jun 18 22:47:11 ok I am on board Jun 18 22:47:15 it gives you direct access to pru memory, but using the correct data type (a 32-bit unsigned integer) Jun 18 22:48:19 core.dram.read( c_uint32, 0 ) would also give you an c_uint32 object, but it'll be a _copy_ of the value in pruss memory, taken at the moment of .read() Jun 18 22:48:36 ok Jun 18 22:51:59 actually never mind, .read( c_uint32, 0 ) returns the value as integer Jun 18 22:52:28 but if you replace c_uint32 by a more complicated type like a struct or an array then what I said is true, lol Jun 18 22:52:55 I forgot that read(0 doesn't return a ctypes object if it's a "simple" type Jun 18 22:53:41 one more quick one the significance of you naming a file __init__.py Jun 18 22:53:48 that's basically also how ctypes itself works: if you have a struct containing a c_uint32 field then reading that field gives you an int, not a c_uint32 object Jun 18 22:54:00 __init__.py is basically the python code for that directory Jun 18 22:54:39 so if you import foo.bar then it's looking for foo/bar.py or foo/bar/__init__.py Jun 18 22:55:28 ok Jun 18 22:55:43 I thought I knew python until I looked at this code Jun 18 22:55:44 lol Jun 18 22:56:07 heh, which part? Jun 18 22:56:12 py-uio didn't _that_ complex I think? Jun 18 22:56:15 *isn't Jun 18 22:56:26 well from your lofty perch it may seem that way Jun 18 22:56:33 it's my first python project Jun 18 22:56:52 so I didn't really know much python yet... I still don't feel like I know much python Jun 18 22:56:53 it is not horrendous just way more elegant Jun 18 22:57:17 I mean, I rty Jun 18 22:57:18 try Jun 18 22:58:30 oh and if you don't understand what src/uio/__init__.py does... don't worry, neither do I. but it's apparently good for you, like broccoli Jun 18 22:59:16 iirc it has something to do with being a workaround for something about python's module system sucking, but I don't really remember the details, or possibly I never understood them Jun 19 01:21:43 time for some BELA and the ole BBB! Jun 19 02:18:32 Makin' tunes! **** ENDING LOGGING AT Fri Jun 19 02:59:57 2020