On 2/9/2017 08:58, Toomas Soome wrote: >> On 9. veebr 2017, at 16:36, Karl Denninger <k...@denninger.net> wrote: >> >> >> On 2/8/2017 16:18, Karl Denninger wrote: >>> r313441 blows up on the Pi3 in /boot/loader.efi with: >>> >>> FreeBSD/arm64 EFI loader, Revision 1.1 >>> (Tue Feb 7 15:15:52 CST 2017 free...@newfs.denninger.net) >>> Failed to start image provided by UFS (14) >>> "Synchronous Abort" handler, esr 0x96000004 >>> ELR: 3af62cec >>> LR: 3af61d60 >>> x0 : 0000000000000001 x1 : 0000000000000001 >>> x2 : 000000003afeb000 x3 : 000000000000003f >>> x4 : 0000000000000020 x5 : 0000000000000010 >>> x6 : 0000000000000000 x7 : 0000000039b260a4 >>> x8 : 000000003af61d48 x9 : 000000000000000d >>> x10: 0000000000000030 x11: 0000000000000000 >>> x12: 0000000000000000 x13: 0000000000000002 >>> x14: 0000000000000000 x15: 0000000000000000 >>> x16: 0000000000000000 x17: 0000000000000000 >>> x18: 000000003ab30df8 x19: 0000000037a16008 >>> x20: 0000000000000000 x21: 0000000000000000 >>> x22: 0000000039b28000 x23: 0000000039b1d49c >>> x24: 0000000039b28850 x25: 000000003ab3d740 >>> x26: 000000003af839a0 x27: 0000000039b2e3e8 >>> x28: 0000000000000000 x29: 000000003ab2ef60 >>> >>> Resetting CPU ... >>> >>> If you copy in a loader.efi from an earlier build (e.g. r313109) then the >>> system boots but complains about SMP problems, fails to start any of the >>> other CPUs (although it sees them) and panics before it reaches a login >>> prompt with what appears to be a problem reading the SD card (I also get a >>> couple of lor's in here too..... not sure if those are "real" or false >>> positives) >>> >>> B >> This has been isolated to r313333 in sys/boot/efi; reverting the EFI >> loader to a previous revision stops the crash. >> >> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 >> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> >> > Does it still crash with r313442? I think it does and this is why: > > From your log above, the hint is "Failed to start image provided by UFS > (14)”, so what we can guess here is that for some reason the loader.efi > main() failed to detect the boot device, and did return back to boot1. > > Boot1 did print out this error message and did call panic(). So, the question > is, why it is failing to detect the root fs handle. I’ll try to check if I > can replicate the issue with x86 + ufs. > > BTW: sorry for trouble:) > > rgds, > toomas > Yes.
It's isolated to that particular revision, which appears to have reworked the enumeration of the available devices to boot from. Reverting only sys/boot/efi to anything before 313333 (e.g. "svn update -r 313332 ." in src/sys/boot/efi) and rebuilding results in a loader.efi that successfully loads and starts the kernel. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
