Date: Wed, 20 Sep 2023 20:08:40 +0000 From: "John F Carr" <jfc@mit.edu> To: "Patrick M. Hausen" <pmh@hausen.com> Cc: Mark Millard <marklmi@yahoo.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface Message-ID: <4F2EC38A-A095-4BA9-B15B-FFFB6A83CC97@mit.edu> In-Reply-To: <B50A4409-84C0-405D-8099-43692243AE52@hausen.com> References: <3C1032FF-B914-4863-8A03-759A8B4BE216@hausen.com> <77E70D30-8E7D-42DC-A041-3A783E1C6908@yahoo.com> <5205C76E-BAB4-4AB7-8A03-1E8A2D4353BB@hausen.com> <B50A4409-84C0-405D-8099-43692243AE52@hausen.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 20, 2023, at 15:49, Patrick M. Hausen <pmh@hausen.com> wrote:
>=20
> Hi all,
>=20
> some more research ...
>=20
>> Am 20.09.2023 um 21:05 schrieb Patrick M. Hausen <pmh@hausen.com>:
>> No worky.
>> [...]
>=20
>=20
> I could not find any code in the network startup routines in userland tha=
t
> would generate and configure a random MAC address. So I looked for
> the driver.
>=20
> Apparently the TuringPi uses smsc(4), and there we have it straight from
> the driver source:
>=20
> -------------------
> 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);
> }
> -------------------
>=20
> 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 ...
>=20
> With no code on our side to perform anything, no wonder the RPI
> config files have no effect.
>=20
> 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.
>=20
> Or am I misreading that? I though that the Pi was *the* aarch64 platform,
> at least in numbers ...
>=20
> Kind regards,
> Patrick
>=20
>=20
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F2EC38A-A095-4BA9-B15B-FFFB6A83CC97>