NanoPi NEO | LEDs have stopped working with Linux v5.15

[mhjessen]

Creating a bug report/issue

Beginning with either v8.1 or v8.2 the green & blue LEDs on my NanoPi NEO have stopped working. I restored an image of v8.0.2 and the LEDs were working again as before. I then upgraded to v8.3.1 and they no longer work.

Required Information

• DietPi version | cat /boot/dietpi/.version G_DIETPI_VERSION_SUB=3 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN bullseye

• Kernel version | uname -a Linux mhj-neo 5.15.25-sunxi #22.02.1 SMP Sun Feb 27 09:23:25 UTC 2022 armv7l GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3) NanoPi NEO (armv7l)

• Power supply used | (EG: 5V 1A RAVpower) North Pada 5v 3A (verified via USB multi-meter)

• SD card used | (EG: SanDisk ultra) Samsung 32GB EVO and PNY 32GB Elite

Additional Information (if applicable)

• Software title | (EG: Nextcloud) = N/A
• Was the software title installed freshly or updated/migrated? = N/A
• Can this issue be replicated on a fresh installation of DietPi? = Yes

• Bug report ID | echo $G_HW_UUID = 22ab27f3-4601-4df7-b20f-9f32cc6fc943

Steps to reproduce

1. Either cold start or reboot
2. ...

Expected behaviour

• 1 : nanopi:green:status [heartbeat]
• 2 : nanopi:red:pwr [activity]

Actual behaviour

• On startup the green LED comes on solid for about 10 seconds then goes out. No LED activity after that.

Extra details

I did notice that with v8.0.2 (Linux mhj-neo 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l GNU/Linux) none of the files in /lib/modules/5.10.60-sunxi/kernel/drivers/ were xz compressed. In v8.3.1 they are all xz compressed.

- grep led /var/log/syslog
Apr  3 15:21:32 mhj-neo kernel: [    3.302645] leds-gpio: probe of leds failed with error -16

- cat /sys/devices/platform/leds/leds/nanopi:green:status/trigger
cat: '/sys/devices/platform/leds/leds/nanopi:green:status/trigger': No such file or directory

- dietpi-led_control
[FAILED] DietPi-LED_control | No LED devices found in /sys/class/leds/. Exiting...

- cat /etc/udev/rules.d/dietpi-led_control.rules = 
# Added by DietPi:
SUBSYSTEM=="leds", KERNEL=="nanopi:green:status", ACTION=="add", ATTR{trigger}="heartbeat"
SUBSYSTEM=="leds", KERNEL=="nanopi:red:pwr", ACTION=="add", ATTR{trigger}="activity"

- cat /sys/class/leds/led{0,1}/trigger
cat: /sys/class/leds/led0/trigger: No such file or directory
cat: /sys/class/leds/led1/trigger: No such file or directory

- ls -lha /sys/class/leds/
total 0
drwxr-xr-x  2 root root 0 Apr  3 15:08 .
drwxr-xr-x 60 root root 0 Apr  3 15:08 ..

[MichaIng]

Many thanks for your report.

Seems similar: #5385 Just not the GPIO sysfs interface but the one for the LEDs.

I wonder whether this is the same with stable/supported kernel as well.

If you find some time and a spare SD card, could you test the Armbian image (Debian Bullseye, Kernel 5.15.y): https://www.armbian.com/nanopi-neo/ If it is the same, if can be reported here: https://forum.armbian.com/forum/13-allwinner-h2-h3/

Generally those are defined in the device tree. Does this show something?

ls -l /proc/device-tree/leds

[mhjessen]

Thanks for looking into this!

I agree that is does look similar to #5385

I just downloaded from the link you provided; Armbian 22.02 Bullseye Kernel 5.15.y, Size: 330Mb, Updated: Feb 27, 2022 I will try to get it going tonight and update this ticket with the results.

In the meantime;

ls -l /proc/device-tree/leds
total 0
-r--r--r-- 1 root root 10 Apr  5 13:28 compatible
drwxr-xr-x 2 root root  0 Apr  5 13:28 led-0
drwxr-xr-x 2 root root  0 Apr  5 13:28 led-1
-r--r--r-- 1 root root  5 Apr  5 13:28 name
-r--r--r-- 1 root root  8 Apr  5 13:28 pinctrl-0
-r--r--r-- 1 root root  8 Apr  5 13:28 pinctrl-names
drwxr-xr-x 2 root root  0 Apr  5 13:28 pwr
drwxr-xr-x 2 root root  0 Apr  5 13:28 status

