Date: Wed, 10 Jan 2024 15:16:49 -0800 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm> Cc: freebsd-arm@freebsd.org Subject: Re: current for arm64 tries tftp first for some reason Message-ID: <0DB5FDFB-184F-4260-A060-ED6A6CAFE546@yahoo.com> In-Reply-To: <ZZ8Zfz40N6XTbdZf@int21h> References: <ZZqgyHIJhgNoHtES@int21h> <C694B0F9-89C0-42F2-A00F-F77787775655@yahoo.com> <ZZ8Zfz40N6XTbdZf@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 10, 2024, at 14:26, void <void@f-m.fm> wrote: > On Tue, Jan 09, 2024 at 09:37:54PM -0800, Mark Millard wrote: >=20 >> For the RPi4B context I'm dealing with I let the first >> time boot go through all its TFTP failures. It produced >> a: >>=20 >> -rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 = /boot/efi/ubootefi.var >>=20 >> that was not there originally. I wonder if it gives a >> means of control over such things that would be >> remembered? >=20 > Unfortunately not. It still goes through tftp 10 or so cycles then = boots > the usb3 device. This makes boot time take 10 mins or so rather than > the usual 20 or so seconds. >=20 > There is a TUI uefi shell at the uboot stage one can invoke if > quick enough (within 3s) the only selectable thing to boot (and it was = already selected) is usb 0:1. >=20 > Not sure what to do now - maybe compare whats in the efi partition to > the latest github versions. Also unsure whether it's a uboot issue or = a freebsd one, U-Boot is doing tftp activity before the FreeBSD UEFI loader has been found to be loaded. So either the sysutils/u-boot* port's choices for how/what to build or U-Boot itself if building can not control the issue. > or if it can be fixed with one of the u-boot ports. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0DB5FDFB-184F-4260-A060-ED6A6CAFE546>