Jump to content

My device tree overlay is bricking the NanoPi NEO


indianajones

Recommended Posts

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines