Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Overriding MAC address via device_properties?

I was working with the ROCK64 image from "armbsd.org" last night.

I uses a pretty old (2017.09) version of U-boot.  One of my goals for today was to rebuild U-boot from the 2022.10 sources.  That will allow the saveenv command to work to (in my case) the SD card -- it writes a file uenv.txt or some such in the EFI fat partition.

I saw that there were some NetBSD specific patches for U-boot 2022.10 so I need
to look at those (why would there be NetBSD specific patches to U-boot?)

I am working on the Orange Pi R1+ (another RK3328 board).

On 1/24/23 08:29, David Brownlee wrote:
On Tue, 3 Jan 2023 at 15:01, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
On Sat, Dec 31, 2022 at 09:06:23AM +0900, Chris wrote:

I have a few rock64s running NetBSD-9.  I'm trying to migrate them from microSD
cards to eMMC, and apparently the rock64 u-boot isn't able to write its
environment to eMMC.

That's unfortunate, because the rock64 doesn't have a unique per-board MAC
address.  If the MAC address isn't explicitly set in the u-boot environment,
all boards will use 9e:6b:01:38:f7:da.

Attempting to override the MAC address via ifconfig's 'link <address> active'
kills the awge interface completely.

I'm planning on untangling that issue, as well as the u-boot issue, but in the
meantime I need to get these boards running with unique MAC addresses.

I see this bit in sys/dev/ic/dwc_gmac.c:

         prop_data_t ea = dict ? prop_dictionary_get(dict, "mac-address") : NULL;
         if (ea != NULL) {
                  * If the MAC address is overriden by a device property,
                  * use that.
                 KASSERT(prop_object_type(ea) == PROP_TYPE_DATA);
                 KASSERT(prop_data_size(ea) == ETHER_ADDR_LEN);
                 memcpy(enaddr, prop_data_data_nocopy(ea), ETHER_ADDR_LEN);

... which leads me to believe that there's a way to specify the MAC address via
a property dictionary.

However, I haven't been able to find any documentation on where that is
actually configured.  Adding various permutations of mac-address to
/boot/{cmdline,config}.txt hasn't worked.
The device properties are kernel internals. They are usually derived from
configuration informations such as device tree or ACPI.
AFAIK there's no way for a user to explicitely set a device property.
OpenFirmware and UEFI allow properties to be set in the firmware to be
read into a booting system, and NetBSD already reads FDT data from
boot media.

It feels like there should be some way to inject additional
information. Does the rock64 support device tree overlay? If not then
is there some other similar mechanism already defined that could be


Home | Main Index | Thread Index | Old Index