Module Load Order Issue? FreeBSD 13 on BeagleBone Black with Overlays.

srfilipek · Jun 12, 2021

I'm booting FreeBSD 13 STABLE 20210610 on a BeagleBone Black, using a few custom device tree overlays to enable some peripherals. I'm using a w1-gpio and pps-gpio device, but running into issues due to device attach ordering.

The "pps-gpio" and "w1-gpio" devices attached before the "gpio0" and "gpio1" devices they use. A log from dmsg:

Code:

owc0: <GPIO one-wire bus> on ofwbus0
owc0: cannot acquire gpio pin (config error)
device_attach: owc0 attach returned 19
gpiopps0: <GPIO PPS> on ofwbus0
gpiopps0: Cannot obtain gpio pin
device_attach: gpiopps0 attach returned 19
...
gpio0: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 3 on ti_sysc1
gpiobus0: <OFW GPIO bus> on gpio0
gpioc0: <GPIO controller> on gpio0
...
gpio1: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 26 on ti_sysc21
gpiobus1: <OFW GPIO bus> on gpio1
gpioc1: <GPIO controller> on gpio1

...

In loader.conf, I explicitly load owc and gpiopps:

Code:

gpiopps_load="YES"
owc_load="YES"

If I remove this, owc automatically loads later in the boot process, and the "owc0" device works. Similarly, if I manually load "gpiopps" after boot, then the gpiopps device works:

Code:

owc0: <GPIO one-wire bus> on ofwbus0
ow0: <1 Wire Bus> on owc0
ow0: Reset discovered bus wired wrong.
...
gpiopps0: <GPIO PPS> on ofwbus0
gpiopps0: PPS input on gpio0 pin 7

So, I know my overlays are configured correctly, there's just a race condition.

Is there a known solution to either ensure these devices get attached later than the gpio devices they depend on?

Note: The effective device tree lists seems to place the overlayed devices (onewire and pps) very early into the tree, which might be causing them to attached too early:

Code:

/dts-v1/;

/memreserve/ 0x88000000 0x16000 0x87fe8000 0x16000;

/  {

        serial-number = "xxxxxxx";
        compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
        interrupt-parent = <0xce>;
        #address-cells = <0x1>;
        #size-cells = <0x1>;
        model = "TI AM335x BeagleBone Black";
        freebsd,dts-version = "5.9";
        onewire { ... };
        pps { ... };

srfilipek · Jun 13, 2021

I think I mitigated the problem, but I'm not entirely sure why.

My initial overlays added the devices at the root of the device tree, with an entry such as:

Code:

fragment@2 {
        target-path = "/";
        __overlay__ {
            pps {
                status = "okay";
                compatible = "pps-gpio";
                pinctrl-names = "default";
                pinctrl-0 = <&pps_pins>;
                gpios = <&gpio0 7 0>;
            };
        };

Changing the target path to "/ocp/" resulted in the gpiopps module auto-loading later in the boot process (it did not auto-load with a target-path of "/"). So, both the 1-wire device and gpiopps device are now loading late enough in the boot process where the gpio devices are already setup.

In summary:

If I explicitly load modules with gpiopps_load="YES" and owc_load="YES", the devices will attach too early and error out -- the gpiobus devices are not attached yet. This happens with target-path of "/" or "/ocp/".
If I don't load modules explicitly, they are auto-loaded later in the boot process after gpiobus devices have been established, so it works
gpiopps only auto-loads if the pps device above is in the "/ocp/" path (bug?), but the 1-wire device is fine regardless

Module Load Order Issue? FreeBSD 13 on BeagleBone Black with Overlays.

srfilipek

srfilipek