 So here we have our little rumor-monger talks who's going to help us out with some rumors that we're going to explore later, but first we're going to start off with the basics, basic facts. Uboot was born in the year 2000, had a couple of parents called FADROM and 8XXROM. Those are both bootloaders for PowerPC. It was an old type of PowerPC by Motorola and it was for embedded stuff, not for Macintoshes. There were some, these PowerQuick chips and 1XX was one of the things that ran really well on them back then because it was so dedicated to PowerPCs and its initial introduction. It used to be called PPCboot, but nowadays it's called DOS Uboot for its full formal name. It's almost nobody uses, but that is what it's called. So let's take a look at what Uboot actually does. And I'm going to compare it to the PC scenario since if you're not yet familiar with Uboot that's probably something that you're at least familiar with. So let's look at the PC boot. To start with the hardware, you have your main storage, normally a hard drive, but inside the PC you've got this flash thing that your BIOS or your EFI lives on and of course you have your main memory, your RAM. So when you start the boot, you have this BIOS in old days, UEFI in modern days that is the first thing that runs when you hit your power. The next thing that runs is the grub. Say, that's pretty common for your Linux-based PC although there are a few other alternatives that you could be using. Let's go for the normal choice. The BIOS or UEFI loops up the grub off of your hard drive and pops it into the RAM where it starts running. And the next step is that your boot loader goes back to the main storage and loops up the kernel and starts running that out of RAM. So we've got something analogous happening on our embedded board, but not quite exactly the same. To begin with, the main storage can be a hard drive, but it rarely is. It's more normal to have even the single chip type, the raw type storages in old days, say back in the PPC boot days. We had the luxury of NOR chips, which are very reliable. Nowadays, you might have a NAND, you might have an SD card, or it might be on an EMMC, which is kind of like an SD card that's been soldered to your board. And in place of a whole chip to run your BIOS, you have the seedlead SOC system on chip reviews that have ROM inside the chip from the manufacturer. And that's going to be the early boot. Plus, they normally have some SRAM, static RAM, also inside the CPU. Those static RAM is pretty expensive, so this is just a teeny little blob of static RAM to get yourself bootstrapped and running. And then you normally, for an embedded system that's big enough to run Linux, you normally have the separate DDR memory for your RAM. So the first thing that happens when you hit the power on your embedded board is it goes into this boot ROM, which is inside the CPU. Because this is so tightly coupled to the CPU, it's like the old PC BIOS where every vendor does their own thing with the little boot ROM. So the specifics of how these work is you're going to have to get familiar with the data sheets for your part. There are some things that are in common, but details are always, you've got to go with your vendor specifics. So somehow the boot ROM goes out to your main storage and it goes out and loads this SPL, which stands for secondary program loader, because the boot ROM is considered to be the first. So SPL, once upon a time, used to be a separate project, a separate software project. The goal here is to be really, really tiny, so tiny that you fit into whatever the CPU designers deign to give you for that internal SRAM memory. So we're talking like just a few kilobytes. In modern times, Uboot has actually learned how to pack itself in to tight spaces, shall we say, and Uboot can actually build through a special SPL build that goes tiny, tiny and fits inside the CPU. So the whole purpose in life of this SPL is to then go out and drag your Uboot in from wherever it's living to give yourself a proper full service boot loader. You get that loaded into the main memory and jump in and let it do its thing. So the embedded boot actually tends to be a little more complicated than the old PC. You get, you have to know your hardware a little more if you're, you know, doing a board support package. So then the Uboot is the thing that equivalent, it's really equivalent to the grub job where it goes and pulls the kernel out of your storage and pops it in a RAM and runs it. But it turns out that Uboot actually does a lot more. It is a little more diverse than its talents in grub or whatever your PC, your favorite boot loader is. So let's take a look at some of these things that Uboot knows how to do. So of course, to qualify as being a boot loader has to know how to load and boot images, that's pretty much a given. But it also is a lot more skilled in initializing and exercising hardware than your typical, you know, desktop or server bios because people tend to use Uboot more than just the end user final boot loader. But from the time that your custom board is born, you know, just the very first versions back from the factory, a lot of times people are using Uboot to exercise whatever the hardware guys change from the reference design and make sure it actually works. So instead of the classical menu system that you have in a bios, you have just the command line interface to Uboot. But the good news is that you have a lot of flexibility in managing environment variables so that you can have a stateful system and save all kinds of settings, any kinds of settings that you need to know in order to boot your system. And the final one that makes it really fun is that Uboot can actually run script. But when you're sitting at the command line, it has a command line parser which if you want to configure it actually can do command line history, you know, like a shell, it has conditionals and, you know, if, this, then that. It's actually pretty good. So suppose you had a, you know, it gives you a lot more flexibility and say just the bios menus where a lot of times the vendor may not have given you the commands that you really wanted to be able to do. Like say you have just some desktop system and you wanted to remember to always power on after the power goes off, right? That's a server thing. Well, if you've got a desktop bios, you might not have bothered to put that in. But Uboot pretty much, you've got it just a ton of flexibility between the generic environment mechanism and running scripts based on your environment settings. As you can actually have a collaborative thing going where when Linux is running, it decides that the next boot is going to be a special one. Say you're going to do an upgrade. And so you just set a variable and the script that you gave is the Uboot lets it know that you want to do something special that only happens on upgrades. So it's pretty cool. So now we'll get in, absolutely done the basics. We'll get into some of these rumors that were in the abstract. I've got my little helper, the tux, who's into rumors, managed to dig up these leads. We're going to investigate to see how many of them are actually true. First one, he claims, he heard claims that Uboot is a network strike breaker for a small fee. He heard that Uboot likes to go around flashing bare hands without a permit. He heard that Uboot has been known to reprogram uncooperative boards for Jenkins. And the last zany one that he didn't actually manage to fit into the abstract is that Uboot was heard to perform all chemical transformations. So, started from the top. So let's talk about the normal case first. Under normal circumstances, Uboot likes to team up with Ethernet to get pixie-like booting going. So for those who don't know what pixie-like booting is, in some of those biases for servers and so forth, you had a PXE mechanism for doing net booting. So you could have a whole cluster of diskless things that would know how to boot off their Ethernets and then, say, either run out of a RAM disk or do an NFS mount. So you can do something similar with Uboot. You need some prep work, unlike the real PXE. In the real PXE, you have a special flavor of a DHCP server that not only tells the client what their IP addresses is, but it also tells them where to go to find their boot images on the network, tells them the server IP and stuff. So with this mere pixie-like booting, you have to go into the ENV and set up a server IP ahead of time and give it the boot art so that it's going to know to net boot. Then you use a couple of commands, you use DHCP to get at its own IP address and you use TFTP boots to grab the actual bootable image off the network. Okay, so that's great. They're usually on good terms, Ethernet and Uboot. So what happens when the Ethernet devices go on strike? Say you have to pick a completely random example that may never have happened, well, yes it did. Okay, flaky early board spins, you find out that first version that comes back from the factory that you cannot get to a Ethernet and you're trying to do your rapid iteration with your development, where you keep on building new kernels and booting NFS, that won't cut it if your Ethernet fly got glitched in the first version. So there's another case at the opposite end of the spectrum. Sometimes these penny pinching hardware people end up taking off the Ethernet. So the final production hardware does not have an Ethernet. I may have seen this as well. So what happens when the local network is on strike? Uboot just teams up with the serial instead. You use the commands load X, load Y, load B and it's really old school because those things are X modem, Y modem and Kermit. Like back in the modem days, you can use programs like Minicom is my favorite, other people use other terminal emulators that still remember how to do these ancient protocols. Okay, so on the other hand, there are no fees involved, Uboot does work for free. We're going to call this one a partial truth. It does not go with the net, it does not cooperate with network strikes, but it doesn't charge a fee. Okay, next rumor. Suppose the theory is that Uboot goes around flashing bare nans without a permit. So for those of you who have never attempted to do it yet, Raw and Nance Nanships can be a major pain to program. Pain, you have to cope with bad block tracking. You know those lovely SSDs that make your desktop and servers so fast nowadays? They have all kinds of firmware inside them to do the bad block tracking for those stupid little Nanships inside them that are very, very flaky. And that it's not a question of if there will be bad blocks, it's just where will you have bad blocks? Like, you know, if you have monitors and they won't take it back if you have like, you know, a hundred bad pixels, oh, it's only a hundred NANDs, the NAND manufacturers, they guarantee you that the very first one is good and beyond that, who knows? Yeah, yeah. So not only do you have to keep track of bad blocks as if you, without having the benefit of your fancy-dancy SSD from where to do it, you also have to cope with the ECC algorithms and the layout of the ECC bytes. So probably you've heard about the ECCs in reference to CDs and DVDs, perhaps. You know, they have the error corrections built in so that every little, every little scratch on your CD or DVD won't ruin the whole thing. It's a way of, it's a mathematical method for making use of redundancy so that, okay, I know this, I know that there's an error here and not only that, there's enough redundancy that I can actually figure out what this was supposed to be, even though we lost some bits. In the case of NAND, it's bits that like to get flipped. And again, NAND is so bad that it's not going to be, it's not unlikely that you have more than one bit flipped nowadays. In the earliest NANDs, they used something called a Hamming code and that was able to detect and correct one bit per block. Now you have to cope with some NANDs are rated for up to eight bit flips per block. So back in the old days, when you had NORs, you could, once you learned what the programming protocol was for a particular vendor, you could pretty much just say, okay, here's the image. I'm going to throw on these exact bits and I'll verify them in the end and if the bits match, we're good to go. And so you have these little devices called flash programmers, right? So nowadays, with NAND, you need to know exactly which ECC algorithm is the software is going to use because if you put in the redundancy using a different algorithm, the software is going to think all the blocks are bad, not going to be able to read anything. So you have to have exact agreement in calculating these, you know, fancy, dancy checksum and then you have to put them in exactly the right place because you have this OOB part out of band area in your NAND and the layout, you know, say you use bits by 0 through 52 and the programmer put them and, you know, shoved them at the end of the block instead, you're also going to think all the bad blocks. Okay, so that shows you why if you're getting small quantities of boards from a board house in early runs, you're not likely to hear them volunteer. Oh, yes, let me program your NANDs for you. No, they're likely to come out bare blank. Oh, yeah, it was sometimes it's even worse than just knowing which ECC, sometimes it's knowing which two ECCs because the boot ROM insists on using one ECC and your kernel insists on using another. That's really a pill. Did I say it was a pain? Unfortunately, yes, you actually run into this problem with too many blank NANDs. So it turns out that U-boot does help you out in this situation. There's actually two different general approaches. One is that U-boot teams up with your boot ROM as a partner. You set your CPU boot jumpers for whatever your boot ROM knows how to do and you have actual hardware wired up to talk to it. Like for instance, if you've got a board that has an SD card, a lot of the embedded CPUs know how to load a block off the SD, or you might have one that knows how to shove things in over your port using X modem, say, more of that old school stuff. You might have USB, you might have an ethernet boot actually programmed into your tiny little boot ROM. You have to read the docs to know. Sometimes setting the boot jumpers is not as trivial as you might wish, say your hardware guy didn't think to put the jumpers on for the mode that's actually practical might need your soldering iron. So once you have it all set up, you've got the plan going. The boot ROM then loads your tiny little SPL, SPL loads U-boot just like we had in the earlier diagram. Then the U-boot is smart enough, once it loads the image to RAM, it will know how to write to NAND in the proper manner. In fact, U-boot knows how to generally, if you've got a platform where they annoyingly make use of more than one ECC, it'll have a command that lets you switch back and forth. You say, okay, I have just loaded my bootloader image, which is basically another copy of U-boot itself. Now I'm going to burn it with the special bootloader ECC, and now I'm going to load the kernel, and now I'm going to switch over to programming the NAND with the other ECC. So U-boot can also team up with the JTAG programmer, assuming you've got a nice little JTAG port on your board, which hopefully somebody thought of if this is an early provision of the board, usually the hardware guys are going to want to use the JTAG too, so they do remember that. So the JTAG then is able to set up the SPL and stuff it into SRAM, it will, you can put a break point so that after the SPL is done, it's usual dirty work of setting up your main RAM so that it actually can remember things. Then you can hold it and let the JTAG go again. This time you load the U-boot into your woken up RAM, and you run it, and then everything works like before. So if you've got a JTAG port available and you have one of those JTAG programmers, this is actually a pretty convenient method during early development, because the one thing, the JTAG programmers usually run faster than, say, UART, and you don't have to worry about some wacky custom protocol like you do with the USB sometimes. So we're going to say this is true. It does flash bare hands without a permit. There is no permit, but if there was one, you might actually get it. So moving right along to our next rumor, we heard that it reprograms uncooperative boards for a guy called Jenkins. You've probably heard of him in other contexts because Jenkins is one of those popular continuous integration or CI frameworks that people use a lot on servers, including just all software projects not necessarily embedded. When it comes to doing embedded projects though, Jenkins sometimes sells for native server tests. Say you've got an application that's pretty generic and just happens to be running on an embedded board, why not just test it on the server? Sometimes Jenkins sells for QEMU tests. For instance, the open embedded, you might have builds where it's pretty convenient to go ahead and run stuff in the QEMU platform. And that would allow you to test that not only does the application work as designed, does it work on the actual arm like it's architecture without having some stupid compiler bugs getting in your way, but sometimes there's just no way to get around needing to run on the real hardware because QEMU stimulates common arm architecture stuff. It doesn't stimulate your custom, say you've got hardware inside of the SOC that does take a random case, video encoding or video decoding accelerators. QEMU knows nothing about that. You can't test your applications that are making use of those accelerators. So when it comes to that and you want your automated test without somebody sitting there and programming the latest, greatest version into your board, UBoot is willing to step up to the plate and help out. This is kind of the overall strategy. Jenkins will, when it's running one of these hardware specific tests, will leave a UBoot command script over in a TFGP area because UBoot knows how to do TFGP. Then Jenkins will reboot your board using whatever mechanism you get it like you might have a software controlled power switch for the brute force mechanism or you might have SSH logins where Jenkins is able to reboot the thing. And then UBoot comes up and UBoot has been told ahead of time that it's supposed to go TFGP that script to Jenkins made it and just do what it says. So this one is also true, mostly because uncooperative board usually have the option to opt out. If you've got a really uncooperative board, you usually need to bring back that soldering iron to talk some sense into it. Okay, here we go. This is the zaniest one of all. Does UBoot perform all chemical transformations? Are we talking like lead to gold? No, more like brick to board. So this one has actually a number of variants. This is a nice, meaty rumor we've got here. The thing they all have in common is that the brick starts out with a serial console because UBoot commands are run over the serial console. The first one is that you have a brick with a USB port in it and then you plug in your USB stick and manage to get your brick back into a board. Or it could be you have a brick with an ethernet port in it and you plug it into your development laptop and you manage to turn it back into a board or maybe you have a brick with a JTAG pins on it and you plug in your JTAG programmer and turn it back into a board. There's a hint for you. Real bricks don't have serial consoles. So that's the trick. It is not really an alchemical transformation. It really was a board all along but UBoot can help you get the board to stop acting like a brick because it is really versatile and it'll work with pretty much whatever peripherals you've got. If you want a net boot that's great. If you want to shove things in via JTAG and then reflash your board that's great. We already talked about that. If you want to boot from an SD, you want to boot from a SATA, you basically however you want to get your recovery images in UBoot can pretty much handle it but sadly it wasn't this since it wasn't really a brick. So I'm going to do some final conclusions and then I'm going to do some Q&A time and other people who like to work with UBoot are free to share their own war stories and the cool UBoot tricks. So first of all, I argue that many books could be written about the exciting life of DOS UBoot. This barely scratched the surface of what UBoot is capable of but unfortunately they probably won't get written. Too few of us embedded DOS really are inclined to write much so go to one more info. On UBoot might have to sell for some presentations. If you go to either of these lists you will find a few different presentations from the ELC Europe and it's both slides and videos on YouTube or you might try the UBoot Read Me which is really, really long, probably one of the longest reading you've ever seen and worthy of some light bedtime reading. I mean it's probably 70 pages printed out. We're going to roll the credits now. Thanks to Dan Malik for the fads wrong back in the day and Magnus Dan for 8XX wrong. Wolfgang Dank was the one who did PPC boot which then got renamed to DOS UBoot because it no longer specialized. Tom Rennie is the current lead maintainer and they have many friends helping them. Give credit to John Miller who is the guy who built the Motorola board that ran PPC boot back in the day and he was the one who recruited me to help get it on there. So that's how come I'm familiar with UBoot even now. And credit goes to Tom King for starting a scale embedded track starting last year actually. He's happy with that. And my beloved other half gets credit for helping me come up with a topic when the deadline was looming and Inkscape deserves credit for this whole presentation with all the PPC animations and stuff. It makes writing a presentation fun. And open clip art has graciously provided the traditional Yamas no wait. The credit Yamas yes and the smelly cheats and the trainers of the Yamas used to get them to stroll in the right direction. And the brightly colored balloons and a space shuttle. And finally the horde of friendly penguins that want questions on UBoot will try to answer any questions you've got. I have a really hard question. I have a really hard question. I know there are a million versions of UBoot on the Internet right now. And I recently did some stuff using an arm chip with a signed boot. And that's a fine one. Yeah it is. That's an all winter chip because you can find the code on the Internet if you look. All winter is not known for being great at mainstreaming. Whereas if it's Qualcomm or TI you have to sign NDAs and you go to prison if you talk to anybody. What advice can you give? Which UBoot is the boot to build to? Like when I do the next project? Do I use Denkz's version of it? Do I use one of the GitHub versions? What do you think? I would go to the UBoot site and actually probably use one of their architecture specific trees. The Tom is the one who maintains like the equivalent of the Linus tree that has all the architecture merged together but he has the equivalent of lieutenants that are looking after different architectures different to you know like there's a TI tree if I were going to do TI and there's quite a few of them I forget if there was an all winter one. You might go with the main. Well I have the all winter one. Yeah but is it from UBoot or from the vendor? It's from the vendor that ended up on the Internet so I can say that I have it. This is a step better than that in that there actually the changes coming from these trees that are listed as basically lieutenants I forget what they term them but these trees are like the equivalent of the ones that officially feed into the mainstream one and they. Is there a sub tree, an official sub tree that deals with the signed boot? No there isn't unfortunately. There is? Okay so that's in all the ones from the Denkz. Right. But like the Chrome people, Chromebook people did. Yes. I would go look at what the Chromebook people did and if I were going to do one of the fully signed trustee. No there's the Chrome for the Intel and the Chrome for the ARM and there was a vintage of Chromebooks that did what he's talking about I'm pretty sure. The next version is not going to use U-boots in this process but there was an error when they were using U-boots for the ARM Chromebooks to do the trustee signed stuff. Yes. Doing it from U-boots, oh you mean instead of doing an upgrade from the Linux? Because we're using a normal version of you know that the end user version of the software which may not be optimized for programming updates. So what the U-boot does is it will then, I could have gone in a little more detail so I'll do that now. So the U-boot can tell you to load a special programmer version where you have everything you need in the in-NAT-RAM-SS and that is where your MTD utils gets installed. It's not necessarily installed in the normal. I'm just programmed to do the, to run this application kind of a build. Right. You, yes you booted into the special programmer. Yes. I'm not going to say a hundred percent because there's hardly ever anything that's a hundred percent but I'm going to say I have never, I can only remember red boot being used once upon a time and I can't remember the last time I've seen that in a board support. So board support packages pretty much come with U-boot and a kernel as a minimum. Nowadays they're actually usually an open embedded layer and those that's open embedded layers if you're not using, okay, I thought of one. Minnowboard doesn't by default do U-boot. They do the EFI stuff instead but if you're not doing the EFI then you're probably doing U-boot. People who are just doing their own thing are always free to run their own coolest favorite. So I don't think there's any reason why U-boot would literally make those things go extinct but I think U-boot is going to be the standard for anybody, you know, well like the Android kernel. I wish it weren't the case but if you've got a new chip nowadays it's probably going to be running an Android kernel this year in something that could possibly be used for CE purposes. Now I mean you can't run other obscure kernels on the same hardware. But that's why I mentioned the SPL knows how to do teensy, teensy build so if you can actually build it as a secondary program loader you can build U-boot really cut down so it's all configurable and in fact in the new mainstream, the new mainline U-boot they've gone with the kernel, they've recently done a switch over to the kernel configuration style where you have the menu config and all I want to turn this one on, this one off, this one on, off, off, off, off. In the old days you know that you and I worked with mostly it was go in and edit the header file right and then you had to get familiar with that the like bedtime reading of a read me to know what things to put in your header so I think they're trying to make it more convenient to be able to turn things off so that you only have the things that your project specifically wants. Yes, one of those talks in the Europe ELC that are online, the one by Simon Glass covers the device tree stuff way better than I could because he's the one that has been leading the effort there. He was the one who, so if you're interested in device tree I highly recommend watching his video and they have made great progress with it last, just in last year a lot of things are going with the device tree and that will in the future make new ports easier, new U-boot ports. Anyone else? Yes, it would be a, you would use a different to, you wouldn't use the same U-boot that the software engineers use during development, I think they call it Falcon or something but there's a, essentially what they did is they made it to where the secondary program motor mode where you compile it down with just a tiny minimum of stuff that it was smart enough to be able to load your kernel directly without going through. So you compile in just what you need into the tiny one and it doesn't know how to do any of this net boot nonsense, it doesn't know how to do memory tests, blah, blah, blah, it just knows, I know how to get the kernel from, say, SD or whatever you've got and pop it in there and run it. So, I think that might actually have been Wolfgang who did that project but anyways, you can look for U-boot Falcon, I'm pretty sure that was the name. We done? Thanks for coming, I guess it's time to hit the exhibition hall.