Date: Thu, 11 Jun 2020 19:56:34 +0000 From: greg@unrelenting.technology To: "Mark Millard" <marklmi@yahoo.com>, "=?utf-8?B?S2xhdXMgS8O8Y2hlbWFubg==?=" <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: Unrelenting testplan D25219 Message-ID: <8414e0163e5cb2e9c4a4c7b02aa01666@unrelenting.technology> In-Reply-To: <876E685B-B3AC-4821-A88F-702ABA3D9812@yahoo.com> References: <876E685B-B3AC-4821-A88F-702ABA3D9812@yahoo.com> <5FE76178-4255-46B0-9A0D-F7640EFCBBE4@googlemail.com> <F1DC2AFB-0CC7-407D-A6C0-4E109590612E@unrelenting.technology> <C7D9957A-5C58-48FF-9601-7DD13DE9D89B@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
June 11, 2020 10:51 PM, "Mark Millard" <marklmi@yahoo.com> wrote:=0A=0A> = On 2020-Jun-11, at 06:59, Klaus K=C3=BCchemann via freebsd-arm <freebsd-a= rm at freebsd.org> wrote:=0A> =0A>> loader.efi-thing maybe fixed in rS362= 008.. hope so..=0A> =0A> For the RPi4 UEFI/ACPI based boot context . . .= =0A> =0A> I grabbed a loader.efi from:=0A> =0A> https://artifact.ci.freeb= sd.org/snapshot/head/r362017/arm64/aarch64/base.txz=0A> =0A> (the closest= to -r362008 that was available for aarch64).=0A> Looks like loader.efi v= intage problems were what=0A> previously stopped the boot much earlier (n= o=0A> loader output back then).=0A=0AOkay, cool. I've had the "no loader = output" thing with the loader.efi from the=0AFreeBSD-13.0-CURRENT-arm64-a= arch64-20200528-r361567-mini-memstick image.=0A=0ABut didn't have that pr= oblem with whatever I used back in February.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8414e0163e5cb2e9c4a4c7b02aa01666>