Date: Tue, 3 Oct 2017 21:25:40 +0200 From: Nick Hibma <nick@van-laarhoven.org> To: =?utf-8?Q?=E2=80=9CFreeBSD_Embedded_Mailing_List=E2=80=9D?= <freebsd-embedded@FreeBSD.org> Subject: Re: Dual NanoBSD partitions on RPi3 - partially solved Message-ID: <6FB4B023-4028-40C5-89EF-74C56ADC00D5@van-laarhoven.org> In-Reply-To: <5484657D-C8C4-4E26-BAC5-B8C10FDA1883@van-laarhoven.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Just to respond to my own last remark: boot1.efi does not consider the active flag to select the partition to boot in the MBR partition table, and just loads loader from the first one. ubldr.bin used for booting Raspberry Pi 1 devices does work that. Solution: workable, but complicated: If you want to boot from a second root partition, say /dev/mmc0s3a in our case, you will have to add currdev=disk0s3a to /boot/loader.conf on the *first* root partition on /dev/mmc0s2a. In that way 'loader' will load use the second root partition for booting, despite the fact that it itself was loaded from the first one. Hope this helps anyone fiddling with this stuff. Nick Hibma nick@van-laarhoven.org -- Open Source: We stand on the shoulders of giants. > On 30 Sep 2017, at 23:00, Nick Hibma <nick@van-laarhoven.org> wrote: > > Right, > > I spent quite some time figuring this out (and learning how to use U-boot, neat stuff!). The problem was I was trying to create an image to load on a Raspberry Pi 3, using U-boot and the (crochet) examples. It kept failing to load my disk image, but did load others, most notably the RaspBSD one. It failed wiith 'failed to mount ext2 filesystem' in my case. > > I figured out that I had marked the second partition, the first UFS one, as active, instead of the FAT partition. I want to mark that partition active because I need to be able to choose between the second and third partitions, both UFS root partitions. But the scan_dev_for_boot_part macro in U-Boot uses fstype to figure out bootable partitions and tries to open that partition as an ext2 partition which produces that error. And it only tries boot using EFI from those bootable partitions and completely forgets about the first partition on which the EFI stuff is stored in our case. > > I resolved this by changing the mmc_boot macro like so: > > setenv mmc_boot "setenv devtype mmc; setenv distro_bootpart 1; run scan_dev_for_efi" > > I haven't quite figured out how to switch to the second UFS root partition yet. I assume that can be done the usual way, by marking the other partition active. EFI then picks that one I hope. But that's for some other time. Just wanted to get this solution into the lists. > > Cheers, > > Nick Hibma > nick@van-laarhoven.org > > -- Open Source: We stand on the shoulders of giants. > > > [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEETFbRZ/gKjBgO10CrH3Ic7sY0duAFAlnT5DQACgkQH3Ic7sY0 duDuNg/+PK7Jc3GQsViMZiB9Qocgf/GOnl0zZxltIA/opuUTcIbAlXw1Wmhicqpc sqAeQk68SSr7AD+Ct3HXmnw/uDpeDhd8UTxv/q7RLzSAGjeXmm3HWcbFXIBw+PZa Cpw4vbxlPbT9KVp2fEQETE1H3SfV7NBy0VbQD5cXrB4FmASgMMacK2H2Tk+h15Ee iYUahekbmn30HP0QPv+vfCpjchZfHGq1Xq6b93H2/qlRq+eWhRtGTf7ssY6lNKVM OOorRZH/8Wg0nXAXdnRtgxnLpuXlvssmJtk6qQJmZu9PvVRAdHj3KuiXAcgHM7Ta pRyhLyy6TAp2Wtlw+nXLvuUs2hAkOlpvDn1JHLA9UAQ1ZGXJw3zRCcDJyiLv5qBM Xl7xWf4s9PmUm+z/dqxlm9NbP8LdU/5epg57wYxXo2NMB9FEvvzu4MhD+Xd/To4g YQZMXWr6Xp8TyzxNB58xRgfTArvS+n5p31qYVIllxTFhWmO8aeIS6FQdx/JVXvHE 3yaBqMeF3Me1ucOdWSaU0UmPqg4x/dn11CZdNd4fxtmB4CH7S3cdfGLd+dxGyTbY 87fu2MzFfynR8pnC150lHA4wZdBcWwbr3NAWCXnKhGpYUypURUMLW1OWnXfAmg9l K+ArF74Hzj/YXEcaqnu0VpTrgdZcHVk+Ajr13+DC6U3TeMdFHBU= =kjLj -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FB4B023-4028-40C5-89EF-74C56ADC00D5>