Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

2017-09-11 Thread Mark Millard 
[Warner: looks like you were thinking in the
correct general direction. Details below.]

On 2017-Sep-10, at 3:17 PM, Warner Losh  wrote:

> On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard  wrote:
> On 2017-Sep-10, at 1:17 PM, Warner Losh  wrote:
> 
> > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard  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 +) 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:
> > "Synchronous Abort" handler, esr 0x9604
> > ELR: bdf90b30
> > LR:  bdf8fb6c
> > x0 :  x1 : 
> > x2 : bdffc000 x3 : 4000
> > x4 : b9f34d40 x5 : 
> > x6 : 0015 x7 : 
> > x8 : bdfa59b8 x9 : 001c
> > x10: 0002 x11: 
> > x12:  x13: 
> > x14:  x15: 
> > x16:  x17: 
> > x18: b9f39df8 x19: 
> > x20:  x21: 0002
> > x22: b8f34c98 x23: b8f34c88
> > x24: b8f34ca0 x25: 07d0
> > x26: b8f34c90 x27: b8f2f198
> > x28:  x29: b9f34de0
> >
> > Resetting CPU ...
> >
> > resetting ...
> >
> > It would be super helpful if you could bisect the change that caused this.
> 
> 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.)
> 
> 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.
> 
> Do to other issues I'm jumping from pre-INO64 to modern
> without having tracked in the middle.
> 
> 
> I will note that the older boot1.efi (as bootaa64.efi)
> output is different (no "Load Path:"):
> 
> >> FreeBSD EFI boot block
>Loader path: /boot/loader.efi
> 
>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)
> 
> The failing one has garbage (invisible)
> text after "Load Path:".
> 
> 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.
> 
> 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 
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 
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 
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

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

2017-09-10 Thread Warner Losh 
On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard  wrote:

> On 2017-Sep-10, at 1:17 PM, Warner Losh  wrote:
>
> > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard 
> 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 +) 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:
> > "Synchronous Abort" handler, esr 0x9604
> > ELR: bdf90b30
> > LR:  bdf8fb6c
> > x0 :  x1 : 
> > x2 : bdffc000 x3 : 4000
> > x4 : b9f34d40 x5 : 
> > x6 : 0015 x7 : 
> > x8 : bdfa59b8 x9 : 001c
> > x10: 0002 x11: 
> > x12:  x13: 
> > x14:  x15: 
> > x16:  x17: 
> > x18: b9f39df8 x19: 
> > x20:  x21: 0002
> > x22: b8f34c98 x23: b8f34c88
> > x24: b8f34ca0 x25: 07d0
> > x26: b8f34c90 x27: b8f2f198
> > x28:  x29: b9f34de0
> >
> > Resetting CPU ...
> >
> > resetting ...
> >
> > It would be super helpful if you could bisect the change that caused
> this.
>
> 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.)
>
> 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.
>
> Do to other issues I'm jumping from pre-INO64 to modern
> without having tracked in the middle.
>
>
> I will note that the older boot1.efi (as bootaa64.efi)
> output is different (no "Load Path:"):
>
> >> FreeBSD EFI boot block
>Loader path: /boot/loader.efi
>
>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)
>
> The failing one has garbage (invisible)
> text after "Load Path:".


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.

This is new functionality designed to help track WTF we booted from.

Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

2017-09-10 Thread Mark Millard 
On 2017-Sep-10, at 1:17 PM, Warner Losh  wrote:

> On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard  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 +) 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:
> "Synchronous Abort" handler, esr 0x9604
> ELR: bdf90b30
> LR:  bdf8fb6c
> x0 :  x1 : 
> x2 : bdffc000 x3 : 4000
> x4 : b9f34d40 x5 : 
> x6 : 0015 x7 : 
> x8 : bdfa59b8 x9 : 001c
> x10: 0002 x11: 
> x12:  x13: 
> x14:  x15: 
> x16:  x17: 
> x18: b9f39df8 x19: 
> x20:  x21: 0002
> x22: b8f34c98 x23: b8f34c88
> x24: b8f34ca0 x25: 07d0
> x26: b8f34c90 x27: b8f2f198
> x28:  x29: b9f34de0
> 
> Resetting CPU ...
> 
> resetting ...
> 
> It would be super helpful if you could bisect the change that caused this.

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.)

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.

Do to other issues I'm jumping from pre-INO64 to modern
without having tracked in the middle.


I will note that the older boot1.efi (as bootaa64.efi)
output is different (no "Load Path:"):

>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   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)

The failing one has garbage (invisible)
text after "Load Path:".

===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

2017-09-10 Thread Warner Losh 
On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard  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 +) 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:
> "Synchronous Abort" handler, esr 0x9604
> ELR: bdf90b30
> LR:  bdf8fb6c
> x0 :  x1 : 
> x2 : bdffc000 x3 : 4000
> x4 : b9f34d40 x5 : 
> x6 : 0015 x7 : 
> x8 : bdfa59b8 x9 : 001c
> x10: 0002 x11: 
> x12:  x13: 
> x14:  x15: 
> x16:  x17: 
> x18: b9f39df8 x19: 
> x20:  x21: 0002
> x22: b8f34c98 x23: b8f34c88
> x24: b8f34ca0 x25: 07d0
> x26: b8f34c90 x27: b8f2f198
> x28:  x29: b9f34de0
>
> Resetting CPU ...
>
> resetting ...
>

