Upgrading u-boot on an rpi3
Mark Millard
marklmi at yahoo.com
Sun Mar 22 19:15:02 UTC 2020
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)
More information about the freebsd-arm
mailing list