Date: Mon, 06 May 2019 15:27:24 -0600 From: Ian Lepore <ian@freebsd.org> To: James Shuriff <james@opentech.cc>, bob prohaska <fbsd@www.zefox.net> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Compiling u-boot-rpi3 on an rpi3 Message-ID: <a289f624652bd7ea483ce6e21c4c17f66c81deff.camel@freebsd.org> In-Reply-To: <BN7PR06MB518770D53F99CF766635C25AAA300@BN7PR06MB5187.namprd06.prod.outlook.com> References: <20190506020115.GA40421@www.zefox.net> <CAJwjRmS4jFxjocLWxTFmP7z1_ovT-E-ktiettV3dmn5XdB9XcQ@mail.gmail.com> <20190506151908.GA43714@www.zefox.net> <CAJwjRmRmaYbvQCh7Cy8TBKsExZ2zAHj=YAGWixzfSO0M4Ez=TA@mail.gmail.com> <20190506180501.GB44000@www.zefox.net> <BN7PR06MB5187B86ABD88FD179C931316AA300@BN7PR06MB5187.namprd06.prod.outlook.com> <20190506192919.GA44506@www.zefox.net> <BN7PR06MB5187306D1FBAA7F493F553FDAA300@BN7PR06MB5187.namprd06.prod.outlook.com> <BN7PR06MB5187183BB26A8859DEA02B6DAA300@BN7PR06MB5187.namprd06.prod.outlook.com> <20190506210832.GA45045@www.zefox.net> <81a9c8cd930ae5740a3245c0f956fc280cc5f473.camel@freebsd.org> <BN7PR06MB518770D53F99CF766635C25AAA300@BN7PR06MB5187.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2019-05-06 at 21:24 +0000, James Shuriff wrote: > You have to cross compile regardless of what your host system is. U- > Boot uses GNU's toolchain, unfortunately. That didn't used to be true. GCC was required to cross-compile on amd64, but native compiles were done using the preinstalled host clang. That was fixed back in like 2016, maybe even earlier. Hmmm, for armv6/7 that is; maybe it never worked for aarch64? -- Ian > Rpi-firmware will also install files in /usr/local/share because, as > previously stated, it's the safest option. I don't know how often the > VideoCore blobs get updated but if you want the latest and greatest > replace what's in your /boot with the blobs from rpi-firmware, U-Boot > from u-boot-rpi3, the dtb's from /boot, and bootaa64.efi from > /boot/loader_lua.efi (same as /boot/loader.efi, it's a hard link). > > If you want a completely up to date system install the rpi-firmware > port and copy over newer versions of the files. You'll need the dtb's > from /boot and you'll have to update bootaa64.efi from loader_lua.efi > in /boot. > > - James Shuriff > > -----Original Message----- > From: Ian Lepore <ian@freebsd.org> > Sent: Monday, May 6, 2019 5:18 PM > To: bob prohaska <fbsd@www.zefox.net>; James Shuriff < > james@opentech.cc> > Cc: freebsd-arm@freebsd.org > Subject: Re: Compiling u-boot-rpi3 on an rpi3 > > 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 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. 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. > > -- Ian > > > > > On Mon, May 06, 2019 at 07:46:03PM +0000, James Shuriff wrote: > > > EFI/BOOT/bootaarch64.efi is the same as /boot/loader_lua.efi > > > which > > > is also the same as /boot/loader.efi. You can use a different > > > loader, of course, but the Lua loader is the default. > > > > > > - James Shuriff > > > > > > -----Original Message----- > > > From: James Shuriff > > > Sent: Monday, May 6, 2019 3:42 PM > > > To: bob prohaska <fbsd@www.zefox.net> > > > Cc: freebsd-arm@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@www.zefox.net> > > > Sent: Monday, May 6, 2019 3:29 PM > > > To: James Shuriff <james@opentech.cc> > > > Cc: bob prohaska <fbsd@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@freebsd.org < > > > > owner-freebsd-arm@freebsd.org> On Behalf Of bob prohaska > > > > Sent: Monday, May 6, 2019 2:05 PM > > > > To: Mika??l Urankar <mikael.urankar@gmail.com> > > > > Cc: freebsd-arm@freebsd.org; freebsd-ports@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@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@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@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@opentech.cc<mailto:james@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@opentech.cc<mailto:james@opentech.cc>). > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@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@opentech.cc<mailto: > james@opentech.cc>). >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a289f624652bd7ea483ce6e21c4c17f66c81deff.camel>