Re: Pi2 bootcode.bin puzzle

bp@www.zefox.net wrote:

Chris Elvidge <chris@internal.net> wrote:

On 28/03/2025 at 15:19, bp@www.zefox.net wrote:

Theo <theom+news@chiark.greenend.org.uk> wrote:

>
I believe that config.txt is consumed by the GPU-side firmware, which is
start*.elf.  bootcode.bin is just enough to be able to load start.elf
and config.txt from storage.  I'd guess that if that storage is USB, it's
too early to have read config.txt.

 
It looks like the path of least resistance is to let FreeBSD boot from
microSD, mount that as root and then mount the USB disk as /usr, with
/var/, /tmp/ and swap mounted from the USB device, either as links
to /usr or maybe as hard partitions.
 
That worked fine in the very early days of FreeBSD on the Pi2.
There isn't much write activity to the root filesystem in a
"production" environment, only during OS upgrades. If the microSD
is sufficiently oversized it'll last long enough.
 
I'd hoped bootcode.bin could be upgraded/tuned to boot from a
USB3 disk on a Pi2, but apparently not.
 
Thanks to everyone for writing!
 
bob prohaska
 
 
 
 

Perhaps I'm coming here too late, but the way I did it was to keep the
whole of the /boot directory on the SD card and put the whole of /
(minus /boot contents) onto the USB SSD. Change the PARTUUID parameter
in cmdline.txt to the new SSD partuuid and of course update the SSD
/etc/fstab to the new values. Worked fine for Pi2B and Pi2B+.

 
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
 
Is this what fstab would look like?
 
/dev/da0s2a mounted on /
/dev/mmcsd0s2a mounted on  /boot
/dev/mmcsd0s1 mounted on /boot/efi
/dev/da0s2d mounted on /usr
 
That doesn't look impossible, but .....
Somehow it seems wrong to me, as it requires access to /boot
"out of order".  Maybe the loader can do it. 

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