I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem: uio_pruss is not configured in as it is with 4.14. Is this an oversight? Is there anyone I need to contact to try and convince them to re-enable uio_pruss? I’d like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi’s and BBB’s, but that’s really minor. uio_pruss is a must-have.
The ti kernels also don’t have it, but I cannot use the ti kernels due to other timing reasons. Mostly concerned about the bone kernels right now.
Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
notice and mention it!
Roger @ TI with comments from David posted an RFC for ti's remotproc
for mainline.. That's what i have in v4.19.x-bone "today" (and
v4.20.x-bone/v5.0.x-bone)..
Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all
uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module
to v4.17.x) and it should work fine..
Does this mean it’s something that is being worked on to be fixed for an upcoming 4.19 kernel update or are UIO folks completely SOL and stuck on 4.14 kernels?
No idea… I’ve never tried building a kernel for the BBB’s. I’ve always just relied on the the update_kernel script providing a usable kernel. For the most part, you guys have done a great job providing kernels that works for us (or have fixed things we’ve run into real quick). The lack of uio_pruss is the first real issue that I’m concerned about.
The dummy snd device is just “useful” cause a boot time, we can detect if there isn’t a sound device and load the module. Then the rest of the app can assume there is a sound device available and things “just work”. It’s mostly just a nice to have.
I cannot use the TI kernel as the cpu idle state driver in the TI kernel really screws up the GPIO0 timing. The bone kernels don’t have the idle states so GPIO0 timing is much more consistent. At some point, I’d like to dig through the TI kernel stuff to see if there is a way to completely turn off the cpu idle driver, but haven’t had the time. I’ve used the cpupower to turn off the various cpuidle states and that helped 95% of the time, but it’s still not as predictable as with the bone kernel.
So why don’t you just ask Robert to add CONFIG_SND_DUMMY to both the older -ti and -bone kernels as we are still using 4.14 for stable stuff for now due to this sort of breakage? A message about the breakage to linux-omap would really be helpful.
I’ve forward-ported the uio-pruss driver to the 4.19 kernel series, and cleaned it up a bit in the process. I’ve done a quick test on beaglebone black and on beagleboard-x15 (both pru instances), including that irqs work.
Only the first patch is needed on beaglebone, the second one is beagleboard-x15 specific. The third patch enables uio-pruss in the base dts, which you’ll need for beagleboard-x15 but on beaglebone you can also just use the AM335X-PRU-UIO overlay instead.
Many thanks for digging through this… once this is available in a kernel I can install via “update_kernel.sh”, I’d be more than happy to test my UIO based apps and such.
#0 0xb5ac6ffc in __pruss_detect_hw_version () from /usr/local/lib/libprussdrv.so #1 0xb5ac717e in __prussdrv_memmap_init () from /usr/local/lib/libprussdrv.so #2 0xb5ac74b8 in prussdrv_open () from /usr/local/lib/libprussdrv.so
so it looks like something is behaving differently or is laid out in memory differently or something. Not sure.
I just realized that enabling it in the base dts for beaglebone using a remoteproc-pru compatible structure was probably a bad idea… While it is safe to apply the remoteproc-pru overlay on top of it (albeit pointless since it hasn’t been ported to 4.19 yet), applying the uio-pruss overlay on top of it would create a mess.
Assuming you have the UIO-PRUSS overlay enabled, try disabling it.
OK, shame on me for just testing everything works on bbx15 and merely checking the devices show up on beaglebone and assuming they work. They really didn’t. I had overlooked that the ti,deassert-hard-reset DT property is a non-standard thing added by the original uio-pruss patch. A better solution would be to have the uio-pruss driver deassert the reset directly, just like the pruss_soc_bus driver does, but since I don’t have time to persue that right now I’ve simply added that patch back in.
I’ve also dropped the patch that enables uio-pruss by default on beaglebone, and restructured the dts patches in general. The patch set is now:
0001: uio-pruss driver itself
0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also needed for remoteproc-pru)
0003: add support for ti,deassert-hard-reset (needed for uio-pruss on am335x)
0004: outline dts declarations for pruss (can be dropped when full declarations are added for remoteproc-pru)
0005: dtsi files for enabling uio-pruss (for convenience of #including by those who want it)
0006: enable uio-pruss by default on beagleboard-x15 (feel free to drop, but seemed better than nothing until remoteproc-pru works)
and I’ve moved them to patches/drivers/ti/uio_pruss.
Hopefully this makes the patchset acceptable to merge as-is (or optionally dropping the last patch if you feel it is a bad idea).
Tests confirmed working on beaglebone-black:
am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam
py-uio/pru-examples/intc-test.py (pruss1 and pruss2)
py-uio/pru-examples/ddr-ping.py (pruss1 and pruss2)
I should caution that the libprussdrv examples look pretty broken. The PRU_industrialEthernetTimer example doesn’t actually work (it doesn’t wait 10s like it was supposed to) and after fixing the most obvious bugs (TICKS written to wrong memory, shared memory access not volatile-qualified) it seems to hang forever. The remaining two examples use /dev/mem to access a part of DDR3 memory that’s not actually reserved for use by pruss (instead of using libprussdrv’s API to access the ddr3 memory that is reserved for pruss), and will therefore probably clobber some kernel memory.
I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem: uio_pruss is not configured in as it is with 4.14. Is this an oversight? Is there anyone I need to contact to try and convince them to re-enable uio_pruss? I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor. uio_pruss is a must-have.
The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons. Mostly concerned about the bone kernels right now.
Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
notice and mention it!
Roger @ TI with comments from David posted an RFC for ti's remotproc
for mainline.. That's what i have in v4.19.x-bone "today" (and
v4.20.x-bone/v5.0.x-bone)..
I have been mostly focussing on remoteproc framework and PRU ethernet driver use case.
I see that uio_pruss is important for the bone community. We will need
to work together to make sure that it continues to operate when the
PRUSS remoteproc stuff gets merged to kernel.org.
I will keep you all in cc when I post v3 of the series so you can
test uio_pruss.c and review the patches.
Meanwhile, I'd like to understand what must be done to ensure uio_pruss.c
is supported. We might need to make some changes to uio_pruss.c
so that it can understand the device tree node (interrupts, memory regions)
and do runtime_pm etc. It will be great if we don't have to make any
device tree changes when switching between pruss_remoteproc and uio_pruss
drivers. Just unbinding the current driver and binding the alternate driver
should work.
Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all
uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module
to v4.17.x) and it should work fine..
I see that uio_pruss is important for the bone community. We will need
to work together to make sure that it continues to operate
Fortunately uio_pruss is a pretty simple driver that’s easy to forward-port.
Meanwhile, I’d like to understand what must be done to ensure uio_pruss.c
is supported. We might need to make some changes to uio_pruss.c
so that it can understand the device tree node (interrupts, memory regions)
and do runtime_pm etc. It will be great if we don’t have to make any
device tree changes when switching between pruss_remoteproc and uio_pruss
drivers. Just unbinding the current driver and binding the alternate driver
should work.
Adding ti,pintc-offset = <0x20000>; to &pruss should suffice to be able to switch between the two drivers (by changing “compatible” in the DT or by rebinding at runtime). It might even be nice to add both drivers to the compatible-property of &pruss to make it automatically fall back to uio-pruss if remoteproc-pru is disabled in kernel config or blacklisted as a module. All the child nodes inside &pruss are simply ignored by the uio-pruss driver.
I think if the pruss_soc_bus is driver is used then it’ll take care of deasserting the hard reset, so the ti,deassert-hard-reset property (and the kernel patch that introduces it) wouldn’t be needed. I haven’t tested this though. On the other hand if you want the same DT to work even if pruss_soc_bus is disabled in kernel config or blacklisted as a module, then you can add “simple-pm-bus” as fallback to the compatible-property of &pruss_soc_bus and add the ti,deassert-hard-reset = “pruss”, “pruss”; property to it. I don’t think adding this property messes up the actual pruss_soc_bus driver, but that would need to be double-checked.
For the beagleboard-x15 I also add a “pruss-instance” property to each pruss instance containing its name (“pruss1” or “pruss2”) to allow udev rules to create convenient symlinks.
Something isn’t working the same as it used to.