Hi,
I’m trying to use the pru and I got :
pruss_uio 4a300000.pruss: No children
my pru.dtsi file :
&am33xx_pinmux {
pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <
0x158 0x72 /* spi0_d1.i2c1_sda, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 /
0x15c 0x72 / spi0_cs0.i2c1_scl, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */
;
};
};
&pruss{
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&pru_pru_pins>;
};
What is wrong ?
…
Micka,
The aliases am33xx_pinmux, and pruss already exist in the stock board files. But look at this snippet as an example.
fragment@0 {
target = <&am33xx_pinmux>;
overlay {
bb_gpio_relay_pins: pinmux_bb_gpio_relay_pins {
pinctrl-single,pins = <
BONE_P9_15 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a0.gpio1_16 /
BONE_P9_23 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) / gpmc_a1.gpio1_17 /
BONE_P9_12 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) / gpmc_be1n.gpio1_28 /
BONE_P9_27 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) / mcasp0_fsr.gpio3_19 */
;
};
};
};
fragment@1 {
target-path=“/”;
overlay {
leds {
pinctrl-names = “default”;
pinctrl-0 = <&bb_gpio_relay_pins>;
compatible = “gpio-leds”;
jp@1 {
label = “relay-jp1”;
gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
default-state = “keep”;
};
jp@2 {
label = “relay-jp2”;
gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
default-state = “keep”;
};
jp@3 {
label = “relay-jp3”;
gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
default-state = “keep”;
};
jp@4 {
label = “relay-jp4”;
gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
default-state = “keep”;
};
};
};
};
Passed that, why do you need to “bind” these pins to the PRUs ? The PRU’s can access any GPIO / hardware module directly through it’s register addresses. Whats more, I’m not even sure what you’re trying to do is possible. The PRUs are not like any of the other hardware modules on the processor, in that they are directly connected to pads / pins.
I think a good example of how to enable pins and the PRUs in the same overlay file would be Beagelpilot. I’ll check it’s dts’s too since I’m currently not doing anything . . .
Here is a good example I think, but I’m confused as to why he has multiple mode / pullup / pulldown configurations for the same pin. But I would take that as only on mode / pullup/pulldown config is meant to be used at any one given time.
https://github.com/nomel/beaglebone/tree/master/pru-gpio/generated
Thanks for the help,
I forgot to precise that I’m not using cape manager. I’ve edited the file am335x-bonelback.dts to include the file pru.dtsi .
The idea in this file is to configure the pins used by the PRU ( you need to configure before using it with the pru ) .
And for what I understood in the device tree, it’s not a problem to repeat the node &am33xx_pinmux { .
It is used in the file am335x-boneblack.dts and the file am335x-bone-common.dtsi .
So, theoretically it should works to do that in the file pru.dtsi :
&am33xx_pinmux {
pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <
0x158 0x72 /* spi0_d1.i2c1_sda, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 /
0x15c 0x72 / spi0_cs0.i2c1_scl, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */
;
};
};
&pruss{
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&pru_pru_pins>;
};
I discovered that you can decompile dtb file ^^ =>
dtc -O dts -I dtb -o am335x-boneblack.dts am335x-boneblack.dtb
the dtb file is the input and the dts file is the output ^^ .
I attached the file generated with this command.
I can find the pruss definition :
pruss@4a300000 {
compatible = “ti,pruss-v2”;
ti,hwmods = “pruss”;
ti,deassert-hard-reset = “pruss”, “pruss”;
reg = <0x4a300000 0x80000>;
ti,pintc-offset = <0x20000>;
interrupt-parent = <0x1>;
status = “okay”;
interrupts = <0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b>;
pinctrl-names = “default”;
pinctrl-0 = <0x31>;
linux,phandle = <0xa2>;
phandle = <0xa2>;
};
and the line with pinctrl-0 = <0x31>; means that it is linked with that :
pinmux_pru_pru_pins {
pinctrl-single,pins = <0x158 0x72 0x15c 0x72>;
linux,phandle = <0x31>;
phandle = <0x31>;
};
But I still don’t understand what this error message mean :
[ 6.745295] pruss_uio 4a300000.pruss: No children
Micka,
am335x-boneblack.dts (67.4 KB)
The error message, I’ve discovered means that while you have pins defined, you didn’t supply them in your .dts file… I finally found an example I was able to pull from so I have something that looks like this:
`
fragment@0{
target=<&am33xx_pinmux>
overlay{
pru_pru_pins:pinmux_pru_pru_pins{
pinctrl-single,pins =<
0x1a4 0x05 //P9_27 pr1_pru0_pru_r30_5,Mode 5 output pulldown
0x19c 0x3e //P9_28 pr1_pru0_pru_r31_3,Mode 6 input pulldown
;
};
};
};
fragment@1 {
target = <&pruss>;
overlay {
status= “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&pru_pru_pins>;
inout {
pin-names = “x:out”,“x:in”
gpios = <&gpio3 19 0
&gpio3 17 0>;
};
};
};
`
The main thing is that the fragment@1 now has a child, inout, containing the pins that it is using. If you are using no pins, then presumably you won’t have the other things in there either and “no children” won’t appear then either, but you likely wouldn’t need the PRU if you didn’t want GPIOs. In any case, I didn’t have to patch the kernel this way. I haven’t ported any of my stuff over to remoteproc yet, so I don’t know how this plays in Peoria, but if you need to use the uio_pruss with, at least 4.9 kernel (this is just building with the basic Beaglebone Black configuration and I do have to remove McASP (which gets loaded if you use HDMI) in my case, but it does seem to work).