Date: Mon, 11 Sep 2017 00:01:51 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more Message-ID: <36A0023C-0DD7-4903-A9C7-C641CC759B47@dsl-only.net> In-Reply-To: <CANCZdfpRRquHCwq607=PaB8VTYLc%2B3H_bv5toKoYQ%2BeK4_TbPg@mail.gmail.com> References: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> <CANCZdfrbaH9Vi9CgOFnqUs4SNsan9Z6ufJyR=NYDFL85GXfQqg@mail.gmail.com> <06E8015B-89F8-4789-B876-59B8624D1207@dsl-only.net> <CANCZdfpRRquHCwq607=PaB8VTYLc%2B3H_bv5toKoYQ%2BeK4_TbPg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Warner: looks like you were thinking in the correct general direction. Details below.] On 2017-Sep-10, at 3:17 PM, Warner Losh <imp at bsdimp.com> wrote: > On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard <markmi at dsl-only.net> = wrote: > On 2017-Sep-10, at 1:17 PM, Warner Losh <imp at bsdimp.com> wrote: >=20 > > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard <markmi@dsl-only.net> = wrote: > > When I attempted to use the result of: > > > > # cp -aRx = /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi = /mnt/EFI/BOOT/ > > > > the pine64+ boot sequence got over and over > > a sequence like: > > > > U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology > > > > CPU: Allwinner A64 (SUN50I) > > Model: Pine64+ > > DRAM: 2 GiB > > MMC: SUNXI SD/MMC: 0 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > . . . > > >> FreeBSD EFI boot block > > Loader path: /boot/loader.efi > > > > Initializing modules: ZFS UFS > > Load Path:=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE= =A8=80 > > "Synchronous Abort" handler, esr 0x96000004 > > ELR: bdf90b30 > > LR: bdf8fb6c > > x0 : 0000000000000000 x1 : 0000000000000000 > > x2 : 00000000bdffc000 x3 : 0000000040000000 > > x4 : 00000000b9f34d40 x5 : 0000000000000000 > > x6 : 0000000000000015 x7 : 0000000000000000 > > x8 : 00000000bdfa59b8 x9 : 000000000000001c > > x10: 0000000000000002 x11: 0000000000000000 > > x12: 0000000000000000 x13: 0000000000000000 > > x14: 0000000000000000 x15: 0000000000000000 > > x16: 0000000000000000 x17: 0000000000000000 > > x18: 00000000b9f39df8 x19: 0000000000000000 > > x20: 0000000000000000 x21: 0000000000000002 > > x22: 00000000b8f34c98 x23: 00000000b8f34c88 > > x24: 00000000b8f34ca0 x25: 00000000000007d0 > > x26: 00000000b8f34c90 x27: 00000000b8f2f198 > > x28: 0000000000000000 x29: 00000000b9f34de0 > > > > Resetting CPU ... > > > > resetting ... > > > > It would be super helpful if you could bisect the change that caused = this. >=20 > I'm doing some other experiments first but I'll > probably take a stab at it if things seem stable > enough. Pine64+ has multiple problems currently. > (It regressed some time back.) >=20 > Unfortunately I do not have a known way to reproduce > the older boot1.efi file fully. I'll have to explore > that part to have a known-good low bound. If I'm > lucky the first try from the general time frame will > happen to work. >=20 > Do to other issues I'm jumping from pre-INO64 to modern > without having tracked in the middle. >=20 >=20 > I will note that the older boot1.efi (as bootaa64.efi) > output is different (no "Load Path:")=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80= =EE=A8=80=EE=A8=80=EE=A8=80: >=20 > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console > Command line arguments: loader.efi > Image base: 0xb6dbb008 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) >=20 > The failing one has garbage (invisible) > text after "Load Path:". >=20 > My first guess, and it's just a shot in the dark, is that the UEFI = subset that u-boot implements doesn't implement the device path to text = protocols, so we're jumping into the middle of cloud cuckoo land and/or = printing stack trash. >=20 > This is new functionality designed to help track WTF we booted from. Based on your guess I explored just recent changes that looked to be tied to your guesses. The following back-off of 2 file revisions was enough to build a working boot1.efi (as bootaa64.efi) for the Pine64+ 2GB : # svnlite update -r322941 /usr/src/sys/boot/efi/boot1/boot1.c = /usr/src/sys/boot/efi/include/efiapi.h -r323064 was not far enough back for these 2 soruces: failed just like -r323246 did. I did not directly try -r323063 . I can if you want. Revision 323064 - Directory Listing=20 Modified Thu Aug 31 17:32:19 2017 UTC (10 days, 12 hours ago) by imp Exit rather than panic for most errors. In the FreeBSD UEFI boot protocol, boot1.efi exits back to UEFI if it can't boot the image for most reasons (so that further items in the EFI boot manger list can be tried). Rename panic to efi_panic, make it static and give it an extra status argument. Exit back to UEFI with that status argument so the next loader can be tried. Use malloc/free exclusively instead of mixing malloc/free and AllocatePool/FreePool. The code is smaller. Sponsored by: Netflix Revision 323063 - Directory Listing=20 Modified Thu Aug 31 17:32:14 2017 UTC (10 days, 12 hours ago) by imp boot1.efi: print more info about where boot1.efi is loaded from Print the device that boot1.efi was loaded from. Print the path as well (since it isn't included in DeviceHandle). Move block where we do this earlier so all the block handle code is now together. Sponsored by: Netflix Revision 322941 - Directory Listing=20 Modified Sun Aug 27 03:10:16 2017 UTC (2 weeks, 1 day ago) by imp Eliminate redunant device path matching. Use efi_devpath_match instead of device_paths_match. They are functionally the same. Remove device_paths_match from boot1.c and call efi_devpath_match instead. Sponsored by: Netflix =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36A0023C-0DD7-4903-A9C7-C641CC759B47>