From nobody Wed Jul 06 00:27:54 2022 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 221931D0A23A for ; Wed, 6 Jul 2022 00:27:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ld0kQ313Qz4nW4 for ; Wed, 6 Jul 2022 00:27:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2660Rs5g009657 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 Jul 2022 17:27:54 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 2660Rsf9009656; Tue, 5 Jul 2022 17:27:54 -0700 (PDT) (envelope-from fbsd) Date: Tue, 5 Jul 2022 17:27:54 -0700 From: bob prohaska To: Mark Millard Cc: Karl Denninger , freebsd-arm@freebsd.org Subject: Re: 13.1R problems on Pi3 Message-ID: <20220706002754.GB9228@www.zefox.net> References: <20220704003639.GA1165@www.zefox.net> <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com> <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net> <20220704152834.GA1771@www.zefox.net> <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net> <20220704182526.GB1771@www.zefox.net> <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com> <8755F460-D5A5-4ED1-857F-37B894A9B875@yahoo.com> 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; charset=us-ascii Content-Disposition: inline In-Reply-To: <8755F460-D5A5-4ED1-857F-37B894A9B875@yahoo.com> X-Rspamd-Queue-Id: 4Ld0kQ313Qz4nW4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.95 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.960]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(0.78)[0.779]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.77)[-0.767]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jul 04, 2022 at 01:29:59PM -0700, Mark Millard wrote: > [This ends with a possible config.txt way to control the > default Ether MAC address used, independent of which OS > happens to be running. Possibly better than using the > only-FreeBSD technique.] > > > Did you get the two RPi3*'s in the same purchase? Ending up with > 2 that both happen to have b8:27:eb:71:46:4e seems odd unless > possibly the means of setting the values at the factory was > not varying the values like it should in some production lot (or > over some range of lots). Independent purchases at different > times would make it seem even odder. > Oddness won this round. They were bought in 2016 and 2018 > > > I've found references to an undocumented control in config.txt : > > force_mac_address=??:??:??:??:??:?? > > See, for example, https://forums.raspberrypi.com/viewtopic.php?t=327562 > > Apparently, force_mac_address controls what value shows up in > the device tree for what the ethernet0 alias points to in the > device tree. > > Note that having a odd .dtb file could lead to force_mac_address > not working. (The RPi* firmware reads the file and then makes > a device tree with some modifications applied.) > With the files on the 13.1R image force_mac_address seems to work. Thank you very much! bob prohaska