From owner-freebsd-arm@freebsd.org Wed Mar 18 17:23:22 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD9222670FF for ; Wed, 18 Mar 2020 17:23:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48jH1h2z3Nz3LKT for ; Wed, 18 Mar 2020 17:23:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 02IHNdvU069773 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Mar 2020 10:23:40 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 02IHNd1V069772; Wed, 18 Mar 2020 10:23:39 -0700 (PDT) (envelope-from fbsd) Date: Wed, 18 Mar 2020 10:23:39 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Upgrading u-boot on an rpi3 Message-ID: <20200318172339.GB67865@www.zefox.net> References: <20200318054243.GA67865@www.zefox.net> <4B4CF1DF-F3C0-4ED3-AAC0-4FC0A8182787@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4CF1DF-F3C0-4ED3-AAC0-4FC0A8182787@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 48jH1h2z3Nz3LKT 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 [3.93 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.06)[ip: (0.24), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.995,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.98)[0.981,0]; R_SPF_NA(0.00)[]; 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]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 17:23:23 -0000 On Tue, Mar 17, 2020 at 11:42:09PM -0700, Mark Millard wrote: > > > On 2020-Mar-17, at 22:42, bob prohaska wrote: > > > Upgrading u-boot on an rpi3 running -current is turning out to be > > more involved than expected. Updating /boot/msdos/u-boot.bin didn't > > do the trick, getting stuck at the u-boot> prompt. > > > > Backing out the change by putting the old u-boot.bin in place > > restored the normal boot behavior, so I don't think the mischief > > is owed to anything else I might have screwed up. > > > > I noticed there was a metadata file in /usr/local/share/u-boot/u-boot-rpi3, > > but copying that along with the new u-boot.bin to /boot/msdos > > reproduced the previous failure. > > The metadata file is involved in doing the build. Some > look like: > > METHOD=uboot-raw > FILES="u-boot-sunxi-with-spl.bin" > OFFSET=8 > BS=1k > > (dd command information) and others like: The reference to dd is rather confusing in this context. Has it something to do with cross compiling on to new bootable media? If dd is required in self-hosting then I'm doing things very wrong. > > METHOD=uboot-file > FILES="u-boot.bin" > > (copy file to msdosfs information). They are not > for the ARM board to use during boot. > > > This is a self-hosting machine, with ports at 528581, > > kernel and world are at 351836. Sources are at 358976 > > > > Could the self-hosting be the source of the trouble? > > The "no mmc device at slot 0" looks rather odd, given > > that the boot device is mmcsd0. > > u-boot's identification of devices is not the same as > FreeBSD's. "MMC Device 0" need not be "mmcsd0" at all. > Slots do not have to be populated an mmc device. > > > Here's an excerpt from the console: > > > > Hit any key to stop autoboot: 0 > > MMC Device 0 not found > > no mmc device at slot 0 > > switch to partitions #0, OK > > mmc1 is current device > > Scanning mmc 1:1... > > Found EFI removable media binary efi/boot/bootaa64.efi > > Those last 2 lines above indicate that it found > your microsd card media and its bootaa64.efi just > fine. > > How old is this file? Rather ancient: -rwxr-xr-x 1 root wheel 637000 Oct 10 2018 /boot/msdos/EFI/BOOT/bootaa64.efi I have a newer version on a 12.x snapshot: -rwxr-xr-x 1 root wheel 609960 Nov 1 02:29 /mnt/EFI/BOOT/bootaa64.efi Is it prudent to simply substitute the newer version for the older? > Have you been updating > it via copying /boot/loader.efi to it as > /boot/loader.efi is updated? Not following here. Loader.efi appears to be a file and seems to update during normal build/install cycles. It's unclear where bootaa64.efi comes from; there's only one copy in the filesystem after repeated OS update cycles. Thanks for reading! bob prohaska > > I've had issues > needing such updates when starting from old > media [by content] that I made a large jump > to modern content for. > > For reference, the RPi4 said "scanning mmc 0:1" > and found its bootaa64.efi there. But it is > a difference device so this would not be > unusual. > > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > Scanning disk mmc@7e300000.blk... > > Found 3 disks > > BootOrder not defined > > EFI boot manager: Cannot load any image > > 637000 bytes read in 63 ms (9.6 MiB/s) > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > Consoles: EFI console > > The above looks normal compared to the RPi4 that > I tested with. > > The below is not like the RPi4 test. > > > efipart_readwrite: rw=1, blk=0 size=1 status=2 > > efipart_readwrite: rw=1, blk=64 size=1 status=2 > > efipart_readwrite: rw=1, blk=1 size=1 status=2 > > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 > > efipart_readwrite: rw=1, blk=0 size=1 status=2 > > efipart_readwrite: rw=1, blk=64 size=1 status=2 > > efipart_readwrite: rw=1, blk=1 size=1 status=2 > > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 > > Back to normal below: > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > Command line arguments: loader.efi > > EFI version: 2.80 > > EFI Firmware: Das U-Boot (rev 8217.4096) > > Console: efi (0) > > Load Path: /efi\boot\bootaa64.efi > > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8) > > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8) > > Setting currdev to disk0p1: > > Still normal above. > > Not normal below: > > > efipart_readwrite: rw=1, blk=0 size=1 status=2 > > efipart_readwrite: rw=1, blk=64 size=1 status=2 > > efipart_readwrite: rw=1, blk=1 size=1 status=2 > > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 > > efipart_readwrite: rw=1, blk=0 size=1 status=2 > > efipart_readwrite: rw=1, blk=64 size=1 status=2 > > efipart_readwrite: rw=1, blk=1 size=1 status=2 > > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 > > Back to normal below: > > > Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x197c7,0xee66839) > > Setting currdev to disk0p2: > > Not normal below: > > > efipart_readwrite: rw=1, blk=0 size=1 status=2 > > > The only messages that look odd to me are the > "efipart_readwrite:" ones. > > > > For reference from the RPi4 context: > > . . . > Setting currdev to disk0p2: > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > Loading /boot/loader.conf.local > Loading kernel... > . . . > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > >