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.dtswhat 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.dtsThis 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#L150There 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