Toomas Soome (tso...@me.com) wrote:
>
> > On 9. veebr 2017, at 17:05, Karl Denninger <k...@denninger.net> wrote:
> >
> >
> > On 2/9/2017 08:58, Toomas Soome wrote:
> >>> On 9. veebr 2017, at 16:36, Karl Denninger <k...@denninger.net>
> >>> <mailto: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
> >>>> <mailto: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>
> >>> <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.
> >
>
> Well, the x86 version does not appear to have problems with finding the ufs
> devices. So this has to be some sort of corner case related to arm:(
> unfortunately I do not have much variants to test arm, except qemu… so some
> help would be needed there. Since the only crash is from boot1 call to panic,
> I am pretty sure the disk detection and setup was ok, so we should get disk
> list if we insert something like:
>
> for (i = 0; devsw[i] != NULL; i++) {
> if (devsw[i]->dv_print != NULL){
> if (devsw[i]->dv_print(verbose))
> break;
> }
> }
>
> after dv_init() loop.
>
> If thats true, then it should not take too much to find why we fail to get
> the handle for root fs in case of arm…
On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standard
comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some
debugging and found that U-Boot reports driver with subtype MEDIA_FILEPATH_DP
so it's not recognized by disk handler. Quick hack below fixed boot
but it's not ideal and the device structure looks like this:
disk devices:
disk0: 15564801 X 512 blocks (removable)
disk0s1: DOS/Windows 49MB
disk0s2: FreeBSD 1856MB
disk0s2a: FreeBSD UFS 1856MB
disk1: 102375 X 512 blocks (removable)
disk2: 3802112 X 512 blocks (removable)
disk2a: FreeBSD UFS 1856MB
net devices:
net0:
disk1 and disk2 are actuallypartitions from disk0.
I can work on proper fix but not sure what should be
considered proper in this case. So some guidelines are welcome
Patch:
Index: boot/efi/libefi/efipart.c
===================================================================
--- boot/efi/libefi/efipart.c (revision 313477)
+++ boot/efi/libefi/efipart.c (working copy)
@@ -467,6 +467,15 @@
efipart_hdinfo_add(handle, efipart_handles[i]);
continue;
}
+
+ /*
+ * U-Boot case
+ */
+ if (DevicePathType(node) == MEDIA_DEVICE_PATH &&
+ DevicePathSubType(node) == MEDIA_FILEPATH_DP) {
+ efipart_hdinfo_add(efipart_handles[i],
efipart_handles[i]);
+ continue;
+ }
}
}
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
