Date: Wed, 18 Mar 2020 11:02:43 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Upgrading u-boot on an rpi3 Message-ID: <456B1ED8-B335-405B-AB7B-B65968631323@yahoo.com> In-Reply-To: <20200318172339.GB67865@www.zefox.net> References: <20200318054243.GA67865@www.zefox.net> <4B4CF1DF-F3C0-4ED3-AAC0-4FC0A8182787@yahoo.com> <20200318172339.GB67865@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
On 2020-Mar-18, at 10:23, bob prohaska <fbsd at www.zefox.net> wrote: > On Tue, Mar 17, 2020 at 11:42:09PM -0700, Mark Millard wrote: >> >> >> On 2020-Mar-17, at 22:42, bob prohaska <fbsd at www.zefox.net> 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. Arm boards other than RPi*'s tend to involve putting materials outside any file system on the media that is involved. Example /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata was used above. Note the dd command below and the bs= and seek= and the file name. # more /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README U-Boot loader for OrangePi Plus2E. To install this bootloader on an sdcard just do : dd if=$LOCALBASE/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin of=/path/to/sdcarddevice bs=1k seek=8 conv=sync This version is patched so that: * API features are enabled. * A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included For information about running FreeBSD on Allwinner boards, see https://wiki.freebsd.org/FreeBSD/arm/Allwinner WWW: http://www.denx.de/wiki/U-Boot Such is not involved for the RPi*'s: all the material goes in a file system, no dd involved. >> METHOD=uboot-file >> FILES="u-boot.bin" The above was an example from an RPi* . Note the "uboot-raw" earlier vs. "uboot-file" here. That indicates the outside file system vs. inside file system status. >> (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? You may want to extract a more modern one from a snapshot if that does not work. >> 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. For the ARM boards involved, efi/boot/bootaa64.efi is a copy of /boot/loader.efi . The loader copy used in booting is placed on the msdosfs, not on ufs/zfs. Example from the RPi4 context: # file /boot/loader.efi /boot/loader.efi: MS-DOS executable PE32+ executable (EFI application) Aarch64, for MS Windows # file /boot/efi/EFI/BOOT/bootaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi: MS-DOS executable PE32+ executable (EFI application) Aarch64, for MS Windows > . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?456B1ED8-B335-405B-AB7B-B65968631323>