Re: [beagleboard] service that starts at boot can't use PRU - uio_pruss unavailable

[John Allwine]

I figured it out. The problem wasn't timing with the service, it was problems with an old version of U-boot on a different board than I had been testing with. I updated U-boot (like I had to do on my testing board) and it all works now. 

That said I still don't fully understand the problem. Where is U-boot stored? I'm booting from a microSD card and using that card in one board works, but didn't when I switched to this other board. Does it not pull that data from the microSD card? Is it reading from the eMMC of the other board?

On Fri, Apr 2, 2021 at 2:00 PM John Allwine <jo...@pocketnc.com> wrote:

I have a systemd service that is supposed to run a program on the PRU using uio_pruss. The service has an After=generic-board-startup.service.  It fails to run with the following error:

ERROR: executing '/sbin/modprobe uio_pruss'  11 - Resource temporarily unavailable

Is there something else I should set the service to start after? What is the recommended way to wait for uio_pruss to be available?

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4e8c42d0-f959-48d3-9148-d6a03cc62bd2n%40googlegroups.com.

[Dennis Lee Bieber]

On Fri, 2 Apr 2021 14:36:51 -0600, in gmane.comp.hardware.beagleboard.user
John Allwine <john-/83Ax2S01hhWk0Htik3J/w...@public.gmane.org> wrote:

>That said I still don't fully understand the problem. Where is U-boot
>stored? I'm booting from a microSD card and using that card in one board
>works, but didn't when I switched to this other board. Does it not pull
>that data from the microSD card? Is it reading from the eMMC of the other
>board?

As I understand the process... Unless the boot-select button is held
down, recent images (mid-Jessie time-frame I believe) contain a u-Boot that
checks for the uSD card. So...

Without boot-select, the u-Boot on the eMMC is loaded. It then checks
for the presence of the uSD card, and then for a bootable system on that
card. If such is found, the uSD card is made primary and booting
/continues/ using the files found on the card. u-Boot is still the version
from the eMMC.

With the boot-select, the eMMC is completely bypassed and the uSD card
is made primary, and u-Boot searched for on the uSD card. If found, it is
loaded and continues booting using the uSD card.

I'm not certain of when the "u-Boot loads device tree" vs "kernel loads
device tree" change took place. If it was after the auto-uSD card boot
change, one has the potential to have an eMMC u-Boot that expects the
kernel to load device tree, while the kernel on the uSD expected u-Boot to
load them (or if the uSD card is old enough, an eMMC u-Boot that does load
device trees, running a kernel that expects to read the device tree files).

Periodic flashing of the eMMC with current images is probably
recommended, just to ensure the u-Boot image is up-to-date (and cleaning
out crud that might have accumulated on the eMMC <G> )


--
Dennis L Bieber

[Drew Fustini]

It does come up on the list often that an old u-boot on the eMMC can
cause problems even when using the latest image on micro SD.

If people just want to run from microSD, then Robert normally
recommends people delete u-boot on the eMMC:
sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k

regards,
drew

[Drew Fustini]

I should note that it is important to make sure you are using the
correct mmc device for the eMMC. mmc1 may not always be the emmc.

-Drew