Compiling u-boot-rpi3 on an rpi3

Tue May 7 08:07:28 UTC 2019

No, formatting the SD card has nothing to do with upgrading the system I only brought it up to aid in explaining how one sets up the platform. Take AMD64 FreeBSD for example. If you were going to use AMD64 as the host system for building another different AMD64 system you'd build src and install it onto a disk attached to the system, but "make installworld" is not going to install the ESP (EFI System Partition) which is the equivalent of the FAT partition on Raspberry Pi. The setup disk will set up ESP but if you're building a ready-to-go system from another system, as you do with Raspberry Pi, you'd have to set up the ESP by hand. Let's say after booting this new AMD64 system you want to upgrade it. You'd checkout src and build it but that's not going to update bootx64.efi on the ESP (which is the equivalent of what you're looking to do). There is an installer for AMD64 but AMD64 had the benefit of IBM's tyranny to standardize the platform. There is no "one size fits all" solution for ARM (yet). U-Boot bridges the gap a little but you know there is no "one size fits all" U-Boot binary. You have to target it to a specific board. There's no ACPI on ARM you need dtb's. I'd say no ACPI on ARM is a plus for it because ACPI DSDT and SSDT tables are a bitch to parse but I still have to consider it a limitation that the hardware itself cannot provide the information an OS needs to talk to the hardware. A few years ago ARM was truly an "embedded" platform. We're in the transitional phase where it's becoming a true PC architecture. The Raspberry Pi developers had to work hard to fit all its functionality into ROM.

Gmake doesn't need to know about syscalls to build U-Boot. If you were building something for another Operating System you'd need to know this information but U-Boot targets "none". I'm not an expert on this part but I believe the compiler just makes elf binaries that are stripped of headers, allowing for u-boot.bin to be loaded wherever it needs to go. Without an OS there are no syscalls. The Raspberry Pi's ROM was programmed to know how to read in the VideoCore binaries and from there U-Boot is loaded.

This is the boot process for Raspberry Pi. First, the VideoCore loads its ROM. VideoCore is the GPU but it's heavily involved in the boot process. The ARM CPU is like a co-processor at this point. At this point the CPU is not on. The ROM loads bootcode.bin off the FAT partition. This is the second stage. Bootcode.bin starts turning on important components, like SDRAM. Next, start.elf is loaded. This turns on the peripherals and the ARM processor. Now that the ARM processor is on it can read config.txt, which instructs it to load u-boot.bin (by convention) into SDRAM. U-Boot then implements the UEFI standard to load /EFI/BOOT/BOOTAA64.EFI (FAT is case-insensitive). Now FreeBSD can attempt to find the root partition and load up the kernel.

You can play around with "strings" to get an idea of what each stage of the process is supposed to do. You can find strings like "/start.elf" in bootcode.bin. There's a string for "config.txt" in start.elf. Raspberry Pi is a fascinating study and I really want to hack the VideoCore and learn its tricks.

I attached the script I use. You'll have to modify the ROOTFS variable to /boot/msdos or wherever your FAT part is mounted, as I mount my FAT partition in /boot/firmware (which was probably intended for something else but whatever). The rpi-firmware port does two things: it downloads the VideoCore blobs from https://github.com/raspberrypi/firmware and it builds the PSCI monitor (armstub8.bin) from https://github.com/gonzoua/rpi3-psci-monitor. So make sure you have that port as well as the u-boot port.

- James Shuriff

-----Original Message-----
From: bob prohaska <fbsd at www.zefox.net>
Sent: Monday, May 6, 2019 10:03 PM
To: James Shuriff <james at opentech.cc>
Cc: Ian Lepore <ian at freebsd.org>; freebsd-arm at freebsd.org; bob prohaska <fbsd at www.zefox.net>
Subject: Re: Compiling u-boot-rpi3 on an rpi3

On Mon, May 06, 2019 at 10:50:26PM +0000, James Shuriff wrote:
> The u-boot-rpi3 port configures U-Boot with the rpi_3_defconfig in the U-Boot sources. U-Boot contains definitions with tons of boards. All the u-boot-* ports do is tell U-Boot which defconfig to apply and possibly apply any patches that are needed for that specific board. Take a look at this:
>
> https://github.com/u-boot/u-boot/blob/master/configs/rpi_3_defconfig
>
I gather that make doesn't need to "know" the target platform to create the executables. But, doesn't an install script  figure out either with system calls or explict configuration files where to put the executables?

>  That's what tells U-Boot how to build for Raspberry Pi 3. It doesn't need to know anything further than that to build U-Boot. The process for installing U-Boot isn't specific for FreeBSD it would be similar for any OS that supports U-Boot. The config.txt file tells the firmware where to find the next stage of the boot process but theoretically you could name the file whatever you want.
Yes, but in practice the names are well established on any given platform.
Is the problem in identifying with sufficient detail the exact platform?

> I wrote a script that sets up the boot files, if you're interested.
I am interested, but:

I'm puzzled why it's not done by default during a normal world or kernel upgrade if the firmware or u-boot sources are updated. Is there some sort of ambiguity that can't be resolved?

> Formatting the SD card isn't too much of a trial, either. There's no MBR boot code needed.
>
I _think_ that's a different problem than upgrading a working system, no?

Thanks for replying!

bob prohaska

>
> -----Original Message-----
> From: bob prohaska <fbsd at www.zefox.net>
> Sent: Monday, May 6, 2019 5:48 PM
> To: Ian Lepore <ian at freebsd.org>
> Cc: James Shuriff <james at opentech.cc>; freebsd-arm at freebsd.org; bob
> prohaska <fbsd at www.zefox.net>
> Subject: Re: Compiling u-boot-rpi3 on an rpi3
>
> On Mon, May 06, 2019 at 03:18:10PM -0600, Ian Lepore wrote:
> > On Mon, 2019-05-06 at 14:08 -0700, bob prohaska wrote:
> > > Ok, now I'm thoroughly confused 8-) It sounds as if the guiding
> > > assumption behind the u-boot-rpi3 port is that it _isn't_ being
> > > self-hosted, but rather part of a cross-compile to be copied onto
> > > an installer medium. This is at variance with "normal" ports, but
> > > consistent with an embedded target that never self-hosts.
> > >
> > > Looking at my own rpi3's /boot directory, most of the files are
> > > dated May 4th, the last time world and kernel were rebuilt and installed.
> > > Are those files genuinely up-to-date, or merely fresh copies of
> > > old versions from /usr/share.....?
> > >
> > > On a Pi3 that _is_ selfhosting, will updating rpi-firmware and u-
> > > boot-rpi3
> > > and then updating world and kernel complete the firmware and
> > > u-boot update?
> > >
> > > Apologies for the confusion, and thanks for any clarification!
> > >
> > > bob prohaska
> > >
> >
> > Updating boot stuff is always a semi-manual procedure.  For example,
> > on
> > x86 systems after doing make installworld you have a new boot0 and a
> > new gptboot or zfsboot, but they've only been installed to /boot.
> > It's up to you to run the gpart commands that install those things
> > to the outside-the-ufs-filesystem parts of the disk drive.
> >
> > The same concept applies to arm and other embedded systems, which
> > have an even more diverse set of "outside the ufs filesystem" things
> > to deal
>
> Apparently I'm not understanding the significance of "outside of ufs" in this situation. On the Pi3 a simple cp works. I'd think that an install script could run gpart, certainly more reliably than I can!
>
> > with.  In the embedded case it's not necessarily even safe or
> > possible to install the various boot bits to /boot, because there
> > may be items that have the same name (u-boot.bin for example) but
> > actually differ depending on SoC or system type.
>
> Doesn't the system have to know that anyway to compile in the first place?
>
> > So installing boot bits to
> > /usr/local/share/u-boot then making the user handle the last bit of
> > the install is about the only option.
> >
>
> If it's not practical to make an installer sufficiently platform-aware to handle "the last bit" then a man page would really help. U-boot updates aren't needed often and a botched attempt is hard to recover from.
>
> Thanks for reading!
>
> bob prohaska
>
>
> > > > -----Original Message-----
> > > > From: James Shuriff
> > > > Sent: Monday, May 6, 2019 3:42 PM
> > > > To: bob prohaska <fbsd at www.zefox.net>
> > > > Cc: freebsd-arm at freebsd.org
> > > > Subject: RE: Compiling u-boot-rpi3 on an rpi3
> > > >
> > > > /boot/msdos is an arbitrary location. It's not even required to
> > > > mount it. I mount my FAT partition elsewhere. Some boards don't
> > > > even have u-boot in the filesystem they dd it directly onto the
> > > > disk. Also consider you don't have to build the port on the
> > > > Raspberry Pi, so there would be no way to install u-boot from
> > > > the host system without knowing where the SD card is mounted.
> > > >
> > > > The rpi-firmware port also puts stuff in /usr/local/share.
> > > > That's the port that has most of the files needed for the
> > > > Raspberry Pi's FAT partition. Here is a list of the files in the
> > > > FAT partition and where you can get them from:
> > > >
> > > > /LICENSE.broadcom: rpi-firmware port
> > > > /armstub8.bin: rpi-firmware port
> > > > /bcm2710-rpi-3-b.dtb: rpi-firmware port
> > > > /bootcode.bin: rpi-firmware port
> > > > /config.txt: rpi-firmware (config_rpi3.txt)
> > > > /dtb/*: FreeBSD Build Output
> > > > (/usr/obj/usr/src/arm64.aarch64/sys/$KERNCONF/modules/usr/src/sy
> > > > s/ m odules/dtb or /boot/dtb on the Raspberry Pi)
> > > > /fixup*.dat: rpi-firmware port
> > > > /overlays/*: rpi-firmware port
> > > > /start*.elf: rpi-firmware port
> > > > /u-boot.bin: u-boot-rpi3 port
> > > >
> > > > - James Shuriff
> > > >
> > > > -----Original Message-----
> > > > From: bob prohaska <fbsd at www.zefox.net>
> > > > Sent: Monday, May 6, 2019 3:29 PM
> > > > To: James Shuriff <james at opentech.cc>
> > > > Cc: bob prohaska <fbsd at www.zefox.net>
> > > > Subject: Re: Compiling u-boot-rpi3 on an rpi3
> > > >
> > > > On Mon, May 06, 2019 at 06:18:35PM +0000, James Shuriff wrote:
> > > > > Copy /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin to
> > > > > /boot/msdos.
> > > > >
> > > >
> > > > Ok, that did the trick.  Is there some particular reason make
> > > > install didn't perform the copy?
> > > >
> > > > Thank you very much!
> > > >
> > > > bob prohaska
> > > >
> > > >
> > > > > - James Shuriff
> > > > >
> > > > > -----Original Message-----
> > > > > From: owner-freebsd-arm at freebsd.org <
> > > > > owner-freebsd-arm at freebsd.org> On Behalf Of bob prohaska
> > > > > Sent: Monday, May 6, 2019 2:05 PM
> > > > > To: Mika??l Urankar <mikael.urankar at gmail.com>
> > > > > Cc: freebsd-arm at freebsd.org; freebsd-ports at freebsd.org
> > > > > Subject: Re: Compiling u-boot-rpi3 on an rpi3
> > > > >
> > > > > On Mon, May 06, 2019 at 06:20:45PM +0200, Mika??l Urankar wrote:
> > > > > > Le lun. 6 mai 2019 ?? 17:19, bob prohaska
> > > > > > <fbsd at www.zefox.net> a ??crit :
> > > > > > >
> > > > > > > On Mon, May 06, 2019 at 03:22:31PM +0200, Mika??l Urankar
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > It builds fine here on aarch64, do you have
> > > > > > > > security/openssl* installed?
> > > > > > > >
> > > > > > >
> > > > > > > Yes, security/openssl is installed. I didn't use it by
> > > > > > > default because of earlier reports of trouble. The system
> > > > > > > reminds me that
> > > > > >
> > > > > > Delete it and rebuild u-boot-rpi3
> > > > > >
> > > > >
> > > > > That certainly helped, make now runs successfully.
> > > > >
> > > > > But, make install didn't update anything in /boot/msdos.
> > > > > There seem to be three copies of u-boot-bin floating around,
> > > > > with identical size. Should I copy one manually to
> > > > > /boot/msdos, and does it matter which one?
> > > > >
> > > > > Thanks for reading and your help!
> > > > >
> > > > > bob prohaska
> > > > >
> > > > > _______________________________________________
> > > > > freebsd-arm at freebsd.org mailing list
> > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > > > > To unsubscribe, send any mail to "
> > > > > freebsd-arm-unsubscribe at freebsd.org"
> > > > > ________________________________
> > > > >  DISCLAIMER: This message and any attachments are intended
> > > > > solely for the use of the recipient and may contain
> > > > > confidential information. If you have received this message in
> > > > > error please delete it and promptly notify the sender, James
> > > > > Shuriff ( james at opentech.cc<mailto:james at opentech.cc>).
> > > > >
> > > >
> > > > ________________________________
> > > >  DISCLAIMER: This message and any attachments are intended
> > > > solely for the use of the recipient and may contain confidential
> > > > information. If you have received this message in error please
> > > > delete it and promptly notify the sender, James Shuriff (
> > > > james at opentech.cc<mailto:james at opentech.cc>).
> > > >
> > >
> > > _______________________________________________
> > > freebsd-arm at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > > To unsubscribe, send any mail to
> > > "freebsd-arm-unsubscribe at freebsd.org
> > > "
> >
> ________________________________
>  DISCLAIMER: This message and any attachments are intended solely for the use of the recipient and may contain confidential information. If you have received this message in error please delete it and promptly notify the sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc>).
>
________________________________
 DISCLAIMER: This message and any attachments are intended solely for the use of the recipient and may contain confidential information. If you have received this message in error please delete it and promptly notify the sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc>).
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sdboot.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20190507/f262973c/attachment.txt>