Upgrading u-boot on an rpi3

[Mark Millard]

On 2020-Mar-22, at 10:42, bob prohaska <fbsd at www.zefox.net> wrote:

> I'd lke to make some "notes to self" for upgrading u-boot on 
> a self-hosted rpi3. Here's what I think got done: 

U-boot is over specific terminology: it is 1 of 3 things. . .


Port's sysutils/u-boot-rpi3 (after installation) :

cp -aRx /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin /boot/msdos/



The following 2 ( sysutils/rpi-firmware and
/boot/loader.efi ) are not part of u-boot but
are involved/required for booting . . .


Port's sysutils/rpi-firmware (after installation) :

(If you have tailored materials in /boot/msdos/config.txt ,
there is the need to preserve your content. So the below 2
copies might not be the right thing to do up front: it
would involved more of a merge activity than just copying.)

cp -aRx /usr/local/share/rpi-firmware/* /boot/msdos/

Deal with /boot/msdos/config.txt having the right content,
such as:

cp -aRx /boot/msdos/config_rpi3.txt /boot/msdos/config.txt


FreeBSD's /boot/loader.efi (after installworld):

cp -aRx /boot/loader.efi /boot/msdos/EFI/BOOT/bootaa64.efi

So . . .

> Build and install the u-boot-rpi3 port using -DBATCH.
> Copy the resulting
> /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin
> to
> /boot/msdos/u-boot.bin

Yep.

> Following buildworld/installworld copy and rename
> /boot/loader.efi
> to
> /boot/msdos/EFI/BOOT/bootaa64.efi

Yep.

> Have I overlooked anything important?

When sysutils/rpi-firmware has updates it too
is involved.

I'll note that sysutils/rpi-firmware has the
armstub8*.bin materials and they are not
from the same places as the rest of the
sysutils/rpi-firmware materials: different
upstream place. So either upstream can lead
to a sysutils/rpi-firmware update.

> As an aside, the Pi3 is now at r359195 and
> seems to work normally. It does seem to become 
> unresponsive for long periods during svnlite up
> or any process involving storage I/O despite top 
> reporting ~98% idle. However, it hasn't crashed yet.

Interesting. If "gstat -spod" is already running
first, does it show anything interesting for the
unresponsive time periods?


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)