[BBB] PRU using uio on recent kernels - update

This forum is for supported devices using an ARMv7 Texas Instruments (TI) SoC.

[BBB] PRU using uio on recent kernels - update

Postby Zeno » Fri Jun 19, 2020 3:55 pm

Hello all,
after some time I made an upgrade to latest version and found out some changes in kernel, that broke support for old uio_pruss way as I originally described here: viewtopic.php?f=48&t=13752
The reason is that the pruss hwmod is completely gone from omap definitions here: https://elixir.bootlin.com/linux/v5.7.3/source/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
this causes wrong initialization of pm_runtime_enable and pm_runtime_get_sync inside of uio_pruss module probe part. There is no easy way to add back pruss hwmod, so when this pm_runtime part is ommited, we are left with semi-initialized pruss, uio structure is mapped, but module is off (without clock), any acces to PRUSS module address space results in error like:
$this->bbcode_second_pass_quote('', '
')Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f6f000
pgd = 3ba88b52
[b6f6f000] *pgd=99680831, *pte=4a320303, *ppte=4a320a33

After analyzing clock activity, (via /sys/kernel/debug/clk/clk_summary), pruss-ocp-clkctrl:0000:0 clock was left disabled (in BBB devicetree pruss-ocp-clkctrl@e8, CPU mem address 0x44E000E8). Therefore, extension/tweak of uio_pruss to enable this clock instead of original pruss_ocp_gclk solved this problem. For anyone interested, look in the attached zip with sources of modified uio_pruss module.
Have a nice day and stay safe in these times.
Zeno
Attachments
uio.zip
uio and uio_pruss dkms modules
(11.95 KiB) Downloaded 596 times
Zeno
 
Posts: 14
Joined: Wed May 03, 2017 5:00 pm

Re: [BBB] PRU using uio on recent kernels - update

Postby summers » Mon Jun 22, 2020 7:19 pm

What happens if you do it the standard way? In /boot/boot.txt after
$this->bbcode_second_pass_code('', 'echo fdt: ${fdtfile}
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
gpio set 55')
add
$this->bbcode_second_pass_code('', 'fdt addr ${fdt_addr_r}
load ${devtype} ${devnum}:${bootpart} 0x88060000 /lib/firmware/uio_pruss_enable-00A0.dtbo
fdt resize ${filesize}
fdt apply 0x88060000
fdt resize
')
If the uio pruss clashes with the hdmi, then you need to disable that first, there is another overlay in /lib/firmware you can load first to do that.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: [BBB] PRU using uio on recent kernels - update

Postby Zeno » Tue Jun 23, 2020 12:36 pm

Hello,
well, that is the problem all the time, so, to elaborate a bit more with you, I believe this is the dts of uio_pruss_enable-00A0.dtbo:
https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/uio_pruss_enable-00A0.dts
what it does, it simply enables the pruss module. Last time pruss module was present in default beaglebone device tree (with status="disabled") was somewhere around branch 4.1, at that time only this uio_pruss_enable overlay was enough, this was because of RCNelson patches to am33xx.dtsi (which is part of final am335x-beaglebone.dtb), see this patch for example (search content for pruss):
https://rcn-ee.com/deb/sid-armhf/v4.1.1-bone9/
I was not looking too far, but 4.2 and later patches do not include this pruss module patch anymore. So when the default am335x-boneblack.dtb does not have pruss module definition, we would also need to load AM335X-PRU-UIO-00A0.dtbo overlay, its sources:
https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/AM335X-PRU-UIO-00A0.dts
This overlay is not working for me for a long time, I even can not decompile it (fixup errors etc.), so therefore I put together pru_uio_cape-00A0.dts (in attached zip). What more, after the evolution to linux 4.16 or so (near end of 4 branch), there was some change in kernel (ti-sysc appeared) and there was also quite a change to DT structure/semantics (maybe just dtc tool changed?) and pruss ceased to work due to different reset methods in ti-sysc (or something like this). Therefore it was necesarry to create/add that syscon reset controller - I tried to discuss this in my first topic regarding pru uio. So this overlay I prepared combines AM335X-PRU-UIO and kind of uio_pruss_enable with the addition of syscon reset controller. One more thing, uio and uio_pruss modules are not available in recent linux-am33x kernels by default either, that was also a part of the purpose of my previous topic, attached zip contains dkms versions of both of them - you need to add them externally anyway. Hope it makes more sense now. (just for info, uio_pruss kernel module is paired via K/V: compatible = "ti,pruss-v2"; tag in DT, also need to mention https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-am33x/PKGBUILD where you can see RCNelson's and other patches applied to kernel sources in the build process)

So far, so good, here comes this update topic, because in 5.7 kernel branch, the pruss hwmod is completely gone from kernel sources (nothing related in patches), so whether you include AM335X-PRU-UIO-00A0.dtbo or that one I put together, it makes no difference, you should get some errors regarding missing hwmod and the module is not initialized via "standard" way as we were used to. Just for info, last occurence of pruss hwmod is here:
https://elixir.bootlin.com/linux/v5.6.19/source/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c#L150
There you can see rst lines and other definitions which play role in HW initialization, hence you get stuck at that unhandled fault when trying to use PRU. Uio_pruss kernel module is still loading properly because of compatible tag, that works well. In spite of this, I found the problem with pruss clock staying disabled (via devmem and clk_summary), only minor change to pruss_uio probe clock initialization from my previous topic solved this, so there is a new working version in the first post attachment for anyone interested.

Regarding the hdmi and other modules, I am using u-boot to remove what i do not need before loading my overlay, like this:
$this->bbcode_second_pass_code('', '
fdt rm /ocp/interconnect@44c00000/segment@200000/target-module@10000/scm@0/pinmux@800/nxp_hdmi_bonelt_pins
fdt rm /ocp/interconnect@44c00000/segment@200000/target-module@b000/i2c@0/tda19988@70
fdt rm /ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
fdt rm /ocp/interconnect@44c00000/segment@200000/target-module@10000/scm@0/pinmux@800/mcasp0_pins
')
instead of loading another several overlays to acomplish this. So, sure, pru_uio_cape-00A0.dts provided from the zip is more of a stub, I usually add another GPIO/PWM/ADC/timer configurations and other stuff as needed for specific BBB aplications (which are mainly static from HW point of view anyway). This way I have only one overlay which I care about and modify, also lot of things could be optimalized easily such as boot time (removal of cape_eeproms +4s for example), less resources/modules loaded (i2c's, spi's, sound, lcdc) etc. basically anything you don't need. Downside is, that one has to study main devicetree and am335x processor a bit. Hope this helps and have a nice day.
Zeno
Zeno
 
Posts: 14
Joined: Wed May 03, 2017 5:00 pm

Re: [BBB] PRU using uio on recent kernels - update

Postby summers » Wed Jun 24, 2020 1:03 pm

Thanks for the background. Yes that makes some sense.

The beagle family, its strong point was its capes, originally done by capmgr - but this all had to change when device tree came along. But I hoped things had settled. So its a pity that the kernel has changed so hardware can't currently be used.

Did you check who made the change in the kernel? Maybe ask them the reason, and how the beagle family should access the PRU.

Oh yes -I also take out the hdmi be hand, I ended up with something somewhat different to you:

$this->bbcode_second_pass_code('', ' fdt addr ${fdt_addr_r}
# take out the framer
fdt rm /ocp/i2c@44e0b000/tda19988
# disable the lcdc and remove its pins
fdt set /ocp/lcdc@4830e000 status "disabled"
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/nxp_hdmi_bonelt_pins
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/nxp_hdmi_bonelt_off_pins
# disable the sound and remove pins
fdt set /ocp/mcasp@48038000 status "disabled"
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/mcasp0_pins')

This seems to be the patch that removed it: https://github.com/torvalds/linux/commit/bce967290977fc54c619f4165b8c40b809f44ed9#diff-b2e1656d1e4cfdb1edfb6c84e8255b3d
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: [BBB] PRU using uio on recent kernels - update

Postby Zeno » Wed Jun 24, 2020 4:25 pm

Yes, you found that exact commit, so as the description says, DT was changed in favor of ti-sysc infrastructure. That somehow agrees to what I wrote earlier.

Recently, If I am not mistaken, people should use RPMsg:
https://processors.wiki.ti.com/index.php/RPMsg_Quick_Start_Guide
I think that this is why UIO pruss method was abandoned. On the other hand, I have a lot of good working PASM code written for PRUs and other methods to communicate between PRU<->CPU which I still intend to use, it satisfies my needs, the architecture is simple and clear, that's it. This is also the reason why I put this "workaround" topics together and off course, there could be others in the same situation as me...

Regarding the capemgr, I understand that it is nice modular system, but i think its more for hobbyists than real applications. For example when you use BGB as AM335x prototyping platform and then switch to some more "industrial" solution, like this https://www.variscite.com/product/system-on-module-som/cortex-a8/var-som-am33-cpu-ti-am335x-am3354-am3352/, then available capes are not usable anymore...
Have a nice day.
Zeno
Zeno
 
Posts: 14
Joined: Wed May 03, 2017 5:00 pm


Return to Texas Instruments (TI)

Who is online

Users browsing this forum: No registered users and 5 guests