Re: Pi2 bootcode.bin puzzle

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. 

In the end, mounting the microsd as root and just hanging /usr
off of it will relieve most of the limitations of flash storage.
/var, /tmp and /home can be linked to /usr, swap is hardware anyway.
This much I know how to do.

Early on there was much concern about "wearing out" flash storage.
In practice, it's turned out to be a minor issue. Write delays
can be a problem, but it really bites hard only on network traffic.
Putting the most-written filesystems on a USB disk solves most of
the problems. It would be nice to not need microSD at all once
booted, but in practical terms that isn't hugely beneficial.

Thanks for writing!

bob prohaska