jimw

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

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?

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. 🙂

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

Nice. Thank you.

Thanks all; I'll try this.

Glad to say creating virtual machine and getting Armbian build environment and running ./compile.sh was easy and successful for bananapim1plus / 6.1 kernel / jammy. Created SD card and booted and is running fine. Added DT overlay to enable spidev and got /dev/spidev0.0 as expected. Got new version of cross compiler to build code I formerly ran on fedora image and the SPI driver behaves differently. It pulses CS low for every transfer instead of optionally staying low for multiple transfers based on "cs_change" field in each transfer message. Found kernel source in build/cache/sources/linux-kernel-worktree/6.1__sunxi__armhf/drivers/spi, and tried editing there to begin debugging (even tried git commit there), and each time I re-run ./compile.sh, my changes are blown-away. Looking to understand what the standard workflow is for this? Do I have to use user patches? Do I have to build the kernel somewhere else and inject it into the img somewhere? Any suggestions welcome. THANK YOU.