Date: Tue, 7 May 2019 08:07:22 +0000 From: James Shuriff <james@opentech.cc> To: bob prohaska <fbsd@www.zefox.net> Cc: Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: RE: Compiling u-boot-rpi3 on an rpi3 Message-ID: <BN7PR06MB5187F5BBC5DFA08D3C66D3DEAA310@BN7PR06MB5187.namprd06.prod.outlook.com> In-Reply-To: <20190507020329.GC45045@www.zefox.net> References: <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> <20190506214823.GB45045@www.zefox.net> <BN7PR06MB518778841ADD8E3309347549AA300@BN7PR06MB5187.namprd06.prod.outlook.com> <20190507020329.GC45045@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--_002_BN7PR06MB5187F5BBC5DFA08D3C66D3DEAA310BN7PR06MB5187namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, formatting the SD card has nothing to do with upgrading the system I on= ly brought it up to aid in explaining how one sets up the platform. Take AM= D64 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 bui= lding 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 AM= D64 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 w= hat you're looking to do). There is an installer for AMD64 but AMD64 had th= e benefit of IBM's tyranny to standardize the platform. There is no "one si= ze fits all" solution for ARM (yet). U-Boot bridges the gap a little but yo= u 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 ACP= I 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 p= hase where it's becoming a true PC architecture. The Raspberry Pi developer= s 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 buil= ding something for another Operating System you'd need to know this informa= tion but U-Boot targets "none". I'm not an expert on this part but I believ= e the compiler just makes elf binaries that are stripped of headers, allowi= ng 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 R= OM. 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 s= tage. 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 i= t 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). No= w 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 bootc= ode.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 tri= cks. 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 partitio= n in /boot/firmware (which was probably intended for something else but wha= tever). The rpi-firmware port does two things: it downloads the VideoCore b= lobs from https://github.com/raspberrypi/firmware and it builds the PSCI mo= nitor (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@www.zefox.net> Sent: Monday, May 6, 2019 10:03 PM To: James Shuriff <james@opentech.cc> Cc: Ian Lepore <ian@freebsd.org>; freebsd-arm@freebsd.org; bob prohaska <fb= sd@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-bo= ot-* ports do is tell U-Boot which defconfig to apply and possibly apply an= y 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 nee= d to know anything further than that to build U-Boot. The process for insta= lling 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 wh= atever 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 up= grade 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@www.zefox.net> > Sent: Monday, May 6, 2019 5:48 PM > To: Ian Lepore <ian@freebsd.org> > Cc: James Shuriff <james@opentech.cc>; freebsd-arm@freebsd.org; bob > prohaska <fbsd@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 instal= led. > > > 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 scr= ipt 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 ar= en'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@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/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@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 se= nder, James Shuriff (james@opentech.cc<mailto:james@opentech.cc>). > ________________________________ DISCLAIMER: This message and any attachments are intended solely for the u= se of the recipient and may contain confidential information. If you have r= eceived this message in error please delete it and promptly notify the send= er, James Shuriff (james@opentech.cc<mailto:james@opentech.cc>). --_002_BN7PR06MB5187F5BBC5DFA08D3C66D3DEAA310BN7PR06MB5187namp_ Content-Type: text/plain; name="sdboot.txt" Content-Description: sdboot.txt Content-Disposition: attachment; filename="sdboot.txt"; size=2050; creation-date="Tue, 07 May 2019 07:40:46 GMT"; modification-date="Tue, 07 May 2019 07:57:05 GMT" Content-Transfer-Encoding: base64 Iy9iaW4vdGNzaAoKc2V0IEJPT1RGUz0vYm9vdC9maXJtd2FyZS8KCnNldCBVQk9PVF9CSU5fUEFU SD0vdXNyL2xvY2FsL3NoYXJlL3UtYm9vdC91LWJvb3QtcnBpMy91LWJvb3QuYmluCnNldCBQU0NJ X0ZVTkNfUEFUSCA9IC91c3IvbG9jYWwvc2hhcmUvcnBpLWZpcm13YXJlL2FybXN0dWI4LmJpbgpz ZXQgRklSTVdBUkVfQ09ORklHX1BBVEggPSAvdXNyL2xvY2FsL3NoYXJlL3JwaS1maXJtd2FyZS9j b25maWdfcnBpMy50eHQKCiMgVGhlc2UgYXJlIHRoZSBzZWxmLWhvc3RlZCB2YXJpYWJsZXMKc2V0 IFVFRklfTE9BREVSX1BBVEggPSAvYm9vdC9sb2FkZXJfbHVhLmVmaQpzZXQgRFRCX0FXX1BBVEg9 L2Jvb3QvZHRiL2FsbHdpbm5lci8Kc2V0IERUQl9PTF9QQVRIPS9ib290L2R0Yi9vdmVybGF5cy8K CiMgVGhlc2UgYXJlIHRoZSBub3Qgc2VsZi1ob3N0ZWQgdmFyaWFibGVzCiNzZXQgTUFLRU9CSkRJ UlBSRUZJWD0vdXNyL29iai8KI3NldCBLRVJOQ09ORj1PVENDCiNzZXQgVUVGSV9MT0FERVJfUEFU SCA9ICRNQUtFT0JKRElSUFJFRklYL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9zdGFuZC9lZmkvbG9h ZGVyX2x1YS9sb2FkZXJfbHVhLmVmaQojc2V0IERUQl9BV19QQVRIPSRNQUtFT0JKRElSUFJFRklY L3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9zeXMvJEtFUk5DT05GL21vZHVsZXMvdXNyL3NyYy9zeXMv bW9kdWxlcy9kdGIvYWxsd2lubmVyLwojc2V0IERUQl9PTF9QQVRIPSRNQUtFT0JKRElSUFJFRklY L3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9zeXMvJEtFUk5DT05GL21vZHVsZXMvdXNyL3NyYy9zeXMv bW9kdWxlcy9kdGIvYWxsd2lubmVyLwoKc2V0IERUQl9BV19GSUxFUyA9IChzdW41MGktYTY0LW5h bm9waS1hNjQuZHRiIHN1bjUwaS1hNjQtb2xpbnV4aW5vLmR0YiBzdW41MGktYTY0LXBpbmU2NC1w bHVzLmR0YiBzdW41MGktYTY0LXBpbmU2NC5kdGIgc3VuNTBpLWE2NC1zb3BpbmUtYmFzZWJvYXJk LmR0YiBzdW41MGktaDUtb3JhbmdlcGktcGMyLmR0YikKc2V0IERUQl9PTF9GSUxFUyA9IChzdW41 MGktYTY0LXNpZC5kdGJvIHN1bjUwaS1hNjQtdGhzLmR0Ym8gc3VuNTBpLWE2NC10aW1lci5kdGJv KQoKc2V0IEZJUk1XQVJFX1JFUE9fUEFUSCA9IC91c3IvbG9jYWwvc2hhcmUvcnBpLWZpcm13YXJl LwpzZXQgRklSTVdBUkVfUkVQT19GSUxFUyA9IChMSUNFTkNFLmJyb2FkY29tIGJjbTI3MTAtcnBp LTMtYi5kdGIgYm9vdGNvZGUuYmluIGZpeHVwLmRhdCBmaXh1cF9jZC5kYXQgZml4dXBfZGIuZGF0 IGZpeHVwX3guZGF0IHN0YXJ0LmVsZiBzdGFydF9jZC5lbGYgc3RhcnRfZGIuZWxmIHN0YXJ0X3gu ZWxmKQoKc2V0IEZJUk1XQVJFX09MX1BBVEggPSAkRklSTVdBUkVfUkVQT19QQVRIL292ZXJsYXlz CnNldCBGSVJNV0FSRV9PTF9GSUxFUyA9IChtbWMuZHRibyBwaTMtZGlzYWJsZS1idC5kdGJvIHB3 bS5kdGJvKQoKIyAvCmZvcmVhY2ggeCAoJEZJUk1XQVJFX1JFUE9fRklMRVMpCgljcCAkRklSTVdB UkVfUkVQT19QQVRILyR4ICRCT09URlMKZW5kCmNwICRQU0NJX0ZVTkNfUEFUSCAkVUJPT1RfQklO X1BBVEggJEJPT1RGUwpjcCAkRklSTVdBUkVfQ09ORklHX1BBVEggJEJPT1RGUy9jb25maWcudHh0 CgojIC9vdmVybGF5cwpta2RpciAtcCAkQk9PVEZTL292ZXJsYXlzCmZvcmVhY2ggeCAoJEZJUk1X QVJFX09MX0ZJTEVTKQoJY3AgJEZJUk1XQVJFX09MX1BBVEgvJHggJEJPT1RGUy9vdmVybGF5cy8K ZW5kCgojIERUQgpta2RpciAtcCAkQk9PVEZTL2R0Yi9hbGx3aW5uZXIgJEJPT1RGUy9kdGIvb3Zl cmxheXMKZm9yZWFjaCB4ICgkRFRCX0FXX0ZJTEVTKQoJY3AgJERUQl9BV19QQVRILyR4ICRCT09U RlMvZHRiL2FsbHdpbm5lci8KZW5kCmZvcmVhY2ggeCAoJERUQl9PTF9GSUxFUykKCWNwICREVEJf T0xfUEFUSC8keCAkQk9PVEZTL2R0Yi9vdmVybGF5cy8KZW5kCgojIEVGSQojIGxvYWRlcl9sdWEu ZWZpIGlzIGEgaGFyZCBsaW5rIHdpdGggbG9hZGVyLmVmaQpta2RpciAtcCAkQk9PVEZTL0VGSS9C T09UCmNwICRVRUZJX0xPQURFUl9QQVRIICRCT09URlMvRUZJL0JPT1QvYm9vdGFhNjQuZWZpCg== --_002_BN7PR06MB5187F5BBC5DFA08D3C66D3DEAA310BN7PR06MB5187namp_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BN7PR06MB5187F5BBC5DFA08D3C66D3DEAA310>