ls -l /proc/device-tree/leds/led-0
total 0
-r--r--r-- 1 root root 16 Apr  5 13:28 gpios
-r--r--r-- 1 root root 19 Apr  5 13:28 label
-r--r--r-- 1 root root 10 Apr  5 13:28 linux,default-trigger
-r--r--r-- 1 root root  6 Apr  5 13:28 name

cat /proc/device-tree/leds/led-0/gpios

cat /proc/device-tree/leds/led-0/label
nanopi:blue:status

cat /proc/device-tree/leds/led-0/linux,default-trigger 
heartbeat

cat /proc/device-tree/leds/led-0/name
led-0

ls -l /proc/device-tree/leds/led-1
total 0
-r--r--r-- 1 root root  3 Apr  5 13:33 default-state
-r--r--r-- 1 root root 16 Apr  5 13:33 gpios
-r--r--r-- 1 root root 17 Apr  5 13:33 label
-r--r--r-- 1 root root  6 Apr  5 13:33 name

cat /proc/device-tree/leds/led-1/default-state 
on

cat /proc/device-tree/leds/led-1/gpios 
9

cat /proc/device-tree/leds/led-1/label 
nanopi:green:pwr

cat /proc/device-tree/leds/led-1/name
led-1

cat /proc/device-tree/leds/name
leds

cat /proc/device-tree/leds/pinctrl-0
78

cat /proc/device-tree/leds/pinctrl-names
default

cat /proc/device-tree/leds/pwr/gpios 
9

cat /proc/device-tree/leds/pwr/label 
nanopi:red:pwr

cat /proc/device-tree/leds/pwr/linux,default-trigger 
default-on

cat /proc/device-tree/leds/pwr/name
pwr

ls -l /proc/device-tree/leds/status/
total 0
-r--r--r-- 1 root root 16 Apr  5 13:40 gpios
-r--r--r-- 1 root root 20 Apr  5 13:40 label
-r--r--r-- 1 root root 10 Apr  5 13:40 linux,default-trigger
-r--r--r-- 1 root root  7 Apr  5 13:40 name

cat /proc/device-tree/leds/status/gpios

cat /proc/device-tree/leds/status/label 
nanopi:green:status

cat /proc/device-tree/leds/status/linux,default-trigger 
heartbeat

cat /proc/device-tree/leds/status/name 
status

[MichaIng]

So on device tree end, the LEDs are there, the correct default trigger is shown etc, but only the sysfs interface to change the triggers is missing. In case of the sysfs GPIO interface, it was deprecated in Linux, in favour of libgpiod, but can be re-enabled. But for LED control I don't see that it is deprecated: https://www.kernel.org/doc/html/latest/leds/leds-class.html

[mhjessen]

Apologies for the delayed update. I was challenged by getting a working SDHC setup. NEO doesn't like Sandisk or PNY cards, only Samsung. Anyway...

The results for Armbian are the same. The green LED comes on solid for 10 seconds on startup then both LEDs are off after that. See below for addition information.

I've submitted a bug report to Armbian; https://forum.armbian.com/topic/20245-nanopi-neo-leds-not-working-with-linux-51525-sunxi-armbian-22021/

# uname -a
Linux nanopineo 5.15.25-sunxi #22.02.1 SMP Sun Feb 27 09:23:25 UTC 2022 armv7l GNU/Linux

# cat /sys/devices/platform/leds/leds/nanopi:green:status/trigger
cat: '/sys/devices/platform/leds/leds/nanopi:green:status/trigger': No such file or directory

# ls -lha /sys/class/leds/
total 0
drwxr-xr-x  2 root root 0 Dec 31  1969 .
drwxr-xr-x 62 root root 0 Dec 31  1969 ..

# grep led /var/log/syslog
Feb 27 22:38:48 nanopineo kernel: [    2.532268] leds-gpio: probe of leds failed with error -16
Feb 27 22:38:48 nanopineo kernel: [    2.534730] ledtrig-cpu: registered to indicate activity on CPUs

