Dual NanoBSD partitions on RPi3 - partially solved

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dual NanoBSD partitions on RPi3 - partially solved

Nick Hibma-4
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
[hidden email]

-- Open Source: We stand on the shoulders of giants.




signature.asc (920 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dual NanoBSD partitions on RPi3 - partially solved

Nick Hibma-4
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
[hidden email]

-- Open Source: We stand on the shoulders of giants.



> On 30 Sep 2017, at 23:00, Nick Hibma <[hidden email]> 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
> [hidden email]
>
> -- Open Source: We stand on the shoulders of giants.
>
>
>


signature.asc (920 bytes) Download Attachment