Date: Fri, 10 Feb 2017 00:02:40 +0200 From: Toomas Soome <tsoome@me.com> To: Oleksandr Tymoshenko <gonzo@bluezbox.com> Cc: Karl Denninger <karl@denninger.net>, freebsd-current@freebsd.org Subject: Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109 Message-ID: <B9B8FCBF-3176-417B-81E3-7F5E054AD6ED@me.com> In-Reply-To: <20170209213916.GA40599@bluezbox.com> References: <517ab0d5-412a-35dd-7d0d-d8297af43b46@denninger.net> <4a6f872b-cee1-57e5-7a72-a1d445f9926f@denninger.net> <F4D44CDD-BEF6-4E21-848A-745B88440617@me.com> <5128b9a9-1186-8c6c-6227-e5e8a087cf89@denninger.net> <0B4B40AA-E654-4A71-92B0-D8E6CD234B63@me.com> <20170209213916.GA40599@bluezbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko <gonzo@bluezbox.com> = wrote: >=20 > Toomas Soome (tsoome@me.com) wrote: >>=20 >>> On 9. veebr 2017, at 17:05, Karl Denninger <karl@denninger.net> = wrote: >>>=20 >>>=20 >>> On 2/9/2017 08:58, Toomas Soome wrote: >>>>> On 9. veebr 2017, at 16:36, Karl Denninger <karl@denninger.net> = <mailto:karl@denninger.net> wrote: >>>>>=20 >>>>>=20 >>>>> On 2/8/2017 16:18, Karl Denninger wrote: >>>>>> r313441 blows up on the Pi3 in /boot/loader.efi with: >>>>>>=20 >>>>>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>>>> (Tue Feb 7 15:15:52 CST 2017 freebsd@NewFS.denninger.net = <mailto:freebsd@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 >>>>>>=20 >>>>>> Resetting CPU ... >>>>>>=20 >>>>>> 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) >>>>>>=20 >>>>>> B >>>>> This has been isolated to r313333 in sys/boot/efi; reverting the = EFI >>>>> loader to a previous revision stops the crash. >>>>>=20 >>>>> Filed here: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940 = <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940>; = <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940>; = <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940>; >>>>>=20 >>>> Does it still crash with r313442? I think it does and this is why: >>>>=20 >>>> =46rom your log above, the hint is "Failed to start image provided = by UFS (14)=E2=80=9D, 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. >>>>=20 >>>> 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=E2=80=99= ll try to check if I can replicate the issue with x86 + ufs. >>>>=20 >>>> BTW: sorry for trouble:) >>>>=20 >>>> rgds, >>>> toomas >>>>=20 >>> Yes. >>>=20 >>> 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. >>>=20 >>=20 >> 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=E2=80=A6 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: >>=20 >> for (i =3D 0; devsw[i] !=3D NULL; i++) { >> if (devsw[i]->dv_print !=3D NULL){ >> if (devsw[i]->dv_print(verbose)) >> break; >> } >> } >>=20 >> after dv_init() loop. >>=20 >> 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=E2=80=A6=20 >=20 >=20 > 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: >=20 > 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: >=20 >=20 > 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 I think Karl got or is getting the same result as I am writing - we did = reach to the same point:) Yep, the idea behind the efipart_hdinfo_add() is that the first argument = is handle to the disk itself, so we can sort the partition handles into = the partition list in the disk. I think the logical step from there would be to dig out the path = structure and see if we can use something to identify the disk itself. So, the interesting part here also is that in your case it did dig out = the BSD label too. Ok, so the MEDIA_FILEPATH_DP has last node as CHAR16 file name, so we = need to pick the last node and cast to FILEPATH_DEVICE_PATH and then we = can see what that CHAR16 there has:) Also we may need to inspect all the nodes on the path, then we have = idea. Once we have method to identify the disk itself, then we should have the = solution. rgds, toomas >=20 > Patch: > Index: boot/efi/libefi/efipart.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- 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) =3D=3D MEDIA_DEVICE_PATH && > + DevicePathSubType(node) =3D=3D MEDIA_FILEPATH_DP) = { > + efipart_hdinfo_add(efipart_handles[i], = efipart_handles[i]); > + continue; > + } > } > }
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9B8FCBF-3176-417B-81E3-7F5E054AD6ED>