From owner-freebsd-current@freebsd.org Thu Feb 9 22:16:56 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 69955CD8A3F for ; Thu, 9 Feb 2017 22:16:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EB771F32 for ; Thu, 9 Feb 2017 22:16:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OL400G00OEB8300@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Thu, 09 Feb 2017 22:16:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1486678615; bh=moNJL9pF8GfFNuqgsk1dLwtF6oC6CoriCZ5vOYr8R6Y=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=h8x41lkHlHTEaQQ75vqlrl2N3eSyf22Rm0tIjNwUkTEiuFVqX/3MDh+mAMToWudhQ I3BDXKkxnv+/fiQWiHAxZpq3RL9L4vu4MxEoGDBUpFLihs5ct213Bm3N/VnEHWyhUk L1GtiSjPsprQfFzX1AdRpfyuHDz5kubkezY2aAIo3UC7EyZKnJMeEZbUWvaKmqgHGu /WoSl3GyWVrCXguZSSAgoipGkJl0nJBijMncrhO56CC/TosrjrEvnd6fCb0nq2xIU8 nHZj3hhhnfWf9HtRiJ8Dd0MwnmxX98MQ56rCKKxx0+tC8MUOotegyixFnNEc56PtBH MW0Zp/l64/E+A== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OL400GG7OK4TO30@st13p35im-asmtp002.me.com>; Thu, 09 Feb 2017 22:16:55 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-09_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702090200 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109 From: Toomas Soome In-reply-to: <20170209221021.GA40870@bluezbox.com> Date: Fri, 10 Feb 2017 00:16:51 +0200 Cc: Karl Denninger , freebsd-current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <64E64B7F-E1BE-4CC6-ACAB-E5D7FEE408C8@me.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> <20170209213916.GA40599@bluezbox.com> <20170209221021.GA40870@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.3259) 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:16:56 -0000 > On 10. veebr 2017, at 0:10, Oleksandr Tymoshenko = wrote: >=20 > Toomas Soome (tsoome@me.com) wrote: >>=20 >>> On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko = wrote: >>>=20 >>> Toomas Soome (tsoome@me.com) wrote: >>>>=20 >>>>> On 9. veebr 2017, at 17:05, Karl Denninger = wrote: >>>>>=20 >>>>>=20 >>>>> On 2/9/2017 08:58, Toomas Soome wrote: >>>>>>> On 9. veebr 2017, at 16:36, Karl Denninger = 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 = ) >>>>>>>> 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 = = = >>>>>>>=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 >>=20 >>=20 >> I think Karl got or is getting the same result as I am writing - we = did reach to the same point:) >>=20 >> 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. >>=20 >> 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. >>=20 >> So, the interesting part here also is that in your case it did dig = out the BSD label too. >>=20 >>=20 >> 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:) >>=20 >> Also we may need to inspect all the nodes on the path, then we have = idea. >>=20 >> Once we have method to identify the disk itself, then we should have = the solution. >=20 > =46rom reading U-Boot sources (lib/efi_loader/efi_disk.c) it looks = like > names are in the form of typeN:M, where type is interface type, > N is disk id and M is partition id. So 3 disks in my setup > may be mmc0, mmc0:1, mmc0:2.=20 >=20 > --=20 > gonzo Okay, so in case of arm or MEDIA_FILEPATH_DP we need to keep the initial = disk handle till there is an disk switch, and use it as first argument = for registering the disk. So the name in last node is probably the same = format and we can identify the disk this way. Worth to check in any = case:) rgds, toomas