From owner-freebsd-current@freebsd.org Thu Feb 9 22:17:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 251D3CD8A71 for ; Thu, 9 Feb 2017 22:17:11 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8A421FF7 for ; Thu, 9 Feb 2017 22:17:10 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cbwQv-000AZP-9q; Thu, 09 Feb 2017 13:39:23 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v19LdGXA040634; Thu, 9 Feb 2017 13:39:16 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Thu, 9 Feb 2017 13:39:16 -0800 From: Oleksandr Tymoshenko To: Toomas Soome Cc: Karl Denninger , freebsd-current@freebsd.org Subject: Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109 Message-ID: <20170209213916.GA40599@bluezbox.com> References: <517ab0d5-412a-35dd-7d0d-d8297af43b46@denninger.net> <4a6f872b-cee1-57e5-7a72-a1d445f9926f@denninger.net> <5128b9a9-1186-8c6c-6227-e5e8a087cf89@denninger.net> <0B4B40AA-E654-4A71-92B0-D8E6CD234B63@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0B4B40AA-E654-4A71-92B0-D8E6CD234B63@me.com> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Toomas Soome (tsoome@me.com) wrote: > > > On 9. veebr 2017, at 17:05, Karl Denninger wrote: > > > > > > On 2/9/2017 08:58, Toomas Soome wrote: > >>> On 9. veebr 2017, at 16:36, Karl Denninger 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 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 > >>>> > >>>> 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: [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: me.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 22:17:11 -0000 Toomas Soome (tsoome@me.com) wrote: > > > On 9. veebr 2017, at 17:05, Karl Denninger wrote: > > > > > > On 2/9/2017 08:58, Toomas Soome wrote: > >>> On 9. veebr 2017, at 16:36, Karl Denninger 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 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 > >>>> > >>>> 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 > >>> > >> 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; + } } }