Nice! I'm at 21 seconds until all of my code is up and ready to serve, of which 1-3 are probably accounted to getting the ARM-side Python code running (so not relevant to booting). Are you doing anything to speed things up that hasn't been mentioned so far?
I find that for me, the PRUs are ready to go with firmware loaded well before the Python code issues them the "start" command. --Tom On Thursday, March 4, 2021 at 6:53:00 PM UTC [email protected] wrote: > Hmmm. I have boot time to just under 14 seconds, but the PRUs are not > available until 30! I have looked with interest at the device tree you > posted, and I may adapt to my application. Until I trimmed the boot time, > I did not realize the PRUs were slow -- with a 45 second boot time, they > were always available. Something seems to be going on, but so far it is > invisible. Thanks. > > On Thu, Mar 4, 2021 at 1:39 PM Tom Stepleton <[email protected]> wrote: > >> 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 [email protected] 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 a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/PFINhbWs-ao/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/e029aba0-ff8c-463f-8db6-d2826baaa046n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/e029aba0-ff8c-463f-8db6-d2826baaa046n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c097d95a-45d8-4b8f-b1d6-ce8df0e20d2an%40googlegroups.com.
