remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

I have the same problem as this user: https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) and doesn't seem to detect the PRUs on boot.

This is a fresh install of Sretch IOT from beagleboard.org, with the kernel and cape-overlays updated through the tools/scripts...

version.sh shows:

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 2018.09-00002-g0b54a51eee]:[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>]

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 weston-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.302485] remoteproc remoteproc0: wkup_m3 is available

[    1.389525] remoteproc remoteproc0: powering up wkup_m3

[    1.389661] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168

[    1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up

dmesg | grep pru

dmesg | grep pinctrl-single

[    0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

dmesg | grep gpio-of-helper

[    0.984114] gpio-of-helper ocp:cape-universal: ready

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

END

What am I doing wrong here? Surely PRU support is one of those things that should be working out of the box with the correct u-boot overlay applied?

[Hugh Frater]

Anybody? I would really like to complete a migration to Stretch and 4.14 due to the awesomeness of uBoot overlays and the pre-built overlay-root setup that is available from a setting in uEnv.txt, that's a big help for my project.

[Hugh Frater]

Thought I would try zero-ing the eMMC boot partition, just in case there was a resident uBoot that was old and didn't support overlays.... no joy :(

On Thursday, 9 May 2019 12:31:27 UTC+1, Hugh Frater wrote:

[Walter Cromer]

Hugh - I'm a real newbie.  I compiled a device tree overlay with not errors and have a dtbo file now.  I just don't know how to get it into the boot process.  Where do I put it, do I need to change a file like env.txt somewhere to get it to load and if so what syntax do i use?  Where did you find these instructions?  I'm so lost and need to keep moving forward.  it was going so well...

I'm on 4.4.14 

[Jim F]

There are some obvious places in /boot/uEnv.txt.  If it doesn't load though, usually the only way you can debug is to hook up a serial console to UART0 because uboot loads before kernel logging starts. 

--
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/205e5464-ada4-4a7b-9133-7461c75adb14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hugh Frater]

Hi Walter, I'm afraid I can't help with your custom device overlay issue, it us really a topic for a new thread in the uBoot section I would have thought?

I would be interested in hearing how you compiled a custom device tree overlay though. We have our BBB on a custom card that uses a bunch of gpio, an eqep module, a bunch of uarts and some pru_ecap pwm - it's a lot of work for config-pin to setup at boot time and I'd like to trim this 13 seconds of work out of my bootup if possible. Perhaps you could make a post in the uBoot section?

Hugh

[Walter Cromer]

Hugh - I'll dig around in the UBoot section.  Thanks for suggesting that.  I'm such a newbie on here!

As for how I compiled the custom device tree overlay, I followed the instructions posted at this location and it worked fine - no errors after I corrected the typos, etc. that were posted in the comments.

http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/

I'd really like to get this temperature sensor working but all the instructions are pre-Uboot.   I can make a lot of progress with my prototype once I get this working but liquid temperature is a critical input so without it I can't move forward!

[Hugh Frater]

If you can live with using the universal-cape and just configuring the pins once booted using the config-pin utility, that's a good way to go. What programming language are you wanting to use to write your temperature sensor software? If you are doing it from the PRU then you can just code up your own i2c read function and access the registers directly though the memory map, just like any standard MCU. 

[Hugh Frater]

An update - tried switching my 8.9/4.4.54-ti-r93 setup (that we have working with kernel overlays) over to uBoot overlays - all good...

[   37.211677]  remoteproc1: powering up 4a338000.pru1

[   37.212435]  remoteproc1: Booting fw image am335x-pru1-fw, size 129436

[   37.240836] ti-pruss 4a300000.pruss: configured system_events = 0x00000000000c0000 intr_channels = 0x0000000a host_intr = 0x0000000a

[   37.246313]  remoteproc1: remote processor 4a338000.pru1 is now up

[   37.261296] virtio_rpmsg_bus virtio0: rpmsg host is online

[   37.261377] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1f

[   38.227474] rpmsg_pru rpmsg0: new rpmsg_pru device: /dev/rpmsg_pru31

No idea why the PRUSS driver doesn't power up the PRU under Stretch/4.14.whatver

Now to see if I can get overlayroot working on 8.9/4.4 and sort out the read-only filesystem

On Thursday, 9 May 2019 12:31:27 UTC+1, Hugh Frater wrote:

[Walter Cromer]

I plan to write the code in C since I'm most familiar with it (although very rusty, but it's coming back) and I have considered learning Python and using it.

By the way, thanks to all for your patience with me on this!  It has been a long time since I worked in this space and a lot has changed and improved!

[Hugh Frater]

Our application is node.js for the easy stuff with all the heavy lifting done in the PRU... if you want to code in C, it's worth looking at the MRAA libraries from Intel https://github.com/intel-iot-devkit/mraa

[jonre...@gmail.com]

Same issue here.

# ls /sys/class/remoteproc/

remoteproc0

Anyone figure this out yet?

[Hugh Frater]

I think it is related to uboot overlays. I started a new thread over in the uBoot section... You might like to take a look over there, Robert has posted an image for me to try but perhaps you can test it for me? I'm currently sd-card-writer-less...