Compiling u-boot-rpi3 on an rpi3

Mon May 6 21:49:06 UTC 2019

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/sys/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
> > "
> 