My device tree overlay is bricking the NanoPi NEO

[indianajones]

I'm trying to add the optional input-debounce to the GPIO G ports of my NanoPi NEO (AllWinner H3) with a device tree overlay, but my overlay merely manages to brick the device.  Here is my overlay, of which I've tried several tweaked versions:

/dts-v1/;
/plugin/;

/ {
    fragment@0 {
        target = <&pio>;
        __overlay__ {
            input-debounce = <1 1>;
        };
    };
};

 

I create the file on the running device and I use 'sudo armbian-add-overlay <file.dts>' and reboot to test my changes.  I'm using <&pio> as the target because I see in the device tree that &pio is a symbol to "/soc/pinctrl@1c20800".  As for the actual input-debounce values, I'm not 100% sure what should go in there, or how many arguments I need.  I've experimented with two or three values inside the <> (always a 1), and those tweaks always brick the device.  It's as if the device tree compiler is treating it as a complete device tree subsection rather than an overlay.  Does anyone have suggestions of what I might be doing wrong?  Thanks!

[tparys]

On 5/18/2021 at 1:58 AM, indianajones said:

As for the actual input-debounce values, I'm not 100% sure what should go in there, or how many arguments I need.

 

Check the AllWinner device tree bindings in the kernel documentation?

 

https://www.kernel.org/doc/Documentation/devicetree/bindings/pinctrl/allwinner%2Csunxi-pinctrl.txt

[indianajones]

12 hours ago, tparys said:

 

Check the AllWinner device tree bindings in the kernel documentation?

 

https://www.kernel.org/doc/Documentation/devicetree/bindings/pinctrl/allwinner%2Csunxi-pinctrl.txt

 

It says "one period per irq bank found in the controller".  My interpretation of that is I would need three values - one each for GPIO A, G, and L, e.g. input-debounce <1 1 1>.  However, other posts imply only two values are required.  But unfortunately my biggest problem is that any attempt to change the main pio (pinctrl@1c20800) section bricks the device.  I can make changes to sub-sections inside pinctrl@1c20800, so I *almost* know what I'm doing.  But the optional input-debounce is a property of the main pinctrl@1c20800 itself.  I believe that once I get that resolved, I'll be able to troubleshoot my way to learning the proper debounce values.

[tparys]

Not that I've tried this debounce, but you can try to load them dynamically after boot?

 

https://forum.armbian.com/topic/17842-dynamic-device-tree-overlays/

 

Unless it crashes the kernel on sight, it might dump a useful message to dmesg about what's wrong?

 

[indianajones]

@tparys yes that's how I'm doing it.  I boot a working image, and try to add the overly using armbian-add-overlay, which throws no errors, and I get the message that a reboot is required to make it live.  It never recovers from the reboot (at least it never recovers far enough to ping it, I don't have HDMI connected).

[tparys]

So, armbian-add-overlay adds the overlay to /boot/overlay-user, which are processed in the bootloader before the kernel starts.

 

The process I pointed uses sysfs to actually tells the kernel to add the overlay *after* the system starts, and doesn't affect future boots.

[indianajones]

@tparys my apologies, I missed that.  I'll give it a go, maybe I'll learn something.