I didn’t know the realtek driver doesn’t offer a leds class to control though sysfs. It’s possible to code it of course so we can expose the register through sysfs. But honestly it is probably not worth the work.
Pull requests are welcome.
Nightly(26.05) destroyed my system 
After update everything was good but while i watching film coreelec restarted and error notice greet me on the home screen. Is any way to restore system because system is empty without all addons. Thanks for advice
Try to restart device.
wow. i update to stable build and now it it is ok…Pfuuh.Thank you…I was afraid that everythink is lost…Now i am going to backup 
2 Likes
I don’t want to bother you, but I think like @Mister-XY also, the current LED behaviour is not common.
The implementation is correct for the description you posted:
LED1 (green) is always stable ON , when any network connection is established.
LED2 (amber) flickers, when network activity occurs (Tx/Rx).
I tested the LED behaviour with CoreELEC on my N2 and it is exactly the same as with CE on C4.
But if I run Armbian (=Debian Buster) on my N2 then the LED behaviour is another:
LED1 (green) flickers if a 100Mbps network activity happens, and LED2 (amber) is OFF.
LED2 (amber) flickers if a 1000Mbps network activity happens, and LED1 (green) is OFF.
So you can see at a glance, what speed your connected network is (forget 10Mbps).
This is the nomal behaviour I know from all of my internet routers.
I think RTL821x_LCR should be changed to 0X6251 to get these behaviour (if I interpret the attached configuration table correctly).
But I don’t know how to make a pull request.
I looked at these issue just for fun, as you @TheCoolest and @Ray mentioned it maybe not worth to look at it. Someone has defined this LED behaviour years ago in the Kodi-sources, but again, it is not common to do it this way.
And this is also the behaviour, which is described by Hardkernel in the tech specs of N2 and C4.
Just my 2 cents…
The current settings comes from Amlogic kernel sources. I guess nobody cared about LEDs
I have watch in Linux Kernel from Hardkernel and found this
phy_write(phydev, RTL821x_LCR, 0XC171); /*led configuration*/
I see this also in your kernel
but on top, i see this
phy_write(phydev, RTL821x_LCR,
(1 << 6) | (1 << 9) // LED1 - GREEN (100Mbps)
| (1 << 13) | (1 << 14)); // LED2 - AMBER (1000Mbps)
i don’t know if this help.
It does not, we’re not going to add device specific changes to our kernel.
Is this seriously about the LED’s next to the ethernet port? Wow…who cares…
1 Like
I can see this is now about: who is taking care of specific devices code 
to wrap this up:
- kernel takes care about LEDs. Couldnt be changed easilly through fsys.
- Correct LED behauviour is described in manual of SBCs.
- While other distro honest that behauviour, some amlogic kernels works otherwise
- CE official statement is no custom-specific changes in amlogic kernel (so even PR@CE wont be accepted)
So, only solution I see is convince amlogic kernel develoers, to fix kernel prior to this issue (yes, when diagnostic HW doesnt work as its described in manual its something to have potentional to fix, although its quite marginal thing for someone. But not for someone, who is troubleshooting ethernet problems!). Which I guess could be harder than convince CE team.
But if all those statements are correct, maybe CE team could tell, from where they getting amlogic kernel? So curious people like pepeq could maybe do PR there? Any maaaybe, just maybe everyone would be happy
That’s not true, CE can and will accept PR if they are “usefull” and applicable. This “issue” is just at a low level to take care of now.
Feel free to make a PR adding a new parameter to config.ini what does feed cmdline. So the kernel driver can read the parameter and the register value can be customized. Like the “enable_wol” parameter. You see what this LED causes on work?
Even better would be to read the platform data from dtb.
Dtb is not possible as it get overwritten on update so user settings are lost.
At 1000Mbps:
Green = Link
Amber = Activity
At 100Mbps:
Green = Off
Amber = Link + Activity
At 10Mbps:
Green = Off
Amber = Activity
1 Like
Thx @TheCoolest.
I tried to build a CE version by my own, to get a feeling of the build process and learn something…
I did:
- install the required tools with apt (as shown in the LibreELEC-howto)
- git clone GitHub - CoreELEC/CoreELEC: A lightweight OS for KODI
- cd CoreELEC
- PROJECT=Amlogic-ng make
→ success, tarfile created and my C4 can be updated with the new tarfile.
Now I wanted to change the parameter for the LED configuration.
I found file realtek.c as
./build.CoreELEC-Amlogic-ng.arm-9.2-devel/linux-95e42ed8a96db8167f0a96f9502c15838f73336a/drivers/net/phy/realtek.c
I modified line 227 from
phy_write(phydev, RTL821x_LCR, 0XC171); /*led configuration*/
to
phy_write(phydev, RTL821x_LCR, 0X6251); /*led configuration*/
and did again
PROJECT=Amlogic-ng make
Again no error, but the created update tarfile didn’t change the LED behaviour.
Then I noticed, that file
./build.CoreELEC-Amlogic-ng.arm-9.2-devel/linux-95e42ed8a96db8167f0a96f9502c15838f73336a/drivers/net/phy/realtek.o
hasn’t changed the timestamp. So it was not compiled newly, although I changed the source file realtek.c.
Why?
What have I to do to change file realtek.c so that my modifications will get compiled?
I think the reason is that this file is contained in a tarfile, which is unpacked during make (blob?)
But how to circumvent this?
Sorry for the noob question, but this is new to me…
Create a script scripts/build_continue_stamp
#!/bin/bash
# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright (C) 2020-present Team CoreELEC (https://coreelec.tv)
. config/options "${1}"
if [ -z "$1" ]; then
echo "usage: $0 package_name[:<host|target|init|bootstrap>]"
exit 1
fi
if [ "${1%:*}" = "${1##*:}" ]; then
rm -f "${STAMPS}/${1%:*}/build_target"
else
rm -f "${STAMPS}/${1%:*}/build_${1##*:}"
fi
# if not removed it will grow
image_lzo="${BUILD}/${1%:*}*/arch/arm64/boot/Image.lzo"
if [ "${1%:*}" = "linux" -a -f ${image_lzo} ]; then
rm -f ${image_lzo}
fi
./scripts/build $1
if [ "${1%:*}" = "linux" -a -f ${image_lzo} ]; then
ls -l ${image_lzo}
fi
make it executable with
chmod 755 scripts/build_continue_stamp
then edit some file in linux folder and build it with
PROJECT=Amlogic-ng ./scripts/build_continue_stamp linux
When linux is build without errors run make again and update your device with .tar file.
2 Likes
Thx a lot for this, I will try it…
How has @TheCoolest changed the LED-configuration? Can/has he changed the config in the
blob-tarfile (?) directly?
It was changed in Kernel code. So it is still hardcoded and there is no user settings.
Thx, understood.
or you can create patch for the linux package with own changes.