# locate leds
/usr/bin/setleds
/usr/include/linux/uleds.h
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/input/input-leds.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/flash
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/led-class-flash.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-an30259a.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-axp20x.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-bcm6328.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-bcm6358.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-bd2802.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-cpcap.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-cr0014114.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-dac124s085.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-el15203000.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-is31fl319x.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-is31fl32xx.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lm3530.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lm3532.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lm355x.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lm3642.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lm3692x.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lm3697.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp3944.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp3952.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp5521.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp5523.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp5562.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp55xx-common.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp8501.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lp8860.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-lt3593.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-max77650.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-mlxreg.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-pca9532.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-pca955x.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-pca963x.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-pwm.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-regulator.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-spi-byte.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-tca6507.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-ti-lmu-common.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/leds-tlc591xx.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/flash/leds-as3645a.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/flash/leds-ktd2692.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/flash/leds-lm3601x.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/flash/leds-rt4505.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/flash/leds-rt8515.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-audio.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-backlight.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-camera.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-gpio.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-netdev.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-oneshot.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-pattern.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-timer.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-transient.ko.xz
/usr/lib/modules/5.15.25-sunxi/kernel/drivers/leds/trigger/ledtrig-tty.ko.xz
/usr/share/X11/xkb/compat/ledscroll
/usr/share/man/man1/setleds.1.gz

# ls -l /proc/device-tree/leds
total 0
-r--r--r-- 1 root root 10 Apr 10 10:35 compatible
drwxr-xr-x 2 root root  0 Apr 10 10:30 led-0
drwxr-xr-x 2 root root  0 Apr 10 10:30 led-1
-r--r--r-- 1 root root  5 Apr 10 10:35 name
-r--r--r-- 1 root root  8 Apr 10 10:35 pinctrl-0
-r--r--r-- 1 root root  8 Apr 10 10:35 pinctrl-names
drwxr-xr-x 2 root root  0 Apr 10 10:30 pwr
drwxr-xr-x 2 root root  0 Apr 10 10:30 status

# ls -l /proc/device-tree/leds/led-0
total 0
-r--r--r-- 1 root root 16 Apr 10 10:36 gpios
-r--r--r-- 1 root root 19 Apr 10 10:36 label
-r--r--r-- 1 root root 10 Apr 10 10:36 linux,default-trigger
-r--r--r-- 1 root root  6 Apr 10 10:36 name

# ls -l /proc/device-tree/leds/led-1
total 0
-r--r--r-- 1 root root  3 Apr 10 10:36 default-state
-r--r--r-- 1 root root 16 Apr 10 10:36 gpios
-r--r--r-- 1 root root 17 Apr 10 10:36 label
-r--r--r-- 1 root root  6 Apr 10 10:36 name

# ls -l /proc/device-tree/leds/pwr
total 0
-r--r--r-- 1 root root 16 Apr 10 10:37 gpios
-r--r--r-- 1 root root 15 Apr 10 10:37 label
-r--r--r-- 1 root root 11 Apr 10 10:37 linux,default-trigger
-r--r--r-- 1 root root  4 Apr 10 10:37 name

# ls -l /proc/device-tree/leds/status
total 0
-r--r--r-- 1 root root 16 Apr 10 10:37 gpios
-r--r--r-- 1 root root 20 Apr 10 10:37 label
-r--r--r-- 1 root root 10 Apr 10 10:37 linux,default-trigger
-r--r--r-- 1 root root  7 Apr 10 10:37 name

# cat /proc/device-tree/leds/led-0/gpios

# cat /proc/device-tree/leds/led-0/label
nanopi:blue:status

# cat /proc/device-tree/leds/led-0/linux,default-trigger 
heartbeat

# cat /proc/device-tree/leds/led-0/name 
led-0

# cat /proc/device-tree/leds/led-1/default-state 
on

# cat /proc/device-tree/leds/led-1/gpios
9

# cat /proc/device-tree/leds/led-1/label 
nanopi:green:pwr

# cat /proc/device-tree/leds/led-1/name
led-1

# cat /proc/device-tree/leds/pwr/gpios 
9

# cat /proc/device-tree/leds/pwr/label 
nanopi:red:pwr

# cat /proc/device-tree/leds/pwr/linux,default-trigger 
default-on

# cat /proc/device-tree/leds/pwr/name 
pwr

# cat /proc/device-tree/leds/status/gpios

# cat /proc/device-tree/leds/status/label 
nanopi:green:status

