FreeBSD ARM : Before Kernel
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Vadot, Emmanuel
This lecture describe the boot process of FreeBSD on ARM and the ongoing effort to upstream our local patches for U-Boot (An opensource bootloader for embedded devices) and DTS (DeviceTree Source) into the Linux Kernel. Booting FreeBSD on an ARM board relies on three things : U-Boot (An opensource bootloader for embedded devices) ubldr (a version of loader (8) using the U-Boot API) DTB (Devicetree Blob, a file that describe the hardware that we are running on). You, of course, also need drivers for the board System On a Chip but this is beyond this talk. Therefore it is important to keep up with U-Boot release as adding support for a new board will require support for it in U-Boot. It is also important to keep up with the DTS (Devicetree Syntax, the file that will be converted in a DTB) that we import from the Linux Kernel project as new board means new DTS file for it.
 So, hello everyone. My name is Emmanuel Vado. I'm a new at FreeBSD.org. And we'll be talking about what's happening on FreeBSD before the kernel is even loaded on our board, looks so specifically bootloaders. So we talk about Sheeboot, which is main bootloader that we use on our board for FreeBSD. We will talk about the Yeboot API, which is a concept that we are using for our loader on FreeBSD. We talk about the Distroboot CMD, which is a generic way to boot OSes on Yeboot. We talk about EFI, which Yeboot is using also. The master Yeboot port that was created somewhere three or four months ago, a little note on DTS, which are diva3 files that are describing the hardware you are running on, and some notes about how to upstream on Yeboot and Linux community. First I would like to thank my employer, Gandhi, which won all of me to be there while I'm not talking about anything that I do for them, and is also paying for the travel and accommodation expense. For those who don't know, Gandhi is a registrar, so you can buy a domain name certificate from us. We also have some hosting products, we have some simple hosting, where you can buy some container, where you can host your PHP, Ruby, or Python application, and also you can buy some VM. And we have FreeBSD VM 11.0 since sometime now. A little bit of warning, there's a lot of acronyms in this talk. I will try to explain every acronym that I will use, but if I forget and you don't get one, don't hesitate to ask me to explain it. So Yeboot. Yeboot means universal boot loader. It's a de facto standard for onboard, MIPS board, ARM64, it even supports PowerPC, and X86. It's really used in the embedded world. It's mostly or mainly split in two parts, SPL, which is a secondary program loader, and the main Yeboot, which does all the things, all the device, and the immersion, initialization, et cetera. And it can execute multiple types of executable. The first one is Yeboot image, which is a specially crafted image for Yeboot, which we are not using on FreeBSD. I think NetBSD is using the Yeboot image to boot their kernel. Recently, there was an addition of the fit image. Fit means flatten image tree or something like that. This is an image where you describe it using the DTS syntax. We will see a letter of what is exactly a DTS. It supports ELF and Robinary, which we are using on FreeBSD to boot our loader, and it also supports EFI since a year ago or something like that. So the way that's onboard our booting is very different than the traditional PC. On the traditional PC, you have your BIOS at some memory location. And when the processor boots, it will simply execute the instruction at this location. On Harmony, this is a bit the same, but the first stage, so the boot ROM is inside the SoC. Most of the time, you cannot modify it. It's burned by the SoC maker. And what the boot ROM does is simply bootstrap the secondary loader. So that's why we call it SPL, which can be found in different source. For example, SD cards. This is mainly used for the common onboard. This can be some SPL flash. It can boot sometimes over USB, sometimes even over a Ethernet, et cetera. So in the case of Uboots, the SPL is also done by the Uboot community. It's a program that is specified for each board, each SoC. And what it does is initialize the DRAM, so the main RAM for the board, talk to the DRAM controller to set it at the right frequency, and then load the main Uboots image into the DRAM and execute it. On FreeBSD, Uboots then loads UBLDR. UBLDR is a specially-crafted version of loader that is using the Uboot API, which I will talk about in a minute. Then UBLDR is loading the DTB. So DTB is a compiled form of DTS. So this is a binary blob that is describing the hardware, every peripheral that you have either on the SoC or on the board. And then it loads the kernel and executes the kernel. So the Uboot API is a Cisco-based API. It was developed at the beginning by Semialf, who is doing a lot of FreeBSD-embedded related work. It gives us access to console, so you can have your, you can put some strings on the serial. And to some devices, mostly storage and network. So UBLDR, using this standard Cisco-based API, can enumerate SD card, this device, sometimes USB work. You can also enumerate network interfaces. If you, Bielder, want to PXE boot some stuff, et cetera. We used to have a lot of local patches in all our different ports from the different boards in the port street. So the first thing that I did was take those patches, see if they still make sense, because most of the Uboots that we used to have were from something like two or three years ago, maybe. Clean up, do some more, and upstream everything in Uboots, so in many Uboots. And what I did also is add a new K config. So Uboot is using K config, like the Linux kernel, to configure for specific targets. What we used to do in the port street is had the config API defined in some include file somewhere, depending on the board. So it was not really clean to do that. So I just added a new config API. So you just gmake menu config, select the config API or whatever, and then you have an API compiled Uboots, which is needed for UBLDR. Since a year or two ago, Uboot is porting the device model, so that's what the DM means here, from the Linux kernel. This is mainly helping them to port some driver from Linux to Uboots easily. So Uboot API is not actively maintained, and every Ethernet driver that has been reworked, so rewrite to use the new device model driver, don't work with ads, which means you cannot use Ethernet device on UBLDR, but you can use Ethernet device on Uboot directly. I started to look how hard it would be to port the Uboot API to support the new Ethernet device model. It does not seem very hard, but I found another way to do it more easily. So I won't be touching any more the API for, I think that it's, follow it safe. It's okay to use it, but we want to go away from it, because I'm the only guy who have ever written some code in the last three or four years, something like that, and I don't want to call it anymore. So the distroboot CMD, as I said before, it's a generic way to finding Linux in the possible available media on the board. Uboot uses a shell-like scripted language, so what the distroboot CMD does is scanning all the available media, so SD card, USB, Ethernet, et cetera. And if you find a Linux kernel in EtherD, it will simply load it. And this is the way that most of the Linux distribution are booting Linux with Uboot. I simply had it config distro3bSD, so it might be a little bit weird to see distro3bSD at the same time, but this is how the config are named in Uboot. And what it does is simply search for Ubuilder in the available media, and if it's found, it will be executed directly. So we won't have to modify the boot script from Uboot. What I want is people compiling mainstream Uboots, enabling one or two options to support 3bSD, copy it on the SD card for the Raspberry Pi, Bigelbone, or whatever, and everything just works. These parts are almost upstream, I ran into some problems for other stuff on the caches, flushes, stuff I won't be talking about today. But I will resume my work soon, and I think this we could have for the releases of September or Uboot, this part, everything upstream. So this is what it looks like, so nothing really interesting. So it's shell-based language, so if we found Ubl.bin, so yeah, we have two loaders on 3bSD. Currently, we have the bin version and the alt version. The alt version is compiled for every board because it has a specified load address, while the bin version is positioned in the opponent executable, which can be compiled for every board and running on every board. I don't think we need any more of the alt version of the Ubl.dr. I need to check every Uboot port to see if they still use them and replace that, then we can deprecate the alt version of the Ubl.dr. So EFI, EFI means extended firmware interface, if I'm not mistaken. I should say UEFI, EFI is mainly for the 1.0 or 1.x releases, while UEFI is for the 2.x releases. It started for IS-64, so the Italian platform from Intel. It's a new way of doing BIOS, basically. It's a specification. You have a reference implementation, which most of the hardware makers are using. So if you have a Lenovo or HP laptop, you're mostly using the Tiena core implementation. It's open source. A year ago, when some Uboot developer from SUS wanted to add... wanted to add EFI support for Uboot, he started looking at Tiena core implementation. Apparently, he wasn't pleased because the code quality, for what he said, I have never looked at the Tiena core source code, so I don't know. So he decided to re-implement everything. And by re-implementing everything, I mean re-implementing only the stuff that he cared about. So Uboot does have some UEFI support, but it doesn't support everything that UEFI specification states. And even if it does, sometimes it does not really work. They took some way around some part of the specification. But yeah, things are coming along, things are more cleaner right now, but we are still missing a lot of things in the UEFI implementation of Uboot. The reason I want to use UEFI even on ARM32, it's because we have one loader to rule them all then. It's simpler to use only loader to UEFI, not care about UBLDR anymore, loader to UEFI is used on ARM64 already, it's used on MD64 of course. The other reason is that we can easily have video outputs via UEFI graphic output protocol. We don't have a really good video output support on 3BSD on ARM board. Uboot have some relatively correct frame buffer support. And since Uboot support UEFI and most of the board that it supports, supports the graphic output protocol, for us it would mean that we could directly use UEFI frame buffer from 3BSD to have video outputs. At least basic one, you couldn't have some dual screen or have some LVDS and HDMI at the same time, but you could have some basic output screen which would be good. Also there is some active development compared to the Uboot API as I was saying. It is mostly done by SUSE which is always good to have a company that is backing the development of some technology. Uboot API, as I say, I'm the only one who ever committed code since the last three years or four years. Here we have a company backing the code so it's better to use that. Right now the UEFI status, the console mode are all correct. This is the first problem I ran into when I wanted to boot the Bigelbong Black with UEFI. So serial console mode were not prob correctly. I think that we're seeing everything is upstream now. We do have some local patch that I have on upstream. It's to export the MBR partition. So on UEFI you can either talk to the disk, to the road disk directly or you can ask the UEFI implementation, okay, give me the list of partition that this device has. UEFI is really tied to GPT partitioning. MBR partitioning should not exist in the UEFI world except for the PMBR, the protective MBR. The thing is most of the embedded world and embedded board don't support GPT partitioning. If you take the Bigelbong Black, for example, the weight boot is the SSE boot ROM. We'll look at the first bootable fat 12 or 16 or 32 partition in the MBR table and we load some file from it. This cannot work with GPT partitioning. So the patch that I've done and not yet upstream, as this is the reason mostly, is a bit of a hack because you shouldn't expose MBR partition in a UEFI world. That we have no choice right now for this kind of board who are relying on MBR partitioning. We still have issue in our SM BIOS code. So you boot for some unknown reason, decided to expose some SM BIOS data. So that expose board information, board serial, board maker, etc. Our SM BIOS code is made for X86. So it doesn't care about alignments. And of course on ARM, you need to have some strict alignments. So I need to work on the SM BIOS code or maybe totally disable SM BIOS code on the ARM world because we don't care a lot about SM BIOS information. We have all the information in some other places. So the Uboot master port was created five or six months ago by Warner Lush. As I say, we used to have a lot of different Uboot versions for each board. And what I was working on, upstreaming everything from our ports to the menu boots. Warner decided to create a master port that every board will be using. So we have one place, one unique place where all our patches are sitting before I upstream them. For now, it's tracking is GitHub fork. We have created a repository under the FreeBSD organization GitHub group. We need to measure switch. It supports all the main boards that are using the generic kernel on FreeBSD. So all the old window board, the AM335X, which is the big bone, and some IMX6 board. We plan to extend it to support also the Raspberry Pi, Uboot or whatever device that is running FreeBSD should be now using this Uboot master port as all the patches needed for FreeBSD. On DTS and DTB, as I said, DTS, Devastree, Sources, our file describing the hardware. Because on ARM, most of the hardware in the SoC is not enumerable like a PCI bus. So you have to know that you have some internal code at this address. And either you out-collect the data inside the kernel or you have a file somewhere describing the hardware. We used to have a lot of custom DTS in FreeBSD because at the time, we were not sure that we could use the one from Linux. No thing that being resolved. We can use them. No problem. But we still have some patch for some DTS or some total custom one like all the Marvel board are using some custom DTS file. I have a little DTS two or three months ago, so now we are sync with Linux 4.10. I should update them to Linux 4.12, I think it's out. And in base, we have DTS which is a Devastree compiler, 1.4.3, which supports overlays. The reason we had patch on the DTS is because at the time, you couldn't have DTB overlay. Now that DTC supports overlay officially, what we could do is always use the Linux DTS. And if we want to add some custom nodes or some nodes that aren't present in the Linux DTS and we don't want to wait the next release of Linux, we can simply add an overlay or loader, can load the overlay DTB. So what does simply takes two DTB merge them together and use all the information. So this is something that we should do. I've not yet looked at really how can we do it properly, but yeah, this is something that we should do. Upstreaming. When I started to say to people that I wanted to upstream our UBIT patches and our DTS patches, so either through Linux for the DTS or through UBIT for UBIT, people told me, you know, Linux don't care about FreeBSD and UBIT don't care about FreeBSD too. Well, this is not true. This is definitely not true. A lot of people in Linux like that we are using the same DTS as them because we don't have the same problem. So upstreaming DTS changing, DTS change, sorry, if the change looks okay, looks normal, they will be accepted. Even if it's for FreeBSD, I've even upstreamed some change saying the Gitlog that the Linux driver doesn't use this property, but FreeBSD uses this, so we need to add this and this was accepted. So there is a commit in the Linux tree that's saying this is for FreeBSD, which is cool. And on UBIT, this is the same. They do care about FreeBSD because they know how Linux works, they know all the problems, but we have some other problems and they are happy to resolve all the problems that they could have. So current for to work, I need to finish EFI and switch FreeBSD 12 current MV6 to using it and not using UBLD anymore. As I said, most of it is working. There is a issue with the SM BIOS code. I need to test the fit image, so fit the flattened image tree. It's a new, relatively new image type for UBUT. Most of the recent, I'm 64 board, the low end one, are using fit image to boot something. I've managed to boot all other which was crafted inside the fit image. So we will see how we will do things. Do we embed the loader on the fit image? Do we embed the kernel directly? I don't know. A few things. One error for its UBUT master port. Alexander Graf, who did the EFI in UBUT, he was very responsive for FreeBSD support on it. He even said in some of his talk at the embedded Linux conference that we were the first OS to use the EFI functionality which was developed by Suze. The thing is OpenBSD did it first, but I'm happy taking the blame for that. Tom Rini, which is a UBUT master guy, again, is very responsive to the FreeBSD problem and it helped me a lot to correctly send my patches, et cetera. And of course, a lot of other people were working on that. Thank you. As of who will be all, if you have any questions, we'll be happy to answer them. Yeah. It's not so much a question, it's more a bit of background reason why the EFI mutation was to enable Suze guys to utilize Grub. Grub, yeah. Or things like snapper, rollback. Yeah, yeah. They want to have a common, it's the same reason that we want to use EFI on FreeBSD. They want a common point. So they want to use Grub and the easiest way to use Grub is using the EFI version of Grub. You should repeat comments for the people. Oh, yeah, yeah, yeah. So the common was that the reason that Suze guy did the EFI implementation was to use Grub because they want to use a snapshot, et cetera, from the ButterFS or whatever. And they want a common point of entry for the OS. So EFI is the solution for that. And this is the same reason that I want to use EFI for FreeBSD on ARM64, et cetera. Sorry, yeah. I know I asked you about the, also, you have any critical way of debugging the code you are writing. So, for example, we had a lot of problems on bringing up the hard norm on TV2, especially in caches. Have you encountered such problems in Uboot? And how do you find the problem? Yeah. So the question was, how many, how do I debug Uboot while doing Uboot development? Print F. Mostly. Mostly print F. I don't have any board with JTAG. Well, I have, but I don't have, either I have or, and I don't have the adapter or I don't have JTAG. I think the simple way will be using JTAG and open a CD, I think it is. Open a CD. I've used that for other Cortex, for other ARM chips. It worked great. I never used that for Cortex A. I'm sure the support is correct too. But yeah, for Uboot, I mainly do print F, which cannot suck, but cannot work. You don't have print F, you turn on an LED. Yes, that's the other way to go. Flash LED. Yeah, exactly. Another, yeah. Are you aware of the level of support of NetBSD and OpenBSD in Uboot right now? How much work do we need to do here at some level? So the question was, do I have any info on the level of support of NetBSD and OpenBSD for Uboot? So OpenBSD guys stepped right after the first Uboot patch where in the Uboot tree, they step in and say, okay, we want to use UFI. I think that they didn't have a UFI loader for MD64 and that their first UFI loader is for ARM. So right now, they're using EFI, apparently everything works for them. They just, I've looked at the code, they just bootstrap the kernel, look at the FFS partition or whatever. So they're not using the partition explored by UFI, they're using Rode disk so they don't have the problems that I ran into. And for NetBSD, I think every board using Uimage, which is Uboot image, and you, I don't know for Tegra because for Tegra, you have DTS. For all the other boards, you don't have DTS and everything is added in the kernel. So you just take the kernel, make a Uboot image and give that to Uboot on a FAT partition or something that Uboot can read, so either FAT or X2 or whatever. For Tegra, I don't know how do you do that. You don't know either, I swear. Any more questions? Yeah. So I take the, you said that people are happy with trying to keep aligned on DTS and these partners are happy, they're happy, because ASEAN is, they're up close to a global arena, so when people thought about these, they did break sup because of all about DTS discussion. I don't know, I wasn't there at the time on the FreeBSD project. But when I started doing FreeBSD work one or two years ago on all window boards, we were still using some custom DTS, and the first thing that the FreeBSD developer told me is the first thing that you should do is using the upstream one. We don't want to use a custom one anymore. So I don't know how it went. But right now I think everyone agrees that we should use a common DTS across OSs. I think one of the arm maintenance for DTSD to be will be a FSD cap. Okay. Is this Mark Rutland? Yeah, okay. Yeah. Good. Yeah. So the reason we're not... we don't use the Uboot image format for loading the panels and we just set it all out in the order? So the question was, is there any reason that we are not using the Uboot image format for the loader or the kernel? The main reason is that the Uboot image you have to specify the loading address and execute address, etc. So we have to build a Uboot image for every board that we support, which is kind of annoying because right now we have the generic army image kernel as of six months ago. We have some UBLDR, which is positioned in the opponent executable. So we are running all this problem of specifying the loading and executing address. But this is the same for fit image. You need to specify the address. So this is a new format, a new image format. I don't know why at the time where the Uboot API was made, why it was made. So, yeah, I don't know why at the time this was made, it would have been much easier for us if we took the netBSD direction, for example. So, yeah, I don't know. But EFI for me is... solve all of our problems. Is EFI interface normal to other architectures? Yeah, so the question was, is the EFI interface portable on other architecture? And if I remember correctly, it works on ARM, ARM64, X86. I think that's the only platform that has at least some development on it. I don't think it would be too much trouble to put it to PowerPC. Try it. And tell me after if it works. But, yeah, it should work. Okay, thank you.
 So, hello everyone.  My name is Emmanuel Vado.  I'm a new at FreeBSD.org.  And we'll be talking about what's happening on FreeBSD before the kernel is even loaded  on our board, looks so specifically bootloaders.  So we talk about Sheeboot, which is main bootloader that we use on our board for FreeBSD.  We will talk about the Yeboot API, which is a concept that we are using for our loader  on FreeBSD.  We talk about the Distroboot CMD, which is a generic way to boot OSes on Yeboot.  We talk about EFI, which Yeboot is using also.  The master Yeboot port that was created somewhere three or four months ago, a little note on  DTS, which are diva3 files that are describing the hardware you are running on, and some  notes about how to upstream on Yeboot and Linux community.  First I would like to thank my employer, Gandhi, which won all of me to be there while I'm  not talking about anything that I do for them, and is also paying for the travel and accommodation  expense.  For those who don't know, Gandhi is a registrar, so you can buy a domain name certificate from  us.  We also have some hosting products, we have some simple hosting, where you can buy some  container, where you can host your PHP, Ruby, or Python application, and also you can buy  some VM.  And we have FreeBSD VM 11.0 since sometime now.  A little bit of warning, there's a lot of acronyms in this talk.  I will try to explain every acronym that I will use, but if I forget and you don't get  one, don't hesitate to ask me to explain it.  So Yeboot.  Yeboot means universal boot loader.  It's a de facto standard for onboard, MIPS board, ARM64, it even supports PowerPC, and  X86.  It's really used in the embedded world.  It's mostly or mainly split in two parts, SPL, which is a secondary program loader,  and the main Yeboot, which does all the things, all the device, and the immersion, initialization,  et cetera.  And it can execute multiple types of executable.  The first one is Yeboot image, which is a specially crafted image for Yeboot, which  we are not using on FreeBSD.  I think NetBSD is using the Yeboot image to boot their kernel.  Recently, there was an addition of the fit image.  Fit means flatten image tree or something like that.  This is an image where you describe it using the DTS syntax.  We will see a letter of what is exactly a DTS.  It supports ELF and Robinary, which we are using on FreeBSD to boot our loader, and it  also supports EFI since a year ago or something like that.  So the way that's onboard our booting is very different than the traditional PC.  On the traditional PC, you have your BIOS at some memory location.  And when the processor boots, it will simply execute the instruction at this location.  On Harmony, this is a bit the same, but the first stage, so the boot ROM is inside the  SoC.  Most of the time, you cannot modify it.  It's burned by the SoC maker.  And what the boot ROM does is simply bootstrap the secondary loader.  So that's why we call it SPL, which can be found in different source.  For example, SD cards.  This is mainly used for the common onboard.  This can be some SPL flash.  It can boot sometimes over USB, sometimes even over a Ethernet, et cetera.  So in the case of Uboots, the SPL is also done by the Uboot community.  It's a program that is specified for each board, each SoC.  And what it does is initialize the DRAM, so the main RAM for the board, talk to the DRAM  controller to set it at the right frequency, and then load the main Uboots image into the  DRAM and execute it.  On FreeBSD, Uboots then loads UBLDR.  UBLDR is a specially-crafted version of loader that is using the Uboot API, which I will  talk about in a minute.  Then UBLDR is loading the DTB.  So DTB is a compiled form of DTS.  So this is a binary blob that is describing the hardware, every peripheral that you have  either on the SoC or on the board.  And then it loads the kernel and executes the kernel.  So the Uboot API is a Cisco-based API.  It was developed at the beginning by Semialf, who is doing a lot of FreeBSD-embedded related  work.  It gives us access to console, so you can have your, you can put some strings on the  serial.  And to some devices, mostly storage and network.  So UBLDR, using this standard Cisco-based API, can enumerate SD card, this device, sometimes  USB work.  You can also enumerate network interfaces.  If you, Bielder, want to PXE boot some stuff, et cetera.  We used to have a lot of local patches in all our different ports from the different  boards in the port street.  So the first thing that I did was take those patches, see if they still make sense, because  most of the Uboots that we used to have were from something like two or three years ago,  maybe.  Clean up, do some more, and upstream everything in Uboots, so in many Uboots.  And what I did also is add a new K config.  So Uboot is using K config, like the Linux kernel, to configure for specific targets.  What we used to do in the port street is had the config API defined in some include file  somewhere, depending on the board.  So it was not really clean to do that.  So I just added a new config API.  So you just gmake menu config, select the config API or whatever, and then you have an  API compiled Uboots, which is needed for UBLDR.  Since a year or two ago, Uboot is porting the device model, so that's what the DM means  here, from the Linux kernel.  This is mainly helping them to port some driver from Linux to Uboots easily.  So Uboot API is not actively maintained, and every Ethernet driver that has been reworked,  so rewrite to use the new device model driver, don't work with ads, which means you cannot  use Ethernet device on UBLDR, but you can use Ethernet device on Uboot directly.  I started to look how hard it would be to port the Uboot API to support the new Ethernet  device model.  It does not seem very hard, but I found another way to do it more easily.  So I won't be touching any more the API for, I think that it's, follow it safe.  It's okay to use it, but we want to go away from it, because I'm the only guy who have  ever written some code in the last three or four years, something like that, and I don't  want to call it anymore.  So the distroboot CMD, as I said before, it's a generic way to finding Linux in the possible  available media on the board.  Uboot uses a shell-like scripted language, so what the distroboot CMD does is scanning  all the available media, so SD card, USB, Ethernet, et cetera.  And if you find a Linux kernel in EtherD, it will simply load it.  And this is the way that most of the Linux distribution are booting Linux with Uboot.  I simply had it config distro3bSD, so it might be a little bit weird to see distro3bSD  at the same time, but this is how the config are named in Uboot.  And what it does is simply search for Ubuilder in the available media, and if it's found,  it will be executed directly.  So we won't have to modify the boot script from Uboot.  What I want is people compiling mainstream Uboots, enabling one or two options to support  3bSD, copy it on the SD card for the Raspberry Pi, Bigelbone, or whatever, and everything  just works.  These parts are almost upstream, I ran into some problems for other stuff on the caches,  flushes, stuff I won't be talking about today.  But I will resume my work soon, and I think this we could have for the releases of September  or Uboot, this part, everything upstream.  So this is what it looks like, so nothing really interesting.  So it's shell-based language, so if we found Ubl.bin, so yeah, we have two loaders on 3bSD.  Currently, we have the bin version and the alt version.  The alt version is compiled for every board because it has a specified load address, while  the bin version is positioned in the opponent executable, which can be compiled for every  board and running on every board.  I don't think we need any more of the alt version of the Ubl.dr.  I need to check every Uboot port to see if they still use them and replace that, then  we can deprecate the alt version of the Ubl.dr.  So EFI, EFI means extended firmware interface, if I'm not mistaken.  I should say UEFI, EFI is mainly for the 1.0 or 1.x releases, while UEFI is for the 2.x  releases.  It started for IS-64, so the Italian platform from Intel.  It's a new way of doing BIOS, basically.  It's a specification.  You have a reference implementation, which most of the hardware makers are using.  So if you have a Lenovo or HP laptop, you're mostly using the Tiena core implementation.  It's open source.  A year ago, when some Uboot developer from SUS wanted to add...  wanted to add EFI support for Uboot, he started looking at Tiena core implementation.  Apparently, he wasn't pleased because the code quality, for what he said, I have never  looked at the Tiena core source code, so I don't know.  So he decided to re-implement everything.  And by re-implementing everything, I mean re-implementing only the stuff that he cared  about.  So Uboot does have some UEFI support, but it doesn't support everything that UEFI specification  states.  And even if it does, sometimes it does not really work.  They took some way around some part of the specification.  But yeah, things are coming along, things are more cleaner right now, but we are still  missing a lot of things in the UEFI implementation of Uboot.  The reason I want to use UEFI even on ARM32, it's because we have one loader to rule them  all then.  It's simpler to use only loader to UEFI, not care about UBLDR anymore, loader to UEFI  is used on ARM64 already, it's used on MD64 of course.  The other reason is that we can easily have video outputs via UEFI graphic output protocol.  We don't have a really good video output support on 3BSD on ARM board.  Uboot have some relatively correct frame buffer support.  And since Uboot support UEFI and most of the board that it supports, supports the graphic  output protocol, for us it would mean that we could directly use UEFI frame buffer from  3BSD to have video outputs.  At least basic one, you couldn't have some dual screen or have some LVDS and HDMI at the  same time, but you could have some basic output screen which would be good.  Also there is some active development compared to the Uboot API as I was saying.  It is mostly done by SUSE which is always good to have a company that is backing the  development of some technology.  Uboot API, as I say, I'm the only one who ever committed code since the last three  years or four years.  Here we have a company backing the code so it's better to use that.  Right now the UEFI status, the console mode are all correct.  This is the first problem I ran into when I wanted to boot the Bigelbong Black with  UEFI.  So serial console mode were not prob correctly.  I think that we're seeing everything is upstream now.  We do have some local patch that I have on upstream.  It's to export the MBR partition.  So on UEFI you can either talk to the disk, to the road disk directly or you can ask the  UEFI implementation, okay, give me the list of partition that this device has.  UEFI is really tied to GPT partitioning.  MBR partitioning should not exist in the UEFI world except for the PMBR, the protective  MBR.  The thing is most of the embedded world and embedded board don't support GPT partitioning.  If you take the Bigelbong Black, for example, the weight boot is the SSE boot ROM.  We'll look at the first bootable fat 12 or 16 or 32 partition in the MBR table and we  load some file from it.  This cannot work with GPT partitioning.  So the patch that I've done and not yet upstream, as this is the reason mostly, is a bit of  a hack because you shouldn't expose MBR partition in a UEFI world.  That we have no choice right now for this kind of board who are relying on MBR partitioning.  We still have issue in our SM BIOS code.  So you boot for some unknown reason, decided to expose some SM BIOS data.  So that expose board information, board serial, board maker, etc.  Our SM BIOS code is made for X86.  So it doesn't care about alignments.  And of course on ARM, you need to have some strict alignments.  So I need to work on the SM BIOS code or maybe totally disable SM BIOS code on the ARM world  because we don't care a lot about SM BIOS information.  We have all the information in some other places.  So the Uboot master port was created five or six months ago by Warner Lush.  As I say, we used to have a lot of different Uboot versions for each board.  And what I was working on, upstreaming everything from our ports to the menu boots.  Warner decided to create a master port that every board will be using.  So we have one place, one unique place where all our patches are sitting before I upstream  them.  For now, it's tracking is GitHub fork.  We have created a repository under the FreeBSD organization GitHub group.  We need to measure switch.  It supports all the main boards that are using the generic kernel on FreeBSD.  So all the old window board, the AM335X, which is the big bone, and some IMX6 board.  We plan to extend it to support also the Raspberry Pi, Uboot or whatever device that  is running FreeBSD should be now using this Uboot master port as all the patches needed  for FreeBSD.  On DTS and DTB, as I said, DTS, Devastree, Sources, our file describing the hardware.  Because on ARM, most of the hardware in the SoC is not enumerable like a PCI bus.  So you have to know that you have some internal code at this address.  And either you out-collect the data inside the kernel or you have a file somewhere describing  the hardware.  We used to have a lot of custom DTS in FreeBSD because at the time, we were not sure that  we could use the one from Linux.  No thing that being resolved.  We can use them.  No problem.  But we still have some patch for some DTS or some total custom one like all the Marvel  board are using some custom DTS file.  I have a little DTS two or three months ago, so now we are sync with Linux 4.10.  I should update them to Linux 4.12, I think it's out.  And in base, we have DTS which is a Devastree compiler, 1.4.3, which supports overlays.  The reason we had patch on the DTS is because at the time, you couldn't have DTB overlay.  Now that DTC supports overlay officially, what we could do is always use the Linux DTS.  And if we want to add some custom nodes or some nodes that aren't present in the Linux  DTS and we don't want to wait the next release of Linux, we can simply add an overlay or  loader, can load the overlay DTB.  So what does simply takes two DTB merge them together and use all the information.  So this is something that we should do.  I've not yet looked at really how can we do it properly, but yeah, this is something  that we should do.  Upstreaming.  When I started to say to people that I wanted to upstream our UBIT patches and our DTS patches,  so either through Linux for the DTS or through UBIT for UBIT, people told me, you know, Linux  don't care about FreeBSD and UBIT don't care about FreeBSD too.  Well, this is not true.  This is definitely not true.  A lot of people in Linux like that we are using the same DTS as them because we don't  have the same problem.  So upstreaming DTS changing, DTS change, sorry, if the change looks okay, looks normal, they  will be accepted.  Even if it's for FreeBSD, I've even upstreamed some change saying the Gitlog that the Linux  driver doesn't use this property, but FreeBSD uses this, so we need to add this and this  was accepted.  So there is a commit in the Linux tree that's saying this is for FreeBSD, which is cool.  And on UBIT, this is the same.  They do care about FreeBSD because they know how Linux works, they know all the problems,  but we have some other problems and they are happy to resolve all the problems that they  could have.  So current for to work, I need to finish EFI and switch FreeBSD 12 current MV6 to using  it and not using UBLD anymore.  As I said, most of it is working.  There is a issue with the SM BIOS code.  I need to test the fit image, so fit the flattened image tree.  It's a new, relatively new image type for UBUT.  Most of the recent, I'm 64 board, the low end one, are using fit image to boot something.  I've managed to boot all other which was crafted inside the fit image.  So we will see how we will do things.  Do we embed the loader on the fit image?  Do we embed the kernel directly?  I don't know.  A few things.  One error for its UBUT master port.  Alexander Graf, who did the EFI in UBUT, he was very responsive for FreeBSD support on  it.  He even said in some of his talk at the embedded Linux conference that we were the first OS  to use the EFI functionality which was developed by Suze.  The thing is OpenBSD did it first, but I'm happy taking the blame for that.  Tom Rini, which is a UBUT master guy, again, is very responsive to the FreeBSD problem  and it helped me a lot to correctly send my patches, et cetera.  And of course, a lot of other people were working on that.  Thank you.  As of who will be all, if you have any questions, we'll be happy to answer them.  Yeah.  It's not so much a question, it's more a bit of background reason why the EFI mutation  was to enable Suze guys to utilize Grub.  Grub, yeah.  Or things like snapper, rollback.  Yeah, yeah.  They want to have a common, it's the same reason that we want to use EFI on FreeBSD.  They want a common point.  So they want to use Grub and the easiest way to use Grub is using the EFI version of Grub.  You should repeat comments for the people.  Oh, yeah, yeah, yeah.  So the common was that the reason that Suze guy did the EFI implementation was to use  Grub because they want to use a snapshot, et cetera, from the ButterFS or whatever.  And they want a common point of entry for the OS.  So EFI is the solution for that.  And this is the same reason that I want to use EFI for FreeBSD on ARM64, et cetera.  Sorry, yeah.  I know I asked you about the, also, you have any critical way of debugging the code you  are writing.  So, for example, we had a lot of problems on bringing up the hard norm on TV2, especially  in caches.  Have you encountered such problems in Uboot?  And how do you find the problem?  Yeah.  So the question was, how many, how do I debug Uboot while doing Uboot development?  Print F.  Mostly.  Mostly print F. I don't have any board with JTAG.  Well, I have, but I don't have, either I have or, and I don't have the adapter or I don't  have JTAG.  I think the simple way will be using JTAG and open a CD, I think it is.  Open a CD.  I've used that for other Cortex, for other ARM chips.  It worked great.  I never used that for Cortex A. I'm sure the support is correct too.  But yeah, for Uboot, I mainly do print F, which cannot suck, but cannot work.  You don't have print F, you turn on an LED.  Yes, that's the other way to go.  Flash LED.  Yeah, exactly.  Another, yeah.  Are you aware of the level of support of NetBSD and OpenBSD in Uboot right now?  How much work do we need to do here at some level?  So the question was, do I have any info on the level of support of NetBSD and OpenBSD  for Uboot?  So OpenBSD guys stepped right after the first Uboot patch where in the Uboot tree, they  step in and say, okay, we want to use UFI.  I think that they didn't have a UFI loader for MD64 and that their first UFI loader is  for ARM.  So right now, they're using EFI, apparently everything works for them.  They just, I've looked at the code, they just bootstrap the kernel, look at the FFS partition  or whatever.  So they're not using the partition explored by UFI, they're using Rode disk so they don't  have the problems that I ran into.  And for NetBSD, I think every board using Uimage, which is Uboot image, and you, I don't  know for Tegra because for Tegra, you have DTS.  For all the other boards, you don't have DTS and everything is added in the kernel.  So you just take the kernel, make a Uboot image and give that to Uboot on a FAT partition  or something that Uboot can read, so either FAT or X2 or whatever.  For Tegra, I don't know how do you do that.  You don't know either, I swear.  Any more questions?  Yeah.  So I take the, you said that people are happy with trying to keep aligned on DTS and these  partners are happy, they're happy, because ASEAN is, they're up close to  a global arena, so when people thought about these, they did break sup because of all  about DTS discussion.  I don't know, I wasn't there at the time  on the FreeBSD project.  But when I started doing FreeBSD work  one or two years ago on all window boards,  we were still using some custom DTS,  and the first thing that the FreeBSD developer told me  is the first thing that you should do  is using the upstream one.  We don't want to use a custom one anymore.  So I don't know how it went.  But right now I think everyone agrees  that we should use a common DTS across OSs.  I think one of the arm maintenance  for DTSD to be will be a FSD cap.  Okay. Is this Mark Rutland?  Yeah, okay. Yeah.  Good.  Yeah.  So the reason we're not...  we don't use the Uboot image format  for loading the panels  and we just set it all out in the order?  So the question was,  is there any reason that we are not using  the Uboot image format  for the loader or the kernel?  The main reason is that the Uboot image  you have to specify the loading address  and execute address, etc.  So we have to build a Uboot image  for every board that we support,  which is kind of annoying  because right now we have the generic army image kernel  as of six months ago.  We have some UBLDR,  which is positioned in the opponent executable.  So we are running all this problem  of specifying the loading and executing address.  But this is the same for fit image.  You need to specify the address.  So this is a new format, a new image format.  I don't know why at the time  where the Uboot API was made,  why it was made.  So, yeah, I don't know why at the time  this was made, it would have been much easier for us  if we took the netBSD direction, for example.  So, yeah, I don't know.  But EFI for me is...  solve all of our problems.  Is EFI interface normal to other architectures?  Yeah, so the question was,  is the EFI interface portable on other architecture?  And if I remember correctly,  it works on ARM, ARM64, X86.  I think that's the only platform  that has at least some development on it.  I don't think it would be too much trouble  to put it to PowerPC.  Try it.  And tell me after if it works.  But, yeah, it should work.  Okay, thank you.
Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_0_131.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_132_539.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_540_1439.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_1440_1607.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_1608_1859.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_1860_3047.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_3048_3203.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_3204_3479.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_3480_8963.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_8964_9179.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_9180_14639.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_14640_17639.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_17640_19079.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_19080_20591.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_20592_20639.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_20640_22247.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_22248_23207.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_23208_25763.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_25764_28919.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_28920_31019.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_31020_34631.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_34632_35759.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_35760_35807.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_35808_37127.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_37128_38603.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_38604_46247.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_46248_47231.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_47232_47363.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_47364_50975.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_50976_51035.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_51036_52331.png Emmanuel_Vadot__FreeBSD_ARM___Before_Kernel_-_BSDCan_2017_n-ewQ_WZAP4_52332_53114.png