prussdrv_open open failed when trying to open the PRU
Closed this issue · 7 comments
Maybe something wrong with kernel modules?
this is a diff between lsmod on the previous 4.4.61(working) and the current 4.4.62 (not working)
$ diff mods-working.sorted mods-not-working.sorted
2,4d1
< arc4 2192 2
< bluetooth 511098 2
< cfg80211 509824 3 mac80211,wl18xx,wlcore
6,16c3,4
< ip_tables 14546 3 iptable_filter,iptable_mangle,iptable_nat
< iptable_filter 1850 0
< iptable_mangle 1849 0
< iptable_nat 2125 0
< libcomposite 53229 14 usb_f_acm,usb_f_ecm,usb_f_rndis
< mac80211 603653 2 wl18xx,wlcore
< nf_conntrack 108839 3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
< nf_conntrack_ipv4 17226 1
< nf_defrag_ipv4 1869 1 nf_conntrack_ipv4
< nf_nat 18076 1 nf_nat_ipv4
< nf_nat_ipv4 6608 1 iptable_nat
---
> ip_tables 14546 0
> libcomposite 53229 8 usb_f_rndis
20d7
< rfkill 21235 6 cfg80211,bluetooth
33,35c20
< tilcdc 31016 0
< u_ether 13682 2 usb_f_ecm,usb_f_rndis
< u_serial 13102 3 usb_f_acm
---
> u_ether 13682 1 usb_f_rndis
39,40d23
< usb_f_acm 8036 2
< usb_f_ecm 10981 2
42,45c25
< wl18xx 99732 0
< wlcore 227162 1 wl18xx
< wlcore_sdio 8686 0
< x_tables 20194 3 ip_tables,iptable_filter,iptable_mangle
---
> x_tables 20194 1 ip_tablesSeem like that's all networking, wifi and USB, nothing to do with the PRU
@LBDonovan has noticed that /sys/class/uio is empty and
[ 10.003507] pruss_uio 4a300000.pruss: No children
and found a workaround (which disables the muxer capelet):
diff --git a/resources/BELA-00A0.dts b/resources/BELA-00A0.dts
index 21d9923..e7232fb 100644
--- a/resources/BELA-00A0.dts
+++ b/resources/BELA-00A0.dts
@@ -70,7 +70,7 @@
"gpio2_22", "gpio2_24", "gpio2_23", "gpio2_25", "gpio3_19",
/* Misc */
- "mcasp0", "pru0", "pru1", "i2c1";
+ "mcasp0", "i2c1";
/** Pinmux settings **/
fragment@0 {
@@ -88,18 +88,6 @@
>;
};
- /* Pin mux for PRU GPIOs for multiplexer capelet */
- pru_bela_pins: pinmux_pru_bela_pins {
- pinctrl-single,pins = <
- 0x0b0 0x25 /* pr1_pru1_pru_r30_4, P8_41 | MODE5 | OUTPUT_PULLDOWN */
- 0x0b4 0x25 /* pr1_pru1_pru_r30_5, P8_42 | MODE5 | OUTPUT_PULLDOWN */
- 0x0ac 0x25 /* pr1_pru1_pru_r30_3, P8_44 | MODE5 | OUTPUT_PULLDOWN */
- 0x0a0 0x25 /* pr1_pru1_pru_r30_0, P8_45 | MODE5 | OUTPUT_PULLDOWN */
- 0x0a4 0x25 /* pr1_pru1_pru_r30_1, P8_46 | MODE5 | OUTPUT_PULLDOWN */
- 0x0a8 0x25 /* pr1_pru1_pru_r30_2, P8_43 | MODE5 | OUTPUT_PULLDOWN */
- >;
- };
-
/* Pin mux for Bela button */
bela_button_pin: pinmux_bela_button_pin {
pinctrl-single,pins = <
@@ -170,17 +158,6 @@
};
};
- /** PRU **/
- fragment@2 {
- target = <&pruss>;
- __overlay__ {
- pinctrl-names = "default";
- pinctrl-0 = <&pru_bela_pins>;
-
- status = "okay";
- };
- };
-
/** Bela button **/
fragment@3 {
target = <&ocp>;or this actually suggests to add stuff into that fragment
https://groups.google.com/forum/#!topic/beagleboard/T5K3IUvNCyA
So what it does not want is a pinctrl-0 unless you specify some pins there.
So this works:
diff --git a/resources/BELA-00A0.dts b/resources/BELA-00A0.dts
index 21d9923..f637415 100644
--- a/resources/BELA-00A0.dts
+++ b/resources/BELA-00A0.dts
@@ -175,7 +175,6 @@
target = <&pruss>;
__overlay__ {
pinctrl-names = "default";
- pinctrl-0 = <&pru_bela_pins>;
status = "okay";
};though it gives
[ 10.053822] pruss_uio 4a300000.pruss: pins are not configured from the driver
(harmless).
Although @henrix points out this means the PRU pins are not muxed, so the muxer (hence the name) capelet would not work with this one.
@LBDonovan this has been tracked down by @henrix to be an issue in the boot order (he tried with different kernel).
If you load the old dtbo manually after boot, they load with no issue whatsoever.
that's closed / worked around / sped up by this probably BelaPlatform/Bela#285