How to get pin to mode 6 on beagle bone black

[Hans Bentum]

>
>
>
> Hello Hans,
>
> On Thu, 16 Jan 2020 16:05:53 +0100
> Hans Bentum <jwbentum44 at gmail.com> wrote:
>
> > >
> > > Hello Manuel,
> > >
> > > I discovered this tool:  https://github.com/nmingotti/pinfun
> > >
> > >  As you can see pin 8_16 has mode 7 (should be 6). So something must
> give
> > > it mode 7.  The overlays seems to be loaded.
> > >
>
> I think the egpio.dtso is not applied, because all of its entries are
> missing in the devicetree-dump of yours. It seems that only
> am335x-boneblack-pruss.dtbo was applied correctly.
>
> You could try to add your changed directly to the original devicetree file
> (sys/gnu/dts/arm/am335x-bone-common.dtsi) without using overlays at all to
> workaround some overlay trouble. Additionally you could have an closer look
> at the early boot. loader(8) prints also some information during devicetree
> loading and applying of overlays. Those messages are not visible via dmesg,
> they can only be seen on the serial console during boot.
>
> Best Regards,
>
> --
> Manuel
>

 Hello,

Manuel, thanks you pointed me in the right direction.
The serial console shows a "failed to apply overlay: FDT_ERR_NOTFOUND"
error.

This has been solved now by changing the overlay. Now I use only one ovelay:

# cat am335x-boneblack-pruss.dtso
/dts-v1/;
/plugin/;
/ {
        compatible="ti,am335x-bone-black","ti,am335x-bone","ti,am33x";
        exclusive-use = "P8.16", "pru0";
        fragment at 0 {
                target-path="/";
                __overlay__ {
                        ocp {
                                #address-cells = <1>;
                                #size-cells = <1>;
                                pruss at 4a300000 {
                                        status="okay";
                                        compatible="ti,pruss-v2";

ti,deassert-hard-reset="pruss","pruss";
                                        reg = <0x4a300000 0x080000>;
                                        ti,pintc-offset = <0x20000>;
                                        interrupt-parent=<&intc>;
                                        interrupts=<20 21 22 23 24 25 26
27>;
                                };
                        };
                };
        };

        fragment at 1 {
                target = <&am33xx_pinmux>;
                __overlay__ {
                        example_pins: pinmux_pru_pru_pins {
                                pinctrl-single,pins = <
                                        0x38 0x36 /* Pin 8_16 in gpmc_ad14
mode 6 PULL UP */
                                >;
                        };
                };
        };
}

It seems to be loaded. A part of the output of:
#sysctl -b hw.fdt.dtb | dtc -I dtb -O dts
pinmux at 800 {

compatible = "pinctrl-single";
reg = <0x800 0x238>;
#pinctrl-cells = <0x1>;
pinctrl-single,register-width = <0x20>;
pinctrl-single,function-mask = <0x7f>;
pinctrl-names = "default";
pinctrl-0 = <0x6a>;
phandle = <0x65>;
pinmux_pru_pru_pins {

pinctrl-single,pins = <0x38 0x36>;
};

As you can see pinmux_pru_pru_pins is pressent.
The output of #ruby pinfun.rb shows:
P.8.15   GPIO1_15        7    gpio1[15]            <IN,PD>
P.8.16   GPIO1_14        6    pr1_pru0_pru_r31_14
P.8.17   GPIO0_27        7    gpio0[27]            <IN,PD>

and the output of # gpioctl -l -f /dev/gpioc1
shows with input being low:
#pin 14: 0       gpio_14<IN,PD>
and with input being high
pin 14: 1       gpio_14<IN,PD>

The input is correct, but the 0x36 of pinmux_pru_pru_pins means pull up so
<IN, PD> should be  <IN, PU> if the userlevel tool is able
to see the changed configuration. I think it is printing some default
configuration.
(actually I want a PD, but uses now the 0x36 (pull up, mode 6) instead of
0x26 (pull down mode 6) to see changes in the printed values of gpioctl)

Unfortunatly I can not see the input in the pru by reading register r31
(that should contain the high/low value at bit 14).

Question:
- Is is to be expected that a user level tool like gpioctl can see an input
for a pin configurated for usage by the pru?

Now I gone try to change the original device tree. The
am335x-bone-common.dtsi as Manuel suggested is not pressent.

Question:
- I think /boot/dtb/am335x-boneblack.dtb must be is loaded. Is this
correct. The serial console output does not print the
name of the device tree file that is loaded. How can I know what is loaded?

Regards,
Hans