One of the Bananapi-m1+ GPIO pins is connected to an LED that I need to illuminate as quickly as possible after power-on.  Using an older Fedora Linux release, it turns on in 3 seconds.  Using a recent Armbian build, it takes 45 seconds.  I've tried many ways using services with early "After=" targets, to access /sys/class/gpio/* interfaces more quickly, and this improved it by 5 seconds, but it's still too long.  So I tried adding a device tree overlay to set the default value in the pin controller.  I am confident the DT overlay is getting read and parsed properly, based on seeing artifacts in debugging streams, but still, no LED illumination.  Anybody got any ideas on either what's up with the DT overlay contents, or other ways to accomplish this?  Any hints or suggestions would be greatly appreciated.  Here's the device tree overlay .dts file (also attached).  I'm sure the gpio 224 associated with PH0 is correct, since the /sys/class/gpio/* interfaces do work properly to control the LED.

 

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun7i-a20";

    fragment@0 {
        target-path = "/soc/pinctrl@1c20800"; /* A20 Pin Controller */
        __overlay__ {
            gpio224_pin: gpio224 {
                pins = "PH0";  /* GPIO 224 = PH0 */
                function = "gpio_out"; /* Set as output */
                output-high;   /* Set high at boot */
            };
        };
    };

    fragment@1 {
        target = <&pio>; /* GPIO controller */
        __overlay__ {
            gpio224 {
                gpio-hog;
                gpios = <&pio 224 1>; /* Actrive HIGH */
                output-high;
                line-name = "gpio_224_ph0";
            };
        };
    };
};

sun7i-a20-ledon.dts

Hi jimw,

 

You are currently addressing the pin controller twice as it performs both pin control and gpio control operations. Try something like this which should work. The led node should make it visible in '/sys/class/leds'

 

/dts-v1/;
/plugin/;
/{

    compatible = "allwinner,sun7i-a20";
    
	fragment@0 {

	    target = <&pio>;	
	    __overlay__{
	
	        my_led_pin: my_led_pin {
                pins ="PH0";
                function = "gpio_out";
            };

         };
    };
          
    fragment@1 {
        target-path = "/";
		__overlay__ {
			leds: leds@0 {
				compatible = "gpio-leds";
				pinctrl-names = "default";
				pinctrl-0 = <&my_led_pin>;
				status = "okay";

				led: led {
			        label = "my_led";
				    gpios = <&pio 7 0 0>;
			        default-on;
				};
			};
		};
    };
};

note the pinctrl control reference '&pio' always take 3 arguments the first is the number of the port which starts with A=0 and goes to I=8. The second is the pin on that particular port and finally the pin state which can either be active high = 0 or active low = 1.

Thanks, I'll give this a try.  I have my own code that accesses the pin controller registers during run-time, so I didn't think to use an led object.  🙂

 

Thanks for your suggestion, Ryzer, I really appreciate you sharing your knowledge about this.  To compile the new overlay, I first removed the "@0" from "leds: leds@0 {" line, to avoid a compiler warning, as AI suggested.  The result is, after full boot, I now have /sys/class/leds/my_led/* interfaces and I can turn on the LED by "echo 1 > /sys/class/leds/my_led/brightness", as expected.  But alas, the LED doesn't come on during the bootup sequence automatically by default.  I am suspicious that perhaps some other hardware initialization is either overriding or overwriting the default-on statement in the dts file.  Does it sound productive to decompile the sun7i-a20-bananapi-m1-plus.dtb file and look for references to PH0 to see if anybody else is trying to control it?  The fact that the "echo 1 >" and "echo 0 >" commands turn the LED on and off appropriately, suggest to me the active-high nature of the pin must be set correctly.  Would it help to apply a pull-up configuration as a default?  If so, where would this go.  BTW, if you could point me to a book or something I could use to learn DT programming, I'd appreciate it.  Thanks again, Jim

 

Oh, and this is interesting:  AI suggested the kernel might be resetting the GPIO state during boot.  It recommended creating a file named /etc/udev/rules.d/99-led-default.rules, containing one line saying, 'ACTION=="add", SUBSYSTEM=="leds", KERNEL=="my_led", ATTR{trigger}="default-on"'.  This did cause the LED to now come on automatically during the boot-sequence!  It turns on 21 seconds after power is applied.  That's still slower than I'd hoped, but its an improvement.  Does this information give you any ideas for overlay programming that could make it faster?

 

 

Ryzer, Thanks a lot for your help with this.  I tried a number of things and found a very simple solution that got the time down to 6 seconds.  I added "gpio set 224" in the boot.cmd file and rebuilt the boot.scr file.  That was it! 

 

If you happen to know any resources I could use to learn DT programming, I'm very interested in pursuing this.

 

Thanks again,

 Jim

 

 

Hi jimw,

 

Glad you have made progress. Its interesting that you got such a quick setup by amending the boot.cmd file, I will need to try that approuch myself for my other issues. I havent previously had reason to touch the boot.scr. Either I missed remember the last parameter or it may have changed, reviewing the binding it should be 'default-state = "on"; '. I mostly just watch youtube such as: 

Bootlin also provide a lot of good resources: https://bootlin.com/pub/conferences/2021/webinar/petazzoni-device-tree-101/petazzoni-device-tree-101.pdf

 

Hope this help

 

Ryzer

Edited February 17, 20251 yr by Ryzer

This is a very interesting topic  I will try to apply it when I need a fast 3.3V output on startup.

 

I am dealing with LCD screens right now, and I know 3 ways to display something on screen faster:

* compiling the LCD driver(s) into the kernel (with the * option instead of "M" in Linux kernel config)
* make uboot drive the LCD display (https://github.com/robutest/u-boot/blob/master/drivers/video/ili9341.c)

* instead of compiling a DTBO to overlay after startup, add the "blob" in the main DT itself and uboot wont lose time on that (there's a discussion about that in onf of the opiz3 gpio threads)

(but I haven't tried any of them)