From nobody Sat Sep 23 19:50:46 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RtKWF28j6z4v95n for ; Sat, 23 Sep 2023 19:50:49 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RtKWF1lT7z3J2m; Sat, 23 Sep 2023 19:50:49 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 38NJolNj014962; Sat, 23 Sep 2023 14:50:47 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1695498648; bh=1m59H25fHElnsdmftXw+IYRaAm1TEUNNHcYpUNyNiOY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HCCdDoyOphTmMvEhyIDwf3W951du0C6bLARV1fVkz21eaQ+EAaMGshLlmDuIQEumw QgQDEG+AHyF6+O56qGOCu/Uo1lPAKnesQxQK7OgITtKxfY3Oek6H3RowQ43Fkue//n +m9uU0HhztGf5CTquC1kWix5qVFFrq2ISCFKEMN58wiCOTM6/QYzEJ50dXErKNSBJ+ AwjQfOea8SEyYSxA3fBZAi3rclcAjHxGia6Yl9yAm6or0Pf+F+xdX/L1wlo3r2zgc7 azSZfKMIQEbwKH4D+QjWYg2l30S4lKwpU2PSKnam2uh0bDe66hvjEcuM+3xLmCBZQ3 gar4FH/85p1Ag== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id XRIMLZdBD2VwOgAAs/W3XQ (envelope-from ); Sat, 23 Sep 2023 14:50:47 -0500 From: Mike Karels To: Ronald Klop Cc: "Patrick M. Hausen" , Mark Millard , freebsd-arm@freebsd.org Subject: Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface Date: Sat, 23 Sep 2023 14:50:46 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: <4951c134-39be-43de-0aa7-430a136d8b36@FreeBSD.org> References: <3C1032FF-B914-4863-8A03-759A8B4BE216@hausen.com> <77E70D30-8E7D-42DC-A041-3A783E1C6908@yahoo.com> <5205C76E-BAB4-4AB7-8A03-1E8A2D4353BB@hausen.com> <84C20AD4-1F37-414E-8808-60A2C9B621D9@karels.net> <4951c134-39be-43de-0aa7-430a136d8b36@FreeBSD.org> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4RtKWF1lT7z3J2m On 23 Sep 2023, at 14:28, Ronald Klop wrote: > On 9/20/23 22:02, Mike Karels wrote: >> On 20 Sep 2023, at 14:49, Patrick M. Hausen wrote: >> >>> Hi all, >>> >>> some more research ... >>> >>>> Am 20.09.2023 um 21:05 schrieb Patrick M. Hausen : >>>> 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 ... >> >> There is a routine called ether_gen_addr(), which will generate an >> Ethernet MAC based on the hostid and the interface name, both of which >> are reasonably stable. Not very many drivers use it though. It >> would probably be an improvement. >> >>> With no code on our side to perform anything, no wonder the RPI >>> config files have no effect. >> >> It would seem wrong to me to have USB Ethernet drivers using an RPI-specific >> mechanism. >> >>> 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 ... >> >> In numbers, probably. In support, no. >> >> Mike >> >>> Kind regards, >>> Patrick >> > > > Would this work? > > diff --git a/sys/dev/usb/net/if_smsc.c b/sys/dev/usb/net/if_smsc.c > index 0a0268bfa1a2..4a7983a20717 100644 > --- a/sys/dev/usb/net/if_smsc.c > +++ b/sys/dev/usb/net/if_smsc.c > @@ -1554,6 +1554,7 @@ static void > smsc_attach_post(struct usb_ether *ue) > { > struct smsc_softc *sc = uether_getsc(ue); > + struct ether_addr eaddr; > uint32_t mac_h, mac_l; > int err; > @@ -1589,9 +1590,10 @@ smsc_attach_post(struct usb_ether *ue) > err = usb_fdt_get_mac_addr(sc->sc_ue.ue_dev, &sc->sc_ue); > #endif > if ((err != 0) || (!ETHER_IS_VALID(sc->sc_ue.ue_eaddr))) { > - read_random(sc->sc_ue.ue_eaddr, ETHER_ADDR_LEN); > - sc->sc_ue.ue_eaddr[0] &= ~0x01; /* unicast */ > - sc->sc_ue.ue_eaddr[0] |= 0x02; /* locally administered */ > + device_printf(ue->ue_dev, "No MAC address found. Using ether_gen_addr().\n"); > + ether_gen_addr(ue->ue_ifp, &eaddr); > + for (int i = 0; i < ETHER_ADDR_LEN; i++) > + sc->sc_ue.ue_eaddr[i] = eaddr.octet[i]; > } > } > > > I don't have the hardware so I can't test it. It looks right to me, and seems like a big improvement. I don't have the hardware either. Mike > Regards, > Ronald.