The big time waster for me appears to be networking.service. I do not have totally resolved what to do, so at the moment I start the interface manually. There seems to be something wonky with ifup and hotplug -- I think it is related to "udevadm settle"). I was pretty draconian with the generic-board-startup, but that only seemed to save a little outside starting networking.
On Thu, Mar 4, 2021 at 2:04 PM Tom Stepleton <steple...@gmail.com> wrote: > 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 rpau...@gmail.com 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 <step...@gmail.com> 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 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 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 >>> beagleboard...@googlegroups.com. >>> 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 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 > beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/c097d95a-45d8-4b8f-b1d6-ce8df0e20d2an%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/c097d95a-45d8-4b8f-b1d6-ce8df0e20d2an%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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAA_M65PP9dPppTL2yrVROLYPvx7u2Ed%3DhnHOiUFVmJwdXj0B1A%40mail.gmail.com.