It would be super helpful if you could bisect the change that caused this.

Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

2017-09-10 Thread Mark Millard 
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 +) 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:
"Synchronous Abort" handler, esr 0x9604
ELR: bdf90b30
LR:  bdf8fb6c
x0 :  x1 : 
x2 : bdffc000 x3 : 4000
x4 : b9f34d40 x5 : 
x6 : 0015 x7 : 
x8 : bdfa59b8 x9 : 001c
x10: 0002 x11: 
x12:  x13: 
x14:  x15: 
x16:  x17: 
x18: b9f39df8 x19: 
x20:  x21: 0002
x22: b8f34c98 x23: b8f34c88
x24: b8f34ca0 x25: 07d0
x26: b8f34c90 x27: b8f2f198
x28:  x29: b9f34de0

Resetting CPU ...

resetting ...



I found an old boot1.efi to copy over instead (from
back in -r308??? time frames as I remember) and
doing the replacement got past this point.



Booting with the non-debug kernel appears to hang for
a bit and then gets to a db> prompt and a bt showed
(for example):
(The console output for the register dump seems
to always be incomplete and there is a wait to
end up at the db> prompt. Note the data_abort
closest to the fork_exit .)

. . .
Release APs
APs not started
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
 Instruction Set Attributes 0 = 
 Instruction Set Attributes 1 = <0>
 Processor Features 0 = 
 Processor Features 1 = <0>
  Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS 
Mem,16bit ASID,1TB PA>
  Memory Model Features 1 = <>
 Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 
Breakpoints,PMUv3,Debug v8>
 Debug Features 1 = <0>
 Auxiliary Features 0 = <0>
 Auxiliary Features 1 = <0>
CPU  1: (null) (null) r0p0 affinity:  0
CPU  2: (null) (null) r0p0 affinity:  0
CPU  3: (null) (null) r0p0 affinity:  0
  x0: 00a1c000
  x1: fd000103a[ thread pid 0 tid 100057 ]
Stopped at  thread_lock_flags_+0x298:   ldr w4, [x3, #156]
db> bt
Tracing pid 0 tid 100057 td 0xfd000103a000
db_trace_self() at db_stack_trace+0xec
 pc = 0x00613688  lr = 0x00084db4
 sp = 0x698f4260  fp = 0x698f4290

db_stack_trace() at db_command+0x224
 pc = 0x00084db4  lr = 0x00084a3c
 sp = 0x698f42a0  fp = 0x698f4380

db_command() at db_command_loop+0x60
 pc = 0x00084a3c  lr = 0x000847fc
 sp = 0x698f4390  fp = 0x698f43b0

db_command_loop() at db_trap+0xf4
 pc = 0x000847fc  lr = 0x00087964
 sp = 0x698f43c0  fp = 0x698f45e0

db_trap() at kdb_trap+0x180
 pc = 0x00087964  lr = 0x003693e0
 sp = 0x698f45f0  fp = 0x698f4650

kdb_trap() at do_el1h_sync+0x90
 pc = 0x003693e0  lr = 0x0062956c
 sp = 0x698f4660  fp = 0x698f4690

do_el1h_sync() at handle_el1h_sync+0x74
 pc = 0x0062956c  lr = 0x00615074
 sp = 0x698f46a0  fp = 0x698f47b0

handle_el1h_sync() at kdb_enter+0x38
 pc = 0x00615074  lr = 0x00368ac8
 sp = 0x698f47c0  fp = 0x698f4850

kdb_enter() at vpanic+0x180
 pc = 0x00368ac8  lr = 0x00326dd8
 sp = 0x698f4860  fp = 0x698f48d0

vpanic() at panic+0x48
 pc = 0x00326dd8  lr = 0x00326c54
 sp = 0x698f48e0  fp = 0x698f4960

panic() at data_abort+0x21c
 pc = 0x00326c54  lr = 0x006298e8
 sp = 0x698f4970  fp = 0x698f4a20

data_abort() at do_el1h_sync+0xfc
 pc = 0x006298e8  lr = 0x006295d8
 sp = 0x698f4a30  fp = 0x698f4a60

do_el1h_sync() at handle_el1h_sync+0x74
 pc = 0x006295d8  lr = 0x00615074
 sp = 0x698f4a70  fp = 0x698f4b80

handle_el1h_sync() at thread_lock_flags_+0x1a8
 pc = 0x00615074  lr = 0x00309060
 sp = 0x698f4b90  fp = 0x698f4c80

thread_lock_flags_() at statclock_cnt+0x11c
 pc = 0x00309060  lr = 0x002c5b90
 sp = 0x698f4c90  fp = 0x698f4cb0