Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface
- In reply to: Patrick M. Hausen: "Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 20 Sep 2023 20:08:40 UTC
> On Sep 20, 2023, at 15:49, Patrick M. Hausen <pmh@hausen.com> wrote: > > Hi all, > > some more research ... > >> Am 20.09.2023 um 21:05 schrieb Patrick M. Hausen <pmh@hausen.com>: >> No worky. >> [...] > > > I could not find any code in the network startup routines in userland that > would generate and configure a random MAC address. So I looked for > the driver. > > Apparently the TuringPi uses smsc(4), and there we have it straight from > the driver source: > > ------------------- > static void > smsc_attach_post(struct usb_ether *ue) > { > [...] > /* Attempt to get the mac address, if an EEPROM is not attached this > * will just return FF:FF:FF:FF:FF:FF, so in such cases we invent a MAC > * address based on urandom. > */ > [...] > /* Initialise the chip for the first time */ > smsc_chip_init(sc); > } > ------------------- > > So what we would really need is a tunable - one per driver or possibly a > common one read and acted upon by all of the USB ethernet drivers ... > > With no code on our side to perform anything, no wonder the RPI > config files have no effect. > > Dang. That's frustrating. With aarch64 having been promoted to "tier 1" > I really expected full support for all RPI platforms and related features > and hardware. > > Or am I misreading that? I though that the Pi was *the* aarch64 platform, > at least in numbers ... > > Kind regards, > Patrick > > The driver attempts to read the address from a device tree file, see call to usb_fdt_get_mac_addr, so you should be able to edit something in the magic boot partition to add a "mac-address" or "local-mac-address" property. As for support level, I can not speak for FreeBSD but what I observe is the Pi boxes are most definitely not supported at Tier 1 level. They are like homebuilt PCs 30 years ago, both for hardware reliability and driver compatibility. Server class ARM boxes mostly just work. OS or firmware updates can break the UEFI boot process and you need to boot from a stick to patch things up. At least you can boot from a stick, unlike many Pis which are simply broken at any given time.