Hi again,
I have some mature PRU firmware that I’ve been loading and starting by having a program 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. 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
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
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.
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, 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, so that speeds things up.
The third possibility is that on the good advice from someone on the Beagle IRC channel, I disable initramfs. 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
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.
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
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.