Radxa zero v1.5 led control

is there any way to control the radxa’s leds just like v1.4 using:

sudo echo heartbeat > /sys/class/leds/radxa-zero:green/trigger

the only way that i found was using:

sudo mraa-gpio set 38 1 # 1 or 0

but this way i can’t pulse the leds like the heartbeat

My Radxa Zero runs headless, so I wished a heartbeat function too.
The mentioned Radxa v1.4 feature didnt work for me either.
So I created a solution for me (based on Radxa Debian Install+mraa tools) - which might work for you.
The small install script does everything in one step (code below):

# this script creates, installs and starts a simple Raxda Zero heartbeat service (a blinking green led)
# it has to be run with sudo/root - please check having mraa tools and a systemd environment before!

svname=“heartbeat.service”
svunit="/lib/systemd/system/$svname"
svscript="/usr/bin/heartbeat.sh"

# create the service script
echo “while true” > $svscript
echo “do” >> $svscript
echo " mraa-gpio set 38 0" >> $svscript
echo " sleep 1" >> $svscript
echo " mraa-gpio set 38 1" >> $svscript
echo " sleep .01" >> $svscript
echo “done” >> $svscript
chmod 755 $svscript

# create the systemd service/unit definition
echo “[Unit]” > $svunit
echo “Description=Radxa Zero Heartbeat” >> $svunit
echo “[Service]” >> $svunit
echo “ExecStart=sh $svscript” >> $svunit
echo “LogLevelMax=0” >> $svunit
echo “[Install]” >> $svunit
echo “WantedBy=multi-user.target” >> $svunit

# enable and start the heartbeat service
systemctl enable $svname
systemctl start $svname
systemctl status $svname

1 Like

i was using a python script to bypass the v1.5 led problem, but creating a services might be better

from datetime import datetime
import os

GPIOLed = “38” #led builtin
LedON = “sudo mraa-gpio set " + GPIOLed + " 1”
LedOFF = “sudo mraa-gpio set " + GPIOLed + " 0”

def LedBlink(timestoblink):
global LedOFF,LedON,GPIOLed
while timestoblink >= 0:
os.system(LedON)
os.system(LedOFF)
os.system(LedON)
timestoblink = timestoblink - 1

if name == “main”:
LedBlink(10)

i’ll try to rebuild the kernel changing the led gpio number, if i success i post here

i did it :slight_smile:

the problem was that the gpio number was wrong, i solved doing the following:

find the kernel folder, mine was: /boot/dtbs/5.10.69-13-amlogic-g104342c59952/amlogic
than:

cd /boot/dtbs/5.10.69-13-amlogic-g104342c59952/amlogic

make a backup:
mv -f meson-g12a-radxa-zero.dtb meson-g12a-radxa-zero.dtb.orig;

decopile the kernel:
dtc -I dtb -O dts meson-g12a-radxa-zero.dtb.orig -o meson-g12a-radxa-zero.dts > /dev/null 2>&1;

edit the file:
sudo nano meson-g12a-radxa-zero.dts

search the following:

	leds {
		compatible = "gpio-leds";

		led-green {
			label = "radxa-zero:green";
			gpios = <0x50 0x08 0x00>;
			linux,default-trigger = "heartbeat";
			default-state = "on";
		};
	};

change the gpios line to:

gpios = <0x50 0x0a 0x00>;

compile the kernel file:
dtc -I dts -O dtb /boot/dtbs/5.10.69-13-amlogic-g104342c59952/amlogic/meson-g12a-radxa-zero.dts -o /boot/dtbs/5.10.69-13-amlogic-g104342c59952/amlogic/meson-g12a-radxa-zero.dtb > /dev/null 2>&1;

change the permissions:
chmod +x /boot/dtbs/5.10.69-13-amlogic-g104342c59952/amlogic/meson-g12a-radxa-zero.dtb

reboot:
sudo reboot now

if every thing work as expected, remove the backup and the .dts file:
cd /boot/dtbs/5.10.69-13-amlogic-g104342c59952/amlogic rm meson-g12a-radxa-zero.dtb.orig rm meson-g12a-radxa-zero.dts

That’s great ! I understand that using physical GPIO 38 masks PWMAO_D, one of the possible pulse-width modulation outputs. @RadxaYuntian In this case, should we create a DT overlay for the LED control functionality ? I think I could do that and make a PR on the radxa overlays repo if it seems sensible.

We are at a transitional period between our existing build system and the new build system so the LED is not gonna be fixed soon (it is mostly a cosmetic feature).

However, since we have confirmed that we had switched GPIO pin for LED, my plan is to enable both GPIOAO_8 and GPIOAO_10 as power led in the base dts, so the default image will always have a working LED. Then we provide overlays to disable one LED for user who wish to use the incorrectly occupied GPIO pin.

I think this is a better compromise as there will be more people who peek the LED to check if the board is alive than who absolutely need that last GPIO pin.