Date: Thu, 9 Feb 2017 15:56:00 -0600 From: Karl Denninger <karl@denninger.net> To: Oleksandr Tymoshenko <gonzo@bluezbox.com>, Toomas Soome <tsoome@me.com> Cc: freebsd-current@freebsd.org Subject: Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109 Message-ID: <a586e0b9-375c-2676-9e74-ea4864ec06f3@denninger.net> 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
This is a cryptographically signed message in MIME format. --------------ms000006090104000406080004 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/9/2017 15:39, Oleksandr Tymoshenko wrote: > Toomas Soome (tsoome@me.com) wrote: >>> On 9. veebr 2017, at 17:05, Karl Denninger <karl@denninger.net> wrote= : >>> >>> >>> On 2/9/2017 08:58, Toomas Soome wrote: >>>>> On 9. veebr 2017, at 16:36, Karl Denninger <karl@denninger.net> <ma= ilto:karl@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 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 >>>>>> >>>>>> Resetting CPU ... >>>>>> >>>>>> If you copy in a loader.efi from an earlier build (e.g. r313109) t= hen 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 al= so 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 EF= I >>>>> loader to a previous revision stops the crash. >>>>> >>>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216= 940 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940>; <https:/= /bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940> <https://bugs.freebs= d.org/bugzilla/show_bug.cgi?id=3D216940> >>>>> >>>> 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)=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 t= o 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=E2=80=99l= l 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 rewo= rked the enumeration of the available devices to boot from. Reverting on= ly 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 successf= ully loads and starts the kernel. >>> >> Well, the x86 version does not appear to have problems with finding th= e 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 boot= 1 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 =3D 0; devsw[i] !=3D NULL; i++) { >> if (devsw[i]->dv_print !=3D 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=E2=80=A6=20 > > On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standar= d > comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some > debugging and found that U-Boot reports driver with subtype MEDIA_FILEP= ATH_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 > =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; > + } > } > } After a lot of back and forth with Toomas I'm sorta in the same place (slightly different code, but same effect)..... but while it enumerates the storage it still doesn't load the kernel. (pardon all the debugging printfs) >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console Enter efipart_updatehd nin [3] Nin 0 Type 4 subtype 4 Nin 0 name is NULL Cannot add as no logical partition is valid Nin 1 Type 4 subtype 4 Nin 1 name is NULL Added for 1 based on non-HD path Nin 2 Type 4 subtype 4 Nin 2 name is NULL Added for 2 based on non-HD path disk devices: disk0: 102375 X 512 blocks (removable) disk1: 62229504 X 512 blocks (removable) disk1a: FreeBSD UFS 29GB net devices: net0: Command line arguments: loader.efi Image base: 0x379b8008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Feb 9 10:08:24 CST 2017 freebsd@NewFS.denninger.net) can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK lsdev -v disk devices: disk0: 102375 X 512 blocks (removable) disk1: 62229504 X 512 blocks (removable) disk1a: FreeBSD UFS 29GB net devices: net0: OK --=20 Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000006090104000406080004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDkyMTU2MDBaME8GCSqGSIb3DQEJBDFCBECU82Dm ttdouF0glatDoRxbvq8GlqoA6Mm/3ihR01DckW598aZSsN/BRcttqLcNOcnJdOW9Q1Ilib6F brQJi/azMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIATxMilPKD9dME RW0l2tekMw6PkVlIOQk1lmEAHRe7XtZCejvtDbpE7llbEoT2NdRmjr4VnY/AHjQ48qV7CdN/ zq5kn8IDShS/9aC8WR6GzzA5VSfbdXOXd1ErPTixTPlSLF9cYM6mCLRHYxHZckrGwfNi4RTd 6Bb9Ec9eNV5Z2/lHfvW+l4G4INx+diXPOPHmZUygLxEfIIQLjcdQrVQ1p8nXTw21pxv5L7RH wdur9FEdR7t88eDtUc3oza3X9oyy/zbPtEBR8A/wANMroPiH5ZTPQ0xPb+rLrfsOz0urBMaF IqCVQYfVs+t8BboYmuMnyzPCYGEyjtm7iWS4W39ugePuvppd8MB08HvPoFke7gDxKHBIu1/p ZNpp2nlCsnBLbZSKoVdvRFabAOckbBVSqfvbsDAYfa3zgU9IqCMKLEV7dH2UTHm/bBqhLcM4 W3hpW4RiJ/+UTo0DNsU7zR/u+lNzxQoAmmYsT4+T74xVF6JhYN1ylEdDUh8ITsMJkbVhmTah p3OSwkczTZUC5iTlU28Yo0mGe2CTIpKwzkcwm8zLr6hPfxvym+T06lRR/6Bmqdk88dwhPpB3 wf5VPsz7Nmv3OYDoKANojSmaKpyP6r43UXD5zTs93UXH9zdfhZ8+cYeCzjCC0ZWhy2rY3wvx uUqJHXrD34TpbnNbKZP8ZVcAAAAAAAA= --------------ms000006090104000406080004--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a586e0b9-375c-2676-9e74-ea4864ec06f3>