Several Rockchip rk35xx boards carry on-board Realtek RTL8125 2.5GbE
NICs whose PCI function nodes are not described in the DT. Describing
them allows for stable ethernetN aliases (matching the GMAC alias
convention on these boards) and lets U-Boot's fdt_fixup_ethernet()
inject mac-address properties from its ethaddr/ethNaddr env, so MACs
stay stable across boots and U-Boot and kernel MAC match.
Tested on a NanoPC-T6: /sys/bus/pci/devices/0004:41:00.0/of_node ->
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0 and
u-boot correctly adds local-mac-address property there which is
correctly picked up kernel-side:
=> setenv eth1addr 8e:b4:90:66:66:66
=> boot
...
# readlink -f /sys/bus/pci/devices/0004:41:00.0/of_node
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0
# xxd /sys/bus/pci/devices/0004:41:00.0/of_node/local-mac-address
00000000: 8eb4 9066 6666 ...fff
# ip link show dev end1 | grep ether
link/ether 8e:b4:90:66:66:66 brd ff:ff:ff:ff:ff:ff
Patch 1 adds a DT binding for Realtek RTL8125 family PCIe Ethernet
controllers.
Patch 2-7 describes the on-board RTL8125 function nodes on a few
Rockchip boards.
---
Changes in v5:
- binding: reword commit message: pci10ec,8125 is already covered by
dtschema pci-device.yaml; the binding is added only to validate the
ethernet-controller properties on these nodes (local-mac-address,
nvmem-cells, et al) (ref Krzysztof, Heiner).
- boards: add a few more Rockchip boards with RTL8125's.
- Link to v4: https://patch.msgid.link/20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net
Changes in v4:
- binding: simplify the binding YAML ref Sashiko's and Krzysztof's
reviews
- binding: describe only the RTL8125 + rename to match ref Heiner's
review.
- dt: fix the bus-range according to Sashiko's review.
- Link to v3: https://patch.msgid.link/20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-0-8a8857b39daf@pardini.net
Changes in v3:
- new patch: add a DT binding for Realtek r8169 family PCIe Ethernet
controllers, per Sebastian Reichel's review (the "pciVVVV,DDDD" OF
spelling still needs a binding when used in a board DT).
- new patch for Rock5 series, and include a brief rationale in each.
- retitle the series, since it now covers a few boards and a binding
rather than just DeviceTree changes for the NanoPC-T6.
- drop the v2 "rename vcc3v3_pcie2x1l0 regulator" patch from this
series; it will be sent separately as it is not relevant to this.
- Link to v2: https://patch.msgid.link/20260529-rk3588-dts-rtl-eth-describe-dt-alias-v2-0-49700248143f@pardini.net
Changes in v2:
- fix: pcie2x1l0, not pcie2x1l1; indirectly caught by Sashiko's review [1]
- while-at-it: rename regulator vcc3v3_pcie2x1l0 to l1
- Link to v1: https://patch.msgid.link/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7@pardini.net
[1] https://sashiko.dev/#/patchset/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7%40pardini.net
To: Heiner Kallweit <hkallweit1@gmail.com>
To: nic_swsd@realtek.com
To: Andrew Lunn <andrew+netdev@lunn.ch>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Sebastian Reichel <redacted>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Ricardo Pardini <redacted>
---
Ricardo Pardini (7):
dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPC-T6
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on ROCK 5 family
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on CM3588-NAS
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPi R5S
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPi R6C
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on ROCK 5 ITX
.../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 30 +++++++++++++++
.../rockchip/rk3588-friendlyelec-cm3588-nas.dts | 21 +++++++++++
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 +++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 30 +++++++++++++++
.../boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 15 ++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts | 18 +++++++++
.../arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 21 +++++++++++
9 files changed, 209 insertions(+)
---
base-commit: df2908090cda368b01ff43709f51890076c56157
change-id: 20260524-rk3588-dts-rtl-eth-describe-dt-alias-c1ed187b7c50
Best regards,
--
Ricardo Pardini [off-list ref]
From: Ricardo Pardini <redacted>
Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
controller. As a PCIe device, its "pci10ec,8125" compatible is the
Open Firmware spelling auto-derived from its PCI-SIG vendor/device IDs
and is already covered by the generic dtschema pci-device.yaml. The
compatible itself therefore needs no binding to be valid.
A dedicated binding is needed because board DTs describe these
soldered function nodes in order to attach ethernet-controller
properties to them: a placeholder local-mac-address that the bootloader
fills in today, and potentially nvmem-cells, phy-handle, etc. in the
future. This binding references ethernet-controller.yaml so those
properties are validated on the RTL8125 PCI function nodes.
Suggested-by: Sebastian Reichel <redacted>
Signed-off-by: Ricardo Pardini <redacted>
---
.../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 44 insertions(+)
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125 NICs
behind pcie2x1l0 and pcie2x1l2.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can fill in the MAC
from its ethaddr/eth1addr env. The on-NIC EEPROMs on this board are
not pre-programmed with a unique MAC, so this gives a stable MAC
across boots that both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
From: Ricardo Pardini <redacted>
The Radxa ROCK 5B / 5B+ / 5T all carry on-board Realtek RTL8125 NICs.
Describe the fixed function nodes and attach ethernet0/ethernet1 aliases,
so that U-Boot's fdt_fixup_ethernet() can fill in the MAC from its
ethaddr/eth1addr env, for stable MACs across boots that both U-Boot
and the kernel agree on.
The RTL8125 on pcie2x1l2 is shared by all three variants. The ROCK 5T
additionally describes pcie2x1l1 with its second RTL8125.
Signed-off-by: Ricardo Pardini <redacted>
---
.../arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts | 18 ++++++++++++++++++
2 files changed, 33 insertions(+)
From: Ricardo Pardini <redacted>
The FriendlyElec CM3588-NAS carrier carries an on-board Realtek
RTL8125 NIC behind pcie2x1l2.
Describe the fixed function node and attach an ethernet0 alias in the
NAS carrier .dts (not the SoM dtsi, as the RTL8125 sits on the
carrier), so that U-Boot's fdt_fixup_ethernet() can inject a
mac-address from its ethaddr env, for a stable MAC across boots that
both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
.../dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPi R5S (rk3568) carries two on-board Realtek
RTL8125 NICs behind pcie2x1 and pcie3x1, alongside the existing gmac0
RGMII PHY.
Describe the fixed function nodes and attach ethernet1/ethernet2
aliases (ethernet0 stays mapped to gmac0), so that U-Boot's
fdt_fixup_ethernet() can inject mac-address properties from its
eth1addr/eth2addr env, for stable MACs across boots that both U-Boot
and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPi R6C carries one on-board Realtek RTL8125 NIC
(the LAN port; WAN uses the on-SoC gmac1 RGMII PHY) behind pcie2x1l1.
Describe the fixed function node and attach an ethernet1 alias
(ethernet0 stays mapped to gmac1), so that U-Boot's fdt_fixup_ethernet()
can inject a mac-address from its eth1addr env, for a stable MAC
across boots that both U-Boot and the kernel agree on.
The function node is added in this .dts (not the shared
rk3588s-nanopi-r6.dtsi), since on the R6C the dtsi's second
RTL8125-capable lane is empty compared to the R6S.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
From: Ricardo Pardini <redacted>
The Radxa ROCK 5 ITX carries two on-board Realtek RTL8125 NICs behind
pcie2x1l1 and pcie2x1l2.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can inject mac-address
properties from its ethaddr/eth1addr env, for stable MACs across
boots that both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
From: Diederik de Haas <hidden> Date: 2026-09-11 09:52:41
On Thu Sep 10, 2026 at 10:07 PM CEST, Ricardo Pardini via B4 Relay wrote:
quoted hunk
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125 NICs
behind pcie2x1l0 and pcie2x1l2.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can fill in the MAC
from its ethaddr/eth1addr env. The on-NIC EEPROMs on this board are
not pre-programmed with a unique MAC, so this gives a stable MAC
across boots that both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
Described on page 23 of the schematic titled '2.5G Ethernet B' and ``U12``
(ie RTL8125BG) is connected to LAN2 which has ``ETH2`` as label on the case.
Described on page 22 of the schematic titled '2.5G Ethernet A' and ``U10``
(ie RTL8125BG) is connected to LAN1 which has ``ETH1`` as label on the case.
So this results in:
ETH1 -> rtl_eth1
ETH2 -> rtl_eth0
This sounds like a recipe for confusion and/or potential future mistakes.
I think using ``rtl_eth1`` and ``rtl_eth2`` would be less confusing, but
I'm fine with another construct which achieves a similar thing.
Cheers,
Diederik
On Thu Sep 10, 2026 at 10:07 PM CEST, Ricardo Pardini via B4 Relay wrote:
quoted
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125 NICs
behind pcie2x1l0 and pcie2x1l2.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can fill in the MAC
from its ethaddr/eth1addr env. The on-NIC EEPROMs on this board are
not pre-programmed with a unique MAC, so this gives a stable MAC
across boots that both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
The new pinctrl reference is ``pcie_25glan_perstb_b_pin``, so this patch needs
to be rebased.
Indeed; I sent v5 vs v7.3-rc2 which doesn't have your recent series
fixing those. I've rebased onto next-20260910 which does, will send in a
v6 - but it's really just fuzz/context changes.
I'll wait a bit until Heiner/Krysztof/Heiko chime in ref the binding and
its wording as that has been contentious in the previous versions. And
who knows what Sashiko will find this time.
Described on page 23 of the schematic titled '2.5G Ethernet B' and ``U12``
(ie RTL8125BG) is connected to LAN2 which has ``ETH2`` as label on the case.
Described on page 22 of the schematic titled '2.5G Ethernet A' and ``U10``
(ie RTL8125BG) is connected to LAN1 which has ``ETH1`` as label on the case.
So this results in:
ETH1 -> rtl_eth1
ETH2 -> rtl_eth0
This sounds like a recipe for confusion and/or potential future mistakes.
I think using ``rtl_eth1`` and ``rtl_eth2`` would be less confusing, but
I'm fine with another construct which achieves a similar thing.
Yeah, that will result in aliases `ethernet0 = &rtl_eth1;` and
`ethernet1 = &rtl_eth2;`. It could also be `rtl_lan1`/`rtl_lan2`, or as
the schematics seems to to use the `_b` suffix, just `rtl_lan` and
`rtl_lan_b`, I don't mind. Raise if you do, otherwise I'll send v6 as
you suggested.
Userspace will be off-by-one vs the printed case labels, thus _some_
confusion will remain, but it's already better than the current
enP2p33s0/enP4p65s0.
From: Diederik de Haas <hidden> Date: 2026-09-11 13:04:45
On Fri Sep 11, 2026 at 2:19 PM CEST, Ricardo Pardini wrote:
On 11/09/2026 11:52, Diederik de Haas wrote:
quoted
On Thu Sep 10, 2026 at 10:07 PM CEST, Ricardo Pardini via B4 Relay wrote:
quoted
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125 NICs
behind pcie2x1l0 and pcie2x1l2.
Forgot to mention: thanks for this series :-)
quoted
quoted
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can fill in the MAC
from its ethaddr/eth1addr env. The on-NIC EEPROMs on this board are
not pre-programmed with a unique MAC, so this gives a stable MAC
across boots that both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
The new pinctrl reference is ``pcie_25glan_perstb_b_pin``, so this patch needs
to be rebased.
Indeed; I sent v5 vs v7.3-rc2 which doesn't have your recent series
fixing those. I've rebased onto next-20260910 which does, will send in a
v6 - but it's really just fuzz/context changes.
I'll wait a bit until Heiner/Krysztof/Heiko chime in ref the binding and
its wording as that has been contentious in the previous versions. And
who knows what Sashiko will find this time.
Described on page 23 of the schematic titled '2.5G Ethernet B' and ``U12``
(ie RTL8125BG) is connected to LAN2 which has ``ETH2`` as label on the case.
Described on page 22 of the schematic titled '2.5G Ethernet A' and ``U10``
(ie RTL8125BG) is connected to LAN1 which has ``ETH1`` as label on the case.
So this results in:
ETH1 -> rtl_eth1
ETH2 -> rtl_eth0
This sounds like a recipe for confusion and/or potential future mistakes.
I think using ``rtl_eth1`` and ``rtl_eth2`` would be less confusing, but
I'm fine with another construct which achieves a similar thing.
Yeah, that will result in aliases `ethernet0 = &rtl_eth1;` and
`ethernet1 = &rtl_eth2;`. It could also be `rtl_lan1`/`rtl_lan2`, or as
the schematics seems to to use the `_b` suffix, just `rtl_lan` and
`rtl_lan_b`, I don't mind. Raise if you do, otherwise I'll send v6 as
you suggested.
I'm not a fan of the `_b` suffix (also not in the schematic; without an
`_a` suffix). Do the aliases have to be 0-based? If not, then `ethernet1`
and `ethernet2` would be my preferred solution. If it needs to be 0-based
then the off-by-one 'confusion' seems like the best solution.
Userspace will be off-by-one vs the printed case labels, thus _some_
confusion will remain, but it's already better than the current
enP2p33s0/enP4p65s0.
Indeed :-)
I triple checked whether my findings were correct before responding.
Thanks to your series, I had a look at NanoPi R5S and found a few issues.
There it's even worse:
PCB/schematic: LAN1=GbE and 'WAN' on the case; LAN2=2.5GbE and LAN1 on the
case; LAN3=2.5GbE and LAN2 on the case.
And those result in `end0`, `enp1s0` and `enP1p17s0` respectively :-P
Cheers,
Diederik
Am Donnerstag, 10. September 2026, 22:07:51 Mitteleuropäische Sommerzeit schrieb Ricardo Pardini via B4 Relay:
From: Ricardo Pardini <redacted>
Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
controller. As a PCIe device, its "pci10ec,8125" compatible is the
Open Firmware spelling auto-derived from its PCI-SIG vendor/device IDs
and is already covered by the generic dtschema pci-device.yaml. The
compatible itself therefore needs no binding to be valid.
A dedicated binding is needed because board DTs describe these
soldered function nodes in order to attach ethernet-controller
properties to them: a placeholder local-mac-address that the bootloader
fills in today, and potentially nvmem-cells, phy-handle, etc. in the
future. This binding references ethernet-controller.yaml so those
properties are validated on the RTL8125 PCI function nodes.
Suggested-by: Sebastian Reichel <redacted>
Signed-off-by: Ricardo Pardini <redacted>
this needs to go through the network tree I think and their processes
are heavily automated, so this should be sent separately.
Heiko
On Thu, 10 Sep 2026 22:07:51 +0200, Ricardo Pardini wrote:
Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
controller. As a PCIe device, its "pci10ec,8125" compatible is the
Open Firmware spelling auto-derived from its PCI-SIG vendor/device IDs
and is already covered by the generic dtschema pci-device.yaml. The
compatible itself therefore needs no binding to be valid.
A dedicated binding is needed because board DTs describe these
soldered function nodes in order to attach ethernet-controller
properties to them: a placeholder local-mac-address that the bootloader
fills in today, and potentially nvmem-cells, phy-handle, etc. in the
future. This binding references ethernet-controller.yaml so those
properties are validated on the RTL8125 PCI function nodes.
Suggested-by: Sebastian Reichel <redacted>
Signed-off-by: Ricardo Pardini <redacted>
---
.../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 44 insertions(+)
Hi Ricardo,
On Thu, 10 Sept 2026 at 22:08, Ricardo Pardini via B4 Relay
[off-list ref] wrote:
Several Rockchip rk35xx boards carry on-board Realtek RTL8125 2.5GbE
NICs whose PCI function nodes are not described in the DT. Describing
them allows for stable ethernetN aliases (matching the GMAC alias
convention on these boards) and lets U-Boot's fdt_fixup_ethernet()
inject mac-address properties from its ethaddr/ethNaddr env, so MACs
stay stable across boots and U-Boot and kernel MAC match.
Tested on a NanoPC-T6: /sys/bus/pci/devices/0004:41:00.0/of_node ->
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0 and
u-boot correctly adds local-mac-address property there which is
correctly picked up kernel-side:
Have you tested this at 2.5Gbps? With which firmware?
I am asking because I have problems at 2.5Gbps using the firmware from
linux-firmware (on a different platform, though)
https://lore.kernel.org/CAMuHMdXPAeHoeaQbM9rXbXukoMbFV+0k28n6sRMw8XF8720WUA@mail.gmail.com
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
From: Diederik de Haas <hidden> Date: 2026-09-23 17:15:58
Hi,
On Thu Sep 10, 2026 at 10:07 PM CEST, Ricardo Pardini via B4 Relay wrote:
quoted hunk
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPi R5S (rk3568) carries two on-board Realtek
RTL8125 NICs behind pcie2x1 and pcie3x1, alongside the existing gmac0
RGMII PHY.
Describe the fixed function nodes and attach ethernet1/ethernet2
aliases (ethernet0 stays mapped to gmac0), so that U-Boot's
fdt_fixup_ethernet() can inject mac-address properties from its
eth1addr/eth2addr env, for stable MACs across boots that both U-Boot
and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
I did not do anything (explicitly) in U-Boot, but it seems it created a
non-random MAC address for end0 and end1 ... and then stopped.
AFAIK gmac0=end0 already had a non-random MAC address and I hoped/expected
it would create non-random addresses for end1 and end2, which would've made
the above warning go away too.
Is this an issue with this patch, with U-Boot or me?
Full details:
https://paste.sr.ht/~diederik/8ae7d354985afcd1c3464e3a4ad81da1b4442364
Side note:
I wonder how 'random' those addresses are as during testing ``ssh rock5b``
landed me on another device (NanoPC-T6 Plus), f.e. My router has DHCP
reservations based on MAC addresses and it looks like it got confused ;-)
Cheers,
Diederik
Hi,
On Thu Sep 10, 2026 at 10:07 PM CEST, Ricardo Pardini via B4 Relay wrote:
quoted
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPi R5S (rk3568) carries two on-board Realtek
RTL8125 NICs behind pcie2x1 and pcie3x1, alongside the existing gmac0
RGMII PHY.
Describe the fixed function nodes and attach ethernet1/ethernet2
aliases (ethernet0 stays mapped to gmac0), so that U-Boot's
fdt_fixup_ethernet() can inject mac-address properties from its
eth1addr/eth2addr env, for stable MACs across boots that both U-Boot
and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
I did not do anything (explicitly) in U-Boot, but it seems it created a
non-random MAC address for end0 and end1 ... and then stopped.
AFAIK gmac0=end0 already had a non-random MAC address and I hoped/expected
it would create non-random addresses for end1 and end2, which would've made
the above warning go away too.
Is this an issue with this patch, with U-Boot or me?
Hi Diederik, in this case (3 ethernet's) I think it's down to U-boot.
Check the output of `printenv` in u-boot, you'll probably find it only
pre-computes 2 MAC addresses, and doesn't feed the ethernet2 alias
during its fdt_fixup_ethernet().
Try doing `setenv eth2addr xx:xx...` in u-boot before booting -- it
should work. I think that's what I did when testing the R5S with this
series, but it has been a very long time ago.
One way around this (without u-boot) would be to use Alexey's series [1]
which could compute as many MACs as needed out of the CPU serialnum -
but that also won't work as-sent vs rk356x, I believe he's checking an
alternative proposed.
[1]
https://lore.kernel.org/linux-rockchip/20260902-rk3576-otp-cpuid-mac-v2-0-e4b7fe2ab13f@flipper.net/
Full details:
https://paste.sr.ht/~diederik/8ae7d354985afcd1c3464e3a4ad81da1b4442364
Side note:
I wonder how 'random' those addresses are as during testing ``ssh rock5b``
landed me on another device (NanoPC-T6 Plus), f.e. My router has DHCP
reservations based on MAC addresses and it looks like it got confused ;-)
Interesting. I dunno what seed is used, as I've been fully set on making
it non-random, but I wouldn't discard the possibility of conflicts
across different machines. One more reason to have this series ;-)
I'll soon send a v6 to linux-rockchip/dt (with small fixes Sashiko found
to DTs, and without the binding) and split a single-patch v1 to net-next
with only the binding, collecting Rob's review. If and when those land,
we'd have open road both for u-boot local-mac-address and Alexey's
nvmem-cells for the RTLs.
Regards,
Ricardo
From: Diederik de Haas <hidden> Date: 2026-09-23 18:42:23
Hi Ricardo,
On Wed Sep 23, 2026 at 8:02 PM CEST, Ricardo Pardini wrote:
On 23/09/2026 19:15, Diederik de Haas wrote:
quoted
On Thu Sep 10, 2026 at 10:07 PM CEST, Ricardo Pardini via B4 Relay wrote:
quoted
From: Ricardo Pardini <redacted>
The FriendlyElec NanoPi R5S (rk3568) carries two on-board Realtek
RTL8125 NICs behind pcie2x1 and pcie3x1, alongside the existing gmac0
RGMII PHY.
Describe the fixed function nodes and attach ethernet1/ethernet2
aliases (ethernet0 stays mapped to gmac0), so that U-Boot's
fdt_fixup_ethernet() can inject mac-address properties from its
eth1addr/eth2addr env, for stable MACs across boots that both U-Boot
and the kernel agree on.
Signed-off-by: Ricardo Pardini <redacted>
---
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
I did not do anything (explicitly) in U-Boot, but it seems it created a
non-random MAC address for end0 and end1 ... and then stopped.
AFAIK gmac0=end0 already had a non-random MAC address and I hoped/expected
it would create non-random addresses for end1 and end2, which would've made
the above warning go away too.
Is this an issue with this patch, with U-Boot or me?
Hi Diederik, in this case (3 ethernet's) I think it's down to U-boot.
Check the output of `printenv` in u-boot, you'll probably find it only
pre-computes 2 MAC addresses, and doesn't feed the ethernet2 alias
during its fdt_fixup_ethernet().
It's indeed what I suspected. I don't dabble in U-Boot very often, but I seem
to recall it has fixed room for 2 MAC addresses and that would explain the
symptom/problem I described.
Try doing `setenv eth2addr xx:xx...` in u-boot before booting -- it
should work. I think that's what I did when testing the R5S with this
series, but it has been a very long time ago.
Haha! You linked in that thread to Heiko's RK356X OTP patch set and I tested
that hoping/assuming that could help with generating unique MAC addresses.
I see (or think I do) pieces of the puzzle, but I don't know how they all
fit together.
quoted
Full details:
https://paste.sr.ht/~diederik/8ae7d354985afcd1c3464e3a4ad81da1b4442364
Side note:
I wonder how 'random' those addresses are as during testing ``ssh rock5b``
landed me on another device (NanoPC-T6 Plus), f.e. My router has DHCP
reservations based on MAC addresses and it looks like it got confused ;-)
Interesting. I dunno what seed is used, as I've been fully set on making
it non-random, but I wouldn't discard the possibility of conflicts
across different machines. One more reason to have this series ;-)
They all use the RTL8125BG and I suspect that plays a role in it.
I'll soon send a v6 to linux-rockchip/dt (with small fixes Sashiko found
to DTs, and without the binding) and split a single-patch v1 to net-next
with only the binding, collecting Rob's review. If and when those land,
we'd have open road both for u-boot local-mac-address and Alexey's
nvmem-cells for the RTLs.
Hi Ricardo,
On Thu, 10 Sept 2026 at 22:08, Ricardo Pardini via B4 Relay
[off-list ref] wrote:
quoted
Several Rockchip rk35xx boards carry on-board Realtek RTL8125 2.5GbE
NICs whose PCI function nodes are not described in the DT. Describing
them allows for stable ethernetN aliases (matching the GMAC alias
convention on these boards) and lets U-Boot's fdt_fixup_ethernet()
inject mac-address properties from its ethaddr/ethNaddr env, so MACs
stay stable across boots and U-Boot and kernel MAC match.
Tested on a NanoPC-T6: /sys/bus/pci/devices/0004:41:00.0/of_node ->
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0 and
u-boot correctly adds local-mac-address property there which is
correctly picked up kernel-side:
Hi Geert, yes, the RTL8125's on those boards work at 2.5gbps just fine
(both with and without the fixed-function nodes in this series). They do
get quite warm at 2.5gbps. I'm using one of those el-cheapo 8-port
2.5gbps switches.
Currently:
[ 3.254450] r8169 0002:21:00.0 eth0: RTL8125B, 8e:b4:90:97:32:30, XID
641, IRQ 124
...
[ 10.480872] r8169 0002:21:00.0 end0: Link is Up - 2.5Gbps/Full - flow
control rx/tx
# sensors r8169_2_2100:00-mdio-0
r8169_2_2100:00-mdio-0
Adapter: MDIO adapter
temp1: +52.0°C (high = +120.0°C)
I'm using whatever is in Armbian's armbian-firmware package:
# ethtool -i end0 | grep -i firmware
firmware-version: rtl8125b-2_0.0.2 07/13/20
# sha256sum /lib/firmware/rtl_nic/rtl8125b-2.fw
529bf1c25c97ff52b401090d00ff89cc22351012336e5a0c9662728a3ee909ef
/lib/firmware/rtl_nic/rtl8125b-2.fw
mvg,
Ricardo
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Ricardo,
On Wed, 23 Sept 2026 at 20:49, Ricardo Pardini [off-list ref] wrote:
On 22/09/2026 11:17, Geert Uytterhoeven wrote:
quoted
On Thu, 10 Sept 2026 at 22:08, Ricardo Pardini via B4 Relay
[off-list ref] wrote:
quoted
Several Rockchip rk35xx boards carry on-board Realtek RTL8125 2.5GbE
NICs whose PCI function nodes are not described in the DT. Describing
them allows for stable ethernetN aliases (matching the GMAC alias
convention on these boards) and lets U-Boot's fdt_fixup_ethernet()
inject mac-address properties from its ethaddr/ethNaddr env, so MACs
stay stable across boots and U-Boot and kernel MAC match.
Tested on a NanoPC-T6: /sys/bus/pci/devices/0004:41:00.0/of_node ->
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0 and
u-boot correctly adds local-mac-address property there which is
correctly picked up kernel-side:
Hi Geert, yes, the RTL8125's on those boards work at 2.5gbps just fine
(both with and without the fixed-function nodes in this series). They do
get quite warm at 2.5gbps. I'm using one of those el-cheapo 8-port
2.5gbps switches.
Currently:
[ 3.254450] r8169 0002:21:00.0 eth0: RTL8125B, 8e:b4:90:97:32:30, XID
641, IRQ 124
...
[ 10.480872] r8169 0002:21:00.0 end0: Link is Up - 2.5Gbps/Full - flow
control rx/tx
# sensors r8169_2_2100:00-mdio-0
r8169_2_2100:00-mdio-0
Adapter: MDIO adapter
temp1: +52.0°C (high = +120.0°C)
I'm using whatever is in Armbian's armbian-firmware package:
# ethtool -i end0 | grep -i firmware
firmware-version: rtl8125b-2_0.0.2 07/13/20
Thanks for checking!
Mine is RTL8125D XID 688, i.e. a different variant.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds