Upgrading u-boot on an rpi3

[Mark Millard]

On 2020-Mar-22, at 12:14, Mark Millard <marklmi at yahoo.com> wrote:

> 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.

I probably should have reported that I was ignoring the
-DBATCH part. I do not know the specifics of why it was
mentioned and I've never explicitly used it.

>> 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)