[PATCH v2 0/2] arm64: dts: meson-gxbb-odroidc2: eFuse MAC address and LED properties

[PATCH v2 0/2] arm64: dts: meson-gxbb-odroidc2: eFuse MAC address and LED properties

[Fil Dunsky via B4 Relay]

Two small device-tree updates for the Hardkernel ODROID-C2, found while
adding OpenWrt support for the board.

Patch 1 wires the eth_mac eFuse nvmem cell (already described in
meson-gx.dtsi, but so far unused) to the Ethernet controller, narrowed
to the 6 bytes of the address, so the kernel reads the factory MAC
address itself instead of relying on the bootloader or a random
fallback.

Patch 2 converts the blue status LED to the standard color/function
properties.

Both verified on ODROID-C2 hardware and rechecked against this tree
with CHECK_DTBS=y W=1.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
Changes in v2:
- Patch 1: narrow the eth_mac cell to 6 bytes for this board.  The
  16-byte cell from meson-gx.dtsi is rejected by
  of_get_mac_address_nvmem(), so v1 only appeared to work because the
  bootloader had already fixed up local-mac-address.  Reported by the
  Sashiko AI review.
- Patch 1: describe the actual test setup in the commit message.
- Link to v1: https://patch.msgid.link/20261011-odroidc2-dts-v1-0-f9f0e779af88@gmail.com

To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Kevin Hilman <khilman@baylibre.com>
To: Jerome Brunet <jbrunet@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-kernel@vger.kernel.org

---
Fil Dunsky (2):
      arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
      arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
---
base-commit: a5ebb76233b79db01e82e061173cb73c6d2b5c6b
change-id: 20261011-odroidc2-dts-53a0b62433c1

Best regards,
--  
Fil Dunsky <filipp.dunsky@gmail.com>