# cat /proc/device-tree/leds/status/linux,default-trigger 
heartbeat

# cat /proc/device-tree/leds/status/name
status

In the armbian-config .dts editor I found that led-0 and led-1 are reversed from what I found above. led-0 is blue and led-1 is green. I don't know if that's a show stopper or not.

1463         leds {
1464                 compatible = "gpio-leds";
1465
1466                 led-0 {
1467                         label = "nanopi:green:pwr";
1468                         gpios = <0x3f 0x00 0x0a 0x00>;
1469                         default-state = "on";
1470                 };
1471
1472                 led-1 {
1473                         label = "nanopi:blue:status";
1474                         gpios = <0x0e 0x00 0x0a 0x00>;
1475                         linux,default-trigger = "heartbeat";
1476                 };
1477         };

The config-5.15.25-sunxi file shows;

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
CONFIG_LEDS_TRIGGER_DISK=y
CONFIG_LEDS_TRIGGER_MTD=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_ACTIVITY=y
CONFIG_LEDS_TRIGGER_GPIO=m
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

I'll update here when I get word back on the Armbian bug report.

[mhjessen]

I've opened case "NanoPi NEO LEDs not working with Linux 5.15.25-sunxi (Armbian 22.02.1)" in the Armbian Allwinner H2 & H3 forum.

https://forum.armbian.com/topic/20245-nanopi-neo-leds-not-working-with-linux-51525-sunxi-armbian-22021/

Fingers crossed!

[mhjessen]

Appears the issue is related to; Error loading modules after kernel upgrade
https://forum.armbian.com/topic/20087-error-loading-modules-after-kernel-upgrade/

Solution being worked on is to disable xz module compression; disable module compression for sunxi-current https://github.com/armbian/build/pull/3663 https://github.com/armbian/build/pull/3663/files

[mhjessen]

Contributed system information to Error loading modules after kernel upgrade https://forum.armbian.com/topic/20087-error-loading-modules-after-kernel-upgrade/?do=findComment&comment=138459

[MichaIng]

@mhjessen I'm actually not convinced that your issue is related to the "module not found" errors in this thread. Also I do not see those error messages in any of your logs. You would see them when regenerating the initramfs:

update-initramfs -u

or when trying to load a kernel module:

modprobe ipv6

The error in this forum thread seems to be with older Ubuntu and Debian versions only, where the userland tools like modprobe are not able to deal with xz-compressed modules, but on Debian Bullseye this doesn't seem to be an issue.

[mhjessen]

Agreed. I ran both and there's nothing in the logs.

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.15.25-sunxi

# modprobe ipv6
<nothing>

[MichaIng]

So indeed the issues are not related. I added this info to your Armbian forum thread.

[Sfinx]

upon configuring LED's kernel prints:

leds-gpio: probe of leds failed with error -16

-16 means EBUSY. Removing shit makes LED's work again. tested at armbian_22.05.4_Nanopineo_jammy_current_5.15.48

--- orig.dts	2022-07-30 11:48:20.657650732 +0300
+++ sys.dts	2022-07-30 11:44:16.388711117 +0300
@@ -1415,22 +1415,10 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <0x37 0x38>;
 
