Pi2 bootcode.bin puzzle

On a Pi4 usb boot is no problem at all. The Pi2 has always been troublesome. I'm interested in the problem only because I have four of them and would like to keep them in service.

Thanks for writing!

bob prohaska

Absolutely agreed!

Similar, in the sense that loader.conf on FreeBSD permits one to set variables that are passed as flag options to the kernel on startup.

The disk discovery seems to happen during the bootcode.bin or u-boot stage. By the time loader starts up, if the usb disk hasn't been found, loader fails to report its existence in an lsusb query.

There is a variable in loader.conf called kern.cam.boot_delay which can be set to wait in milliseconds for the disk to spin up, but that only affects behavior after bootcode.bin and u-boot are long gone.

This situation is what prompted me to post earlier about boot managers for the RPi family. Bootcode.bin seems to do a rather unreliable job of exploring the system for bootable media. U-boot likewise takes its cues from bootcode.bin, apparently.

Thanks for writing!

bob prohaska

It turns out in FreeBSD that setting currdev="disk0s2a" and vfs.root.mountfrom="ufs:/dev/da0s2a" in /boot/loader.conf of the microSD card does what's wanted.

Provided da0 is found immediately, the kernel is loaded from /da0s2a/boot/kernel and then started. After the kernel has populated /dev root is then mounted on /da0s2a. So far, so good.

If da0 is not detected by bootcode.bin, the kernel loads from mmcsd0, but by the time of mountroot the kernel has found da0 so the mountroot on da0 succeeds anyway. That mismatches kernel and world, but if the revisions are close the boot will succeed anyway and the system will run correctly.

For now, that's what I'm trying to do.

Integrating the microSD's msdos filesystem seems easy, just mount /dev/mmcsd0s1 on /boot/msdos. But, since FreeBSD never touches /boot/msdos, there isn't much point.

Mounting /dev/mmcsd0s0s2a on /boot becomes a problem, however. It would end up at /boot/boot if the intact microSD partition is mounted, which isn't updateable using the existing system upgrade scripts. If the files in the microSD's boot partition are raised to the top of the disk, the paths will be wrong if the machine ends up booting from the microSD alone. That I think will trigger a boot failure if da0 isn't detected by bootcode.bin.

Perhaps it would work to mount mmcsd0s2a on /microSD, with a symbolic link from /boot to /dev/mmcsd0s2a/boot. Updates to FreeBSD's /boot files would go on the microSD. If da0 isn't found the paths are correct for microSD boot alone. But, I'd really like to keep kernel files off flash storage.

It would be much better to fix the da0 detection failures. Most of them seem to happen on warm boot. Cold boots have so far all succeeded. I _think_ it's got something to do with the Pi2's usb2 interface talking to a usb3-sata bridge. A second Pi2 with a very old usb2-pata bridge has worked for five years without fault.

In hindsight, I think this is what motivated my question about standalone Raspberry Pi boot managers.

Thanks for reading, and everybody's help!

bob prohaska