Re: current for arm64 tries tftp first for some reason
- Reply: void : "Re: current for arm64 tries tftp first for some reason"
- In reply to: void : "Re: current for arm64 tries tftp first for some reason"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 10 Jan 2024 23:16:49 UTC
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: > >> For the RPi4B context I'm dealing with I let the first >> time boot go through all its TFTP failures. It produced >> a: >> >> -rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 /boot/efi/ubootefi.var >> >> that was not there originally. I wonder if it gives a >> means of control over such things that would be >> remembered? > > 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. > > 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. > > 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. === Mark Millard marklmi at yahoo.com