Date: Sun, 22 Mar 2020 15:32:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Upgrading u-boot on an rpi3 Message-ID: <23A16E57-7902-4734-825D-5A40CF07CE4F@yahoo.com> In-Reply-To: <7ADF6512-A998-420A-8FD9-C7AA8F08E20D@yahoo.com> References: <20200318054243.GA67865@www.zefox.net> <4B4CF1DF-F3C0-4ED3-AAC0-4FC0A8182787@yahoo.com> <20200318172339.GB67865@www.zefox.net> <456B1ED8-B335-405B-AB7B-B65968631323@yahoo.com> <20200319001353.GA70624@www.zefox.net> <20200322174257.GA84906@www.zefox.net> <7ADF6512-A998-420A-8FD9-C7AA8F08E20D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23A16E57-7902-4734-825D-5A40CF07CE4F>