-		led-0 {
-			label = "nanopi:blue:status";
-			gpios = <0x0d 0x00 0x0a 0x00>;
-			linux,default-trigger = "heartbeat";
-		};
-
-		led-1 {
-			label = "nanopi:green:pwr";
-			gpios = <0x39 0x00 0x0a 0x00>;
-			default-state = "on";
-		};
-
 		pwr {
 			label = "nanopi:red:pwr";
 			gpios = <0x39 0x00 0x0a 0x00>;
-			linux,default-trigger = "default-on";
+			default-state = "on";
 		};
 
 		status {

root@cs:~# l /sys/class/leds/
total 0
drwxr-xr-x  2 root root 0 Jan  1  1970 ./
drwxr-xr-x 61 root root 0 Jan  1  1970 ../
lrwxrwxrwx  1 root root 0 Jan  1  1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status/
lrwxrwxrwx  1 root root 0 Jan  1  1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr/

[MichaIng]

@Sfinx Nice, were these present probably as of an Armbian patch which has now become obsolete and conflicting? So we may open a PR to remove the patch.

[MichaIng]

@mhjessen @Sfinx ~It's working again with latest "current" kernel 5.15.93-sunxi, right? At least on NanoPi M1 it works well here.~ EDIT: Most likely not.

There is an LED related patch at Armbian: https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-5.15/patches.armbian/arm-dts-sun8i-h3-nanopi-add-leds-pio-pins.patch

But the ones you (@Sfinx) removed above are from upstream sources: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi?h=linux-5.15.y

The one which do work in your case are from another patch: https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-5.15/patches.armbian/arm-dts-h3-nanopi-neo-Add-regulator-leds-mmc2.patch

Looking at this, it seems that there are 4 LED nodes defined for the NanoPi NEO, 2 from upstream sources and 2 from the Armbian patch. I do not see the pins assigned to the "status" LED, but the ones assigned to the "pwr" LED double with them for "led-1", which fits to the "EBUSY" error.

@Sfinx Could you test removing the "pwr" and "status" LED notes instead? If this works, we simply need to remove the additional two LEDs from the Armbian patch to solve this cleanly.

[Sfinx]

Sorry, I do not use any patches and recent kernels. The bug I've found related to doubling LED pins description in dts. I guess there must be only one pin per LED.

[MichaIng]

I guess there must be only one pin per LED.

Respectively one LED node per pin. Before I submit a PR to Armbian, I'd like to have it tested at least. Probably it is needed to remove the generic Allwinner H3 LED nodes instead of removing the NEO ones from the patch.

I'll provide the steps to edit the dtb later, for anyone with a NanoPi NEO to test.

[mhjessen]

Hmmm... I figured out to install 'device-tree-compiler' and can use dtc to export a copy of sun8i-h3-nanopi-neo.dtb to sun8i-h3-nanopi-neo.dts, but where to put the code from 'arm-dts-h3-nanopi-neo-Add-regulator-leds-mmc2.patch' is beyond me.

I'll keep following along here for the steps whenever you're ready.

[MichaIng]

Does this work (with the original device tree)?

mkdir -p /boot/overlay-user
dtc -I dts -O dtb -o /boot/overlay-user/dietpi-nanopi-neo-fix-leds.dtbo <<< '/dts-v1/;
/plugin/;
/ {
	compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
	fragment@0 {
		target-path = "/leds/pwr";
		__overlay__ {
			status = "disabled";
		};
	};
	fragment@1 {
		target-path = "/leds/status";
		__overlay__ {
			status = "disabled";
		};
	};
};'
G_CONFIG_INJECT 'user_overlays=' 'user_overlays=dietpi-nanopi-neo-fix-leds' /boot/dietpiEnv.txt

[mhjessen]

I tried these steps several times, but the LEDs still are not working, and the DietPi-Launcher DietPi-LED_control still does not work. I did notice that when I exported /boot/overlay-user/dietpi-nanopi-neo-fix-leds.dtbo to a dts to 'cat' it this was always missing; /plugin/;

[MichaIng]

Not sure about /plugin/;, but it is used in every device tree overlay source.

Can you check whether the content of the led-0 is identical to the one of the status node (aside of the latter being disabled when having the device tree overlay applied)? At and it did apply successfully, didn't it?

cat /proc/device-tree/leds/{pwr,status}/status; echo

shows disableddisabled?

If so, does it work the other way round, disabling led-0 and led-1 and hence using pwr and status?

dtc -I dts -O dtb -o /boot/overlay-user/dietpi-nanopi-neo-fix-leds.dtbo <<< '/dts-v1/;
/plugin/;
/ {
	compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
	fragment@0 {
		target-path = "/leds/led-0";
		__overlay__ {
			status = "disabled";
		};
	};
	fragment@1 {
		target-path = "/leds/led-1";
		__overlay__ {
			status = "disabled";
		};
	};
};'

If this doesn't work either, it seems disabling the nodes is not sufficient or does not work for those (the do not have a status attribute by default). As there is no way to actually remove nodes via overlay, then this can only be fixed with a patched base device tree, like @Sfinx did above: https://github.com/MichaIng/DietPi/issues/5401#issuecomment-1200119432 In this case, also here it would be interesting whether removing the pwr and status LEDs works, hence using the the upstream device tree and removing the added LEDs from the Armbian patch. I'll give instructions about how to do that.

[mhjessen]

Still no LEDs. Don't know why but your command never builds with/plugin/; Just an empty line. So I just ended up adding it manually.

cat /proc/device-tree/leds/{pwr,status}/status; echo cat: /proc/device-tree/leds/pwr/status: No such file or directory cat: /proc/device-tree/leds/status/status: No such file or directory

Here's what I found in /proc/device-tree/leds/

tree -a /proc/device-tree/leds/ /proc/device-tree/leds/ ├── compatible ├── led-0 │   ├── gpios │   ├── label │   ├── linux,default-trigger │   └── name ├── led-1 │   ├── default-state │   ├── gpios │   ├── label │   └── name ├── name ├── pinctrl-0 ├── pinctrl-names ├── pwr │   ├── gpios │   ├── label │   ├── linux,default-trigger │   └── name └── status ├── gpios ├── label ├── linux,default-trigger └── name

.../pwr/name cat /proc/device-tree/leds/pwr/name; echo pwr

.../pwr/linux,default-trigger cat /proc/device-tree/leds/pwr/linux,default-trigger; echo default-on

.../pwr/label cat /proc/device-tree/leds/pwr/label; echo nanopi:red:pwr

.../status/name cat /proc/device-tree/leds/status/name; echo status

.../status/linux,default-trigger cat /proc/device-tree/leds/status/linux,default-trigger; echo heartbeat

.../status/label cat /proc/device-tree/leds/status/label; echo nanopi:green:status

.../leds/led-0/name cat /proc/device-tree/leds/led-0/name; echo led-0

.../leds/led-0/linux,default-trigger cat /proc/device-tree/leds/led-0/linux,default-trigger; echo heartbeat

.../led-0/label cat /proc/device-tree/leds/led-0/label; echo nanopi:blue:status

.../leds/led-1/name cat /proc/device-tree/leds/led-1/name; echo led-1

.../leds/led-1/default-state <------ this one is different than the others cat /proc/device-tree/leds/led-1/default-state; echo on

.../led-1/label cat /proc/device-tree/leds/led-1/label; echo nanopi:green:pwr

[MichaIng]

Hmm, the status attributes did not even appear, as if the overlay was not successfully loaded.

Don't know why but your command never builds with /plugin/; Just an empty line. So I just ended up adding it manually.

How did you add it? It it compiles or decompiles without the `/plugin/;, then this is correct, I assume. I observe the same on a perfectly functional overlay, so I'd skip hacking it inside:

# dtc -I dtb -O dts /boot/overlays/micha-fb.dtbo
/dts-v1/;

/ {
        compatible = "brcm,bcm2835";

        fragment@0 {
                target = <0xffffffff>;

                __overlay__ {
                        status = "disabled";
                };
        };

        __fixups__ {
                fb = "/fragment@0:target:0";
        };
};

[mhjessen]

Still not working, and I think (hope) I'm following your instructions correctly.

I built dietpi-nanopi-neo-fix-leds.dtbo without 'hacking' it. I built micha-fb.dtbo as well. Both seem OK (I hope).

grep leds /var/log/syslog May 5 17:09:18 mhj-neo kernel: [ 3.414516] leds-gpio: probe of leds failed with error -16 May 5 17:21:44 mhj-neo kernel: [ 3.369238] leds-gpio: probe of leds failed with error -16

grep leds /var/log/kern.log May 5 17:09:18 mhj-neo kernel: [ 3.414516] leds-gpio: probe of leds failed with error -16 May 5 17:21:44 mhj-neo kernel: [ 3.369238] leds-gpio: probe of leds failed with error -16

tree -a /proc/device-tree/leds/

/proc/device-tree/leds/
├── compatible
├── led-0
│   ├── gpios
│   ├── label
│   ├── linux,default-trigger
│   └── name
├── led-1
│   ├── default-state
│   ├── gpios
│   ├── label
│   └── name
├── name
├── pinctrl-0
├── pinctrl-names
├── pwr
│   ├── gpios
│   ├── label
│   ├── linux,default-trigger
│   └── name
└── status
    ├── gpios
    ├── label
    ├── linux,default-trigger
    └── name

And in /sys/class ... drwxr-xr-x - root 5 May 17:21 ├── leds/

What's next?

[MichaIng]

Probably LED devices simply cannot be disabled via status attribute. I'll try to test on NanoPi M1.

[mhjessen]

Were your NanoPi M1 tests successful? Anything else I can try?

Thanks!