Older U-Boots assign RockPI-S and RockS0 their Ethernet MAC based on disk image.

[brentr]

Uses the same mechanism we've been using to deal with the RockPI-S random WiFi MAC addresses to derive unique, fixed Ethernet MACs as well.

Description

Radxa appears to have omitted any hardware to store a unique MAC address on each of their RK3308 based devices. Users have trouble when putting two or more devices running copies of the same image on the same LAN. See:

(https://forum.armbian.com/topic/42663-how-to-change-ethernet-mac-address-on-image/)

@Kwiboo pointed out that U-Boot should handle this.
U-Boot v2024.10 added logic to correctly derive the Ethernet MAC from the SOC's unique CPUid, but older versions lacked this.
So, this PR was altered to disable the userspace fix to the end0 interface by default.

(https://armbian.atlassian.net/jira/software/c/projects/AR/issues/AR-2541

The end result is that this PR makes NO code changes. It merely reorganizes these udev scripts for fixing MAC addresses so they can be applied to all Radxa rk3308 based boards (RockS0 and RockPI-S)

How Has This Been Tested?

• Built RockPI-S image, verified WiFi reassigned, Ethernet left unchanged.
• Build Rock S0, verified no MACs reassigned, but scripts installed to do so if needed.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[Kwiboo]

Mainline U-Boot should inject a local-mac-address prop into ethernet0/ethernet1 nodes for all Rockchip aarch64 targets, so this should not be needed for Ethernet as long as the device tree contains an ethernet0-alias, or is this an Armbian only issue?

[brentr]

@Kwiboo
I think you are correct, U-boot is where a hardware unique proper MAC address should assigned.

Interestingly, U-Boot has always been reading the unique RK3308 cpuid# from the board and exporting it to its environment as: (for example)

cpuid#=55524b55313830303500000000072353

But the ethaddr and eth1addr vars generated did not incorporate that cpuid# to ensure uniqueness until recently. (not in v2022.04, anyway)

u-boot v2024.10 does incorporate this fix, so the user space fix is no longer needed.
This also explains why I was able to replicate the problem first reported in the forums.

I'll alter the PR to just add support for the user space fix to the RockS0, but leave it disabled by default.

[paolosabatino]

Would not be a better idea to just backport the fix to older u-boot and completely remove the userland fix?

[brentr]

Even if one were to backport the recent U-Boot fix, there is still the case of the RockPi-S WiFi being assigned random MACs at each boot.
U-Boot does not touch the WiFi interface.

This is a problem common to many network peripherals on low-cost platforms.
The same tiny (<500byte) userland script can automatically assign sensible MACs to any network interface.

That said, I'll leave this in draft status because the best "fix" is simply to move to the new u-boot, which fixes the MAC problem (for Ethernet, at least) and a few other outstanding issues.

[paolosabatino]

I agree the best fix is to move to newer u-boot, which fixes a variety of things among the others.

About the wifi, it is a different beast: it depends on the wifi chip, but usually they have a small efuse and they initialize the MAC address by themselves within firmware or driver. I never had difficulties with realtek chips for example, even though I don't know exactly where is the code that assigns the MAC address. Anyway, for sure u-boot has not to deal with wifi MAC address.

[brentr]

@paolosabatino
Radxa does not program the efuse in the WiFi chip for these inexpensive boards.
It's a known issue.