PRUSS not working
Closed this issue · 6 comments
The PRUSS is no longer working. This regressed somewhere between 3.8.6 which worked and the current HEAD of 3.8.
During boot the following error is shown:
[ 0.129598] omap_hwmod: pruss: failed to hardreset
After that, uio_pruss cannot load.
This happens if you have &pruss { status="okay"; } in the bone DTS or if by loading a cape with cape manager.
Related thread: https://groups.google.com/forum/?fromgroups=#!category-topic/beagleboard/gqCjxh4uZi0
Jacek found a work around will get uio_pruss to load OK, no idea why this works though:
export slots=/sys/devices/bone_capemgr.7/slots set -x modprobe uio_pruss sleep 2 rmmod uio_pruss sleep 2 echo cape-bone-nixie > $slots sleep 2 modprobe uio_pruss sleep 2 echo cape-bone-nixie > $slots sleep 2 rmmod uio_pruss sleep 2 modprobe uio_pruss sleep 2
I don't now how it works either, I found it by trying different combinations of module and overlay loads and unloads. Even though it enables PRUSS, it is not safe. Any attempt to unload the cape-bone-nixie overlay will crash the kernel. Please see https://groups.google.com/d/msg/beagleboard/gqCjxh4uZi0/PcbPbt1F2TUJ for more information.
I found the source of the problem. The specific error is:
[ 6.059403] pruss_uio 4a300000.pruss: No children
which happens when the uio_pruss driver is loaded. The pru/004 replicape patch introduced this error. It returning ENODEV from probe() when there are no children of the pruss DT block (which there are none with the shipped DTS.) It looks like it is trying to suppose reserving GPIOs for PRU use in the DT. Rolling back this patch causes uio_pruss to start working again.
Proposed fix: Either modify the patch to handle the no children case or move this GPIO reserving feature somewhere else.
Chris, nice catch finding this bug, because that is what it is. Sorry for introducing this. I was looking for a way to mux pins based on adding a cape that required the PRU. Obviously it should not be necessary to mux pins for the PRU and it should gracefully continue if "there are no children". You were going to submit a pull request that fixes this?
I was in process and Koen beat me to it with this commit, moving the patch out.
Confirmed fixed with the patch removed.