This thread is a followup to my post over in the PRU section. Tl;Dr - latest stretch IOT image using 4.14.108-ti-r104 wouldn’t enable the PRUs when I un-commented:
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
I attached a serial debug header and have managed to get the PRU overlays to load correctly and configure the PRUs by fudging uEnv.txt thus:
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
However, this gives rise to the following problem:
uboot_overlays: cape universal disabled, external cape enabled or detected…
And I really need to use cape-universal. So, my questions:
-
How come the uBoot overlay for the PRU-RPROC support doesn’t work?
-
How can I get uBoot to load the PRU-RPROC overlay and the overlay for cape-universal?
Cheers all…
let's see the output of:
sudo /opt/scripts/tools/version.sh
Regards,
Hi Robert, I'm no longer in front of the hardware for today but you can see the output of version.sh on my thread over in the PRU section. You can also see I tried zero-ing out the mmc in case that had a version of uboot that didn't support overlays. Didn't make a difference.
So, it's actually working for me, that's why i'd like to see what the
current output is.. might be the bootloader...
Mine:
Interesting that it works for you... Might be something to do with our 50Hz wall power 
I'll get back on this when I'm in work tomorrow and I'll try updating the bootloader and get you a fresh output from version.sh
OK, back in the office…
I’ve tried updating the bootloader, that didn’t make a difference. Here is the output from version.sh
debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
eeprom:[A335BNLT00C03816BBBK190D]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g9ca2c5819f]:[location: dd MBR]
kernel:[4.14.108-ti-r104]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk we
ston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep remote
[ 1.302439] remoteproc remoteproc0: wkup_m3 is available
[ 1.390494] remoteproc remoteproc0: powering up wkup_m3
[ 1.390611] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[ 1.393154] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[ 0.971836] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[ 0.983805] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
I’m booting from a micro-sd card and the device is an element 14/farnell BBB
I will try this and report back Robert. I need to get hold of another sd card adapter tomorrow, the card reader in my laptop has decided to stop mounting cards rw… 
I had the same issue on my BBBW:
ls /sys/class/remoteproc/
remoteproc0
I flashed the new image to an SD, then booted from SD. From there I checked:
ls /sys/class/remoteproc/
remoteproc0 remoteproc1 remoteproc2
Next I removed the line from /boot/uEnv.txt so that the new image would flash to BBBW and rebooted. As expected the lights cycle while flashing. However, when I rebooted without SD card BBBW is bricked with all LEDs on.
Any idea what’s going on?
I'm not sure, sounds like the flashing of eMMC wasn't successful. I have a new SD card writer so I will try this image this evening and report my findings...
Flashing your test image to a fresh SD card leaves me with the same behaviour as before Robert. My uEnv.txt follows:
debian@beaglebone:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.14.108-ti-r104
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Ov
erlays
###Master Enable
enable_uboot_overlays=1
This is what I think is relevant from my uBoot console:
U-Boot SPL 2017.03-00002-gd12b1519b4 (Mar 14 2017 - 10:28:26)
Trying to boot from MMC2
U-Boot 2017.03-00002-gd12b1519b4 (Mar 14 2017 - 10:28:26 -0500), Build: jenkins-
github_Bootloader-Builder-532
There you go!! Would you please give me a dd copy of the first 100Mb
of the eMMC partition.. Such that i can use it to update the
version.sh script, to detect this bad version...
Regards,
I will get that sorted and put it on my dropbox. I’ve got to flash eMMC with the sd card contents then reboot with another sd card in the USB-A port - I’m working from home and don’t have any cables other than a 232r on the debug header and a 5v power brick.
Give me half an hour…
Damn… accidentally overwritten uBoot on the eMMC… I thought the flasher wouldn’t touch that. Apologies Robert.
However, it was obviously a uBoot on eMMC problem as with a freshly flashed eMMC the overlay loads properly. I’ll try booting from SD card now and see if that works too,. In our application we use a bunch of the eMMC pins for other hardware so we’re forced to use an SD card.
You should run the flasher with a serial console connected to the debug header, that way you can monitor exactly what is going on. My attempts at flashing the latest image Robert posted was successful.
Robert, is it ok to use this image in production or should I use the current stretch IOT image and flash the eMMC to overwrite this old bootloader?
Okay I managed to get everything working too. I had to do the following steps:
-
reset eMMC
sudo /opt/scripts/tools/developers/update_bootloader.sh
-
flash new image provided above
-
After that the model from /opt/scripts/tools/version.sh was wrong for me. I’m using a BBBW but model field had just regular beaglebone black in it. This prevent wifi (via connman) from working. I followed another post about this (https://groups.google.com/forum/#!topic/beagleboard/_ydry5HYVNQ) which suggested to reset eeprom:
GND TP1 then run as root:
dd if=/opt/scripts/device/bone/bbbw-eeprom.dump of=/sys/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050/eeprom
reboot.
Everything works fine now!
Thanks Robert and Hugh
Good to hear that it is working for you… It’s detecting PRUs for me now when booting off the SD card - I just need to get them to start my code and setup /de/rpmsg_31 properly… another hurdle but I’m sure I will overcome.