[PATCH v2 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

The vendor programs a unique factory MAC address into the SoC eFuse at
offset 0x34, where meson-gx.dtsi already describes the eth_mac nvmem
cell.  Reference the cell from the Ethernet controller so the kernel
picks up the factory address itself instead of depending on the
bootloader to populate local-mac-address, or falling back to a random
one when it does not.

The cell is 16 bytes long in meson-gx.dtsi, while
of_get_mac_address_nvmem() only accepts a cell of exactly ETH_ALEN
bytes, so narrow it to the 6 bytes of the address for this board.

Tested on an ODROID-C2 with the bootloader's MAC fixup out of the way
(ethernet0 alias removed from the DTB): with the 16-byte cell the
driver falls back to a random address, with the 6-byte cell eth0 comes
up with the factory address from the eFuse.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 5943bc810..3b74528ef 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -223,6 +223,10 @@ &cec_AO {
 	hdmi-phandle = <&hdmi_tx>;
 };
 
+&eth_mac {
+	reg = <0x34 0x6>;
+};
+
 &ethmac {
 	status = "okay";
 	pinctrl-0 = <&eth_rgmii_pins>;
@@ -230,6 +234,9 @@ &ethmac {
 	phy-handle = <&eth_phy0>;
 	phy-mode = "rgmii";
 
+	nvmem-cells = <&eth_mac>;
+	nvmem-cell-names = "mac-address";
+
 	amlogic,tx-delay-ns = <2>;
 
 	mdio {

-- 
2.53.0

Re: [PATCH v2 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[Martin Blumenstingl]

Thank you for your patch!

On Sun, Oct 11, 2026 at 8:31 PM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:
[...]
> +&eth_mac {
> +       reg = <0x34 0x6>;
> +};
Question to Neil: should the eth_mac node be moved from meson-gx.dtsi
to meson-gxbb-odroidc2.dts?
Odroid-C2 would be the only board using it and u-boot seems to derive
MAC from SoC chip ID/serial number instead of reading it from eFuse
(so I'm not sure about the status of MAC address in eFuse on most
boards).

Re: [PATCH v2 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[Fil Dunsky]

Hi Martin,

On Sun, Oct 11, 2026 at 10:49 PM Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> Question to Neil: should the eth_mac node be moved from meson-gx.dtsi
> to meson-gxbb-odroidc2.dts?
> Odroid-C2 would be the only board using it and u-boot seems to derive
> MAC from SoC chip ID/serial number instead of reading it from eFuse
> (so I'm not sure about the status of MAC address in eFuse on most
> boards).

Some data points in case they help Neil decide:

- Mainline U-Boot does read the eFuse first on the GX reference board
  files: board/amlogic/p200 (used by odroid-c2_defconfig), p201, p212
  and q200 all call meson_sm_read_efuse(EFUSE_MAC_OFFSET = 52, 6 bytes)
  and only fall back to meson_generate_serial_ethaddr() when that does
  not give a valid address.

- On my ODROID-C2 the eFuse at 0x34 holds 00:1e:06:37:d9:37, i.e.
  Hardkernel's OUI, and that is what U-Boot passes on today.

I can't say how many other GX boards have the eFuse programmed, so I
have no strong opinion on where the node should live. Happy to respin
with the cell moved into the board file if that is preferred.

Thanks for the review,
Fil

Re: [PATCH v2 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[Neil Armstrong]

On 10/11/26 22:49, Martin Blumenstingl wrote:
> Thank you for your patch!
> 
> On Sun, Oct 11, 2026 at 8:31 PM Fil Dunsky via B4 Relay
> <devnull+filipp.dunsky.gmail.com@kernel.org> wrote:
> [...]
>> +&eth_mac {
>> +       reg = <0x34 0x6>;
>> +};
> Question to Neil: should the eth_mac node be moved from meson-gx.dtsi
> to meson-gxbb-odroidc2.dts?
> Odroid-C2 would be the only board using it and u-boot seems to derive
> MAC from SoC chip ID/serial number instead of reading it from eFuse
> (so I'm not sure about the status of MAC address in eFuse on most
> boards).

Odroid C2 has a custom efuse mapping so it can't be used on other boards.

Neil

Re: [PATCH v2 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[Neil Armstrong]

On 10/11/26 20:31, Fil Dunsky via B4 Relay wrote:
> From: Fil Dunsky <filipp.dunsky@gmail.com>
> 
> The vendor programs a unique factory MAC address into the SoC eFuse at
> offset 0x34, where meson-gx.dtsi already describes the eth_mac nvmem
> cell.  Reference the cell from the Ethernet controller so the kernel
> picks up the factory address itself instead of depending on the
> bootloader to populate local-mac-address, or falling back to a random
> one when it does not.
> 
> The cell is 16 bytes long in meson-gx.dtsi, while
> of_get_mac_address_nvmem() only accepts a cell of exactly ETH_ALEN
> bytes, so narrow it to the 6 bytes of the address for this board.
> 
> Tested on an ODROID-C2 with the bootloader's MAC fixup out of the way
> (ethernet0 alias removed from the DTB): with the 16-byte cell the
> driver falls back to a random address, with the 6-byte cell eth0 comes
> up with the factory address from the eFuse.
> 
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
> ---
>   arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 5943bc810..3b74528ef 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -223,6 +223,10 @@ &cec_AO {
>   	hdmi-phandle = <&hdmi_tx>;
>   };
>   
> +&eth_mac {
> +	reg = <0x34 0x6>;
> +};
> +
>   &ethmac {
>   	status = "okay";
>   	pinctrl-0 = <&eth_rgmii_pins>;
> @@ -230,6 +234,9 @@ &ethmac {
>   	phy-handle = <&eth_phy0>;
>   	phy-mode = "rgmii";
>   
> +	nvmem-cells = <&eth_mac>;
> +	nvmem-cell-names = "mac-address";
> +
>   	amlogic,tx-delay-ns = <2>;
>   
>   	mdio {
> 

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Thanks,
Neil

[PATCH v2 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Replace the legacy label on the blue status LED with the standard
color and function properties, following what the other Amlogic boards
already do.  The LED then shows up with a generic blue:status name
instead of the board-specific c2:blue:alive.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 3b74528ef..722dc906d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -9,6 +9,7 @@
 
 #include "meson-gxbb.dtsi"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/sound/meson-aiu.h>
 
 / {
@@ -51,7 +52,8 @@ usb_otg_pwr: regulator-usb-pwrs {
 	leds {
 		compatible = "gpio-leds";
 		led-blue {
-			label = "c2:blue:alive";
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "heartbeat";
 			default-state = "off";

-- 
2.53.0

Re: [PATCH v2 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

[Martin Blumenstingl]

On Sun, Oct 11, 2026 at 8:31 PM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:
>
> From: Fil Dunsky <filipp.dunsky@gmail.com>
>
> Replace the legacy label on the blue status LED with the standard
> color and function properties, following what the other Amlogic boards
> already do.  The LED then shows up with a generic blue:status name
> instead of the board-specific c2:blue:alive.
>
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>