I can't say for sure about why I'm enjoying faster load times now, but I have three guesses.
One possibility is that I finally arranged some candles in a ring, sat in the middle, slipped into a hypnagogic torpor, and in an echoing dissociative void managed to utter yet another arcane device tree overlay <https://github.com/stepleton/cameo/blob/master/aphid/firmware/PB-CAMEO-APHID.dts>, this time for my own application. It seems possible to me that when the PocketBeagle loads this device tree overlay on boot, some more complicated and time-consuming facilities of its default hardware setup are disabled, allowing it to attend to other setup tasks faster. This is purely a guess; my memories of that time are hazy and indistinct and whenever I try to recall them my mouth tastes of metal. (just kidding it wasn't that bad at all, but even now I'm not really sure I got it "right") The second possibility is that I'm as ruthless as I know how to be about disabling services I don't use in my application <https://github.com/stepleton/cameo/blob/master/aphid/setup_trim_services.sh>, so that speeds things up. The third possibility is that on the good advice from someone on the Beagle IRC channel, I disable initramfs <https://github.com/stepleton/cameo/blob/master/aphid/setup_trim_misc.sh>. This one really does seem to shave off quite a few seconds from boot time for me. I'm talking about boot time here---I haven't measured time-to-availability for the PRUs, but so far it hasn't been a problem and it's definitely much faster than it was. Either way, I'd be thrilled to collect yet further tips and tricks for making my gizmo start up even sooner! But for setup and installation of this magic, I do want people to be able to just run some shell scripts like the ones I've linked above --- recompiling the kernel would not be an option for me, for example. --Tom On Thursday, March 4, 2021 at 3:49:47 PM UTC rpau...@gmail.com wrote: > I'm trying to do something similar. It would be better, at least in my > case, if the PRU could be started at boot. One thing I noticed in my case > is the pruss doesn't show up until about 30 seconds into the boot cycle. > Yours seems to be detected much faster. Did you change something, or have > any idea when the kernel decides to discover it? I have tried to create a > systemd unit to start them, but I find myself trying to start them before > sysfs is populated. > > On Monday, February 1, 2021 at 7:08:32 PM UTC-5 Tom Stepleton wrote: > >> Oops, nevermind --- I see that it can't be done for now. On boot, or in >> other words during startup or power-on, the Debian Linux kernel on your >> PocketBeagle or BeagleBone Black can load rproc (aka remoteproc) PRU >> firmware such as am335x-pru0-fw and am335x-pru1-fw from /lib/firmware, but >> it will not start the firmware. (Yes, I am keyword-stuffing for maximum >> searchability.) >> >> >> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/remoteproc/pru_rproc.c?h=ti-android-linux-4.19.y#n1173 >> >> I'll try to identify other means of getting the PRUs started quickly; >> maybe something that systemd can run at boot time. >> >> Apologies for the distraction, >> --Tom >> On Monday, February 1, 2021 at 4:09:40 AM UTC Tom Stepleton wrote: >> >>> Hi again, >>> >>> I have some mature PRU firmware that I've been loading and starting by >>> having a program >>> <https://github.com/stepleton/cameo/blob/master/aphid/profile.py#L262> >>> manipulate the files >>> /sys/class/remoteproc/remoteproc[12]/(state|firmware) >>> well after the system has booted. >>> >>> I'd like to speed that process up, so today I've finally copied my >>> firmware files to /lib/firmware/am335x-pru0-fw and >>> /lib/firmware/am335x-pru1-fw . Now, I did do >>> sudo update-initramfs -uk `uname -r` ; sudo reboot >>> like you're supposed to. I can even do >>> zcat /boot/initrd.img-4.19.50-ti-r20 | cpio -itv >>> and see my firmware files inside the file (albeit as >>> /usr/lib/firmware/am335x-pru[01]-fw). >>> >>> When the PocketBeagle boots, the firmware is listed correctly within >>> /sys/class/remoteproc/remoteproc?/firmware files, it's just that the >>> neighbouring "state" files show that both PRUs are "offline". I can echo >>> "start" into those files and things work fine, but as I'm trying to >>> accelerate the time from boot to a running system, it would be really nice >>> if the firmware could start automatically on boot, as quickly as possible. >>> >>> I'm using this firmware in concert with a new device tree overlay I've >>> also been developing, which is the subject of another thread >>> <https://groups.google.com/g/beagleboard/c/Ro2PioeoN-c/m/Cd2d0YRGBAAJ>. >>> If you like, you can view it at >>> >>> http://mg-1.uk:31132/pb-cameo-aphid.dts.txt >>> >>> Perhaps something is missing in there? I based some of its design off of >>> information in https://groups.google.com/g/beagleboard/c/lS8QlNV8JCc , >>> which to be fair is now a healthy 3.5 years old... >>> >>> Thanks for any help, >>> --Tom >>> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e029aba0-ff8c-463f-8db6-d2826baaa046n%40googlegroups.com.
