Date: Wed, 10 Jan 2024 05:14: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: <1E55A7B4-1AC0-47F6-9418-4310268632D0@yahoo.com> In-Reply-To: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> References: <ZZqgyHIJhgNoHtES@int21h> <C694B0F9-89C0-42F2-A00F-F77787775655@yahoo.com> <ZZ6CkoBI0q2s1XGj@int21h> <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 10, 2024, at 05:07, Mark Millard <marklmi@yahoo.com> wrote: > On Jan 10, 2024, at 03:42, void <void@f-m.fm> wrote: >=20 >> 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 >> Did it subsequently boot quickly? Or did you have to edit the file? >=20 > The file is not a text file and I've no clue if any > EFI variables happen to be related. >=20 > The HoneyComb automatically booted faster after the > first time. The RPi4B and RPi3B have not. The reference to the HoneyComb was incoherent. Ignore it: not a U-Boot context at all. Sorry. > More to figure out someday. =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?1E55A7B4-1AC0-47F6-9418-4310268632D0>