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.