 Yes? I am sorry for the late start. A little bit of laptop trouble but I'm on الن belongs to books now. So maybe I should have done that from the start. So my name is Simon Glass. I'm here to talk a little bit abreviatedly David walls new Noble on what's new in New lyrics. So, here's my goals of this talk. I will say that I'm, I don't know everything about U-boot. It's a huge project, but I, so I'm going to talk a little bit more about things I know about than things that I don't, and it's only natural, right? And I also, I also know that some people use quite old versions of U-boot. How many of you are using a U-boot that's five years old? Yeah, what about two years old or more? Yeah, so it's not very common to update your U-boot. So some of these things, I will mention some things that have happened perhaps older than two years ago. So just an overview of U-boot. It's been around quite a while. Since 2012, Tom Renie has been the head custodian, and there are about 50 other custodians for different areas of the project. It's about 2.2 million lines of code, but a lot of that is board specific, you know, drivers and things like that. The amount of code you actually compile into your particular board is considerably less. It's a release cycle that was two months, and now it's three months. There's a lot of contributors, a lot of things going on in the project, and it has quite a strong links to Linux. It uses Linux code style, obviously, and some Linux drivers and so on. I'm not going to talk about these things, and probably these things have been true five or even ten years ago, certainly five years ago. So U-boot has very wide architecture and board support. It has a mechanism for loading U-boot, which is, you know, several hundred k, when you've only got a very small amount of SRAM and you need to get your SDRAM going. It's called TPL and SPL. It's got pretty wide image support. There's also a sandbox architecture, so you can run U-boot on top of Linux just for testing and for development, and so certainly in my case any feature development is done in sandbox because you can use normal host debugging tools and all that sort of thing, and then it just works as expected on the actual board. U-boot has a command line, so when you run it, you just get a command line. I won't be able to run it on this Chromebook, but take my word for it, you can run all the different commands and things like, you know, looking at files in the files system, looking at memory, changing memory, that kind of thing. So here are some things that you may not have known about if you're using the U-boot from four or five years ago. So U-boot has a driver model now, which is designed to take care of all the different drivers and devices you might have in your system. It uses k-build and k-config. There's several, actually, at least three verified or secure boot mechanisms. It supports firmware update and fastboot, that sort of thing, and it's attached to the co-verity system, so we actually get security emails telling us to go and fix our code, that kind of thing. So just to look at a couple of these things. First of all, driver model. How many of you have used driver model or seen driver model? Okay, some of you. All right. So it's fair to say that it came out in 2004, and I think it's, sorry, 2014, and I think it's settled down a bit now. We have it sort of embedded in most areas of U-boot. The goal is to allow you to specify the devices in your system using device tree as we do on Linux. And by doing that, we can then effectively use those devices within U-boot without having to run a whole lot of code to set them up. So here's an example. On the right, you can see there's an I2C bus. It has a PMIC in it. That PMIC has a LDO, and we want that LDO to be set to 2.8 volts and some other things as well. And so at the bottom left, you can see that we're automatically setting all the regulators where we know the voltage. You can imagine behind the scenes what's happening. It's going and finding that PMIC. U-boot has lazy initialisation, so it will only do it when it needs to. It will go onto that I2C bus. It will send some register commands to that PMIC to set the voltages, and it will do that for the three different regulators that we've mentioned there. So that's something that driver model can do, whereas previously, perhaps you would have had to code all this up with register accesses directly in your board code. I'll just mention this. I don't think it's widely used, but it's a mechanism for measuring boot time through the different stages of U-boot, through different phases, and getting that sort of microsecond count to find out where your boot time is going. And there's even a tracing mechanism that you see function tracing. It's a little bit atrophied now, but it will record tracing information. You can actually write it. Here we're writing it using a network, and then analysing it on the host. So I want to mention Buildman. A couple of years ago, there was a script called Make All, which was designed to make all the boards, and that would tell you whether things were good or not. And that got retired in favour of this thing called Buildman. At the bottom right, you can see I'm doing a build, a very ambitious build here. I'm building a tree with 145 commits for all of the boards. It's about 1,300 boards in U-boot. And it's busy there working away, and it's going to be done in about 24 hours. I didn't continue that. I didn't let that finish. But Buildman essentially lets you build any number of commits. It lets you build for any number of boards. You can select architecture and that kind of things. And it handles the tool chain for you. It downloads the tool chains if you ask it to. And it's pretty easy to use. And on the top, we've got the analysis phase. So when you say minus S to Buildman, it looks at existing build that you've actually completed. And here it's telling us where our code size is changing or our data size. It's a little bit... There's a lot of changes going on here because this is a series which introduces... Refactors and introduces SD RAM support for a particular SOC. And yeah, there's a lot of commits. But basically if you look at this, here you can see the text size has gone up by about 60 bytes, which isn't too bad. And some of these functions have gone up in size. Red means they've got bigger. Green means they've got smaller. So it's pretty easy to see where you've made things better or worse in terms of code size. Buildman also supports config changes and environment changes. So now I'm going to talk about some of these new things. I'm just picking a selection of things that I'm going to mention. Hopefully, if you've not looked at Uber in the last couple of years, you won't quite know what these are and you'll learn something. If not, please tell me what you wanted to know afterwards. So the first thing is device tree overlays. These are not... Not needed on every board, but here's an example of a base board where we can connect a number of additional add-on boards to it. And the device tree basically is used to describe what devices are on that board and when you add a different adapter board on top, obviously you're changing the devices that are available. And the mechanism used in the kernel to support this is device tree overlays. So here on the right, you can sort of see I'm loading in a couple of device trees. I'm then applying the overlay and now I can see that my display has appeared, whereas previously it wasn't there. So that's a very, very simple example of an overlay being applied in new boot. And so when we have an add-on board, we can access its peripherals. If you do this early enough in new boot, then new boot can use those peripherals too. New boot can use that same device tree. So obviously that's supported in new boot and SPL workers in progress. It's also possible to do this within Linux, but the nice thing about having it early and having it ready to go is everything is consistent. So new boot's had device tree for quite a while, but it was a little bit clunky. There's a new interface called a live tree interface. The code for that was largely copied out of Linux. Essentially there's a new API called dev read, and you use that now to say, you know, read a device tree property from the device tree. So we've got several examples here. The simplest one is on the bottom left here where we're reading boolean values from the device tree. That's just going to read it from the node associated with that device. And we've got other things here like reading the address of the peripheral and reading resources and so on. So it's a fairly consistent interface. You don't have to worry about device tree pointers or anything like that. You've not got config.of live enabled. It will still work. The dev read interface still works. It's transparent. It'll work no matter whether it's a live tree or a flat tree. So in new boot now we're trying to use this interface in preference to anything else. So this is a little bit of a crazy thing. It's not really widely used in new boot, but there are about, I think, five or ten boards that use it. The device tree does add overhead. Typically the code size increase on ARM is 3K, 3 or 4K. And the device tree itself, obviously the device trees are typically 40 or 60K or even 100K in size. What we do in new boot is we actually grep down the device tree and remove the things that aren't used in SPL. So SPL is a very small memory constrained thing. You get the device tree down to about 3K in SPL. So the overhead typically is 6 to 7K, which is not too bad. But if you've only got 32K of RAM, it's VES RAM, it's too much. So this is a scheme for converting the device tree into C automatically. You can see what it's doing here. On the top right you've got a device tree node for a memory controller. And here's what it produces. This declaration and the header file here. And then it produces the actual contents of the device tree here and then declares a U-boot device. So hopefully that makes some sort of sense. You can see what's going on. The point is when you run SPL now you don't need the device tree. It's just not necessary at all. You've got all the data you need and available in C. And if you're interested, the code that's actually used to access it is a set series of assignments to assign from this web structure that DTC creates into your correct one, the normal one that you would use with device tree. And if that's enabled, you do this special code to copy things over. And that's much smaller code than having LibFDT in there. A couple of other things to mention. There's Android bootloader support, LibAVB is in U-boot now. And there's a... There's also an opti driver, although no command. So there's an example of a boot flow there, very simple. You run through this verify command. If it verifies, then all is good. Otherwise, you've got a problem. It's just... I think it's the third or fourth verify boot mechanism in U-boot now. U-boot, sometime this year moved to GitLab. And I quite like it. It does similar things to Travis. It's a little more integrated. Essentially, when you push a commit up to GitLab, it goes ahead and builds it for you and tells you whether there's any problems and you can see the actual errors and so on. So that's fairly new. We're still using Travis CI, but we'll see how it goes. If you've got a build server sitting around, not doing anything and want to hook it up to provide capacity, please don't let me stop you. Which leads me on to this, which I think is really cool. U-boot's firmware's not the best place for testing. Quite often, when people write firmware, they just write the code and they manually test it, and they don't change it ever and that sort of thing. Or maybe there's a lot of manual testing or functional testing of the actual device and that sort of thing. U-boot, in the last several years, has been an effort to increase the amount of automated testing that's available. So there is a thing called Pi test. It's basically a number of unit tests and functional tests that are built into U-boot. Things like, for example, do the file systems work? Can I write and read files with the file system support? Can't do all of the different driver model U-classes actually work. For example, there's a test that basically uses a simulated USB stick. It goes and tries to read a couple of blocks off that simulated USB stick. Obviously that requires going right through the whole USB stack and therefore we get some feeling that that kind of works. When you run, it's actually make Q-check, or make check, it will run all these tests. It takes about a minute or so including all these things. And they use sandbox when you run them on your machine. The test can also run on QMU or they can run on real hardware with appropriate hooks. And there's a thing called T-bot. Is anyone using T-bot? Anyone familiar with that? Yeah, okay. So I don't, I guess it's not widely used, because of all this, you test U-boot Linux and beyond on real hardware and it collects the information, the failures and that sort of thing. So I think what's going to happen over the next few years is more and more of this stuff is going to become possible. Traditionally, or more recently there has been this use of these Wi-Fi flash sticks. They're used for cameras, but you can basically send U-boot and then reboot the device with some sort of power control module and that allows you to test that it's working. But there is this thing which I recently discovered and maybe I'm just slow which is called SD wire which plugs into your board and then connects to your development machine via USB. So now you can control, you can write to the SD card over USB, some sort of new U-boot Linux, whatever and then use power control to reboot it. And now you can obviously access the console and see what's happening there. So connecting that to GitLab I think will happen, hopefully as well, more and more people will have these things running automated tests on actual real hardware. So U-boot supports EFI, the EFI interface effectively. You can boot, for example, you can boot Linux, but you can boot Grub 2 and use that. And this came from Sushi and I think it's been fairly widely publicised, there's been a few talks about it. Essentially with this you can run an EFI application, U-boot provides console support, serial support, network disk and that kind of thing. So you don't actually need U-EFI as such if your platform supports U-boot. And there's pretty good tests associated with that as well. There's a recent change to use restructured text for documentation and also the documentation this is a large amount of documentation in U-boot. It's all sort of traditionally been in this big doc directory and you kind of grip for it really because otherwise you couldn't figure out where it is. So now it's kind of moving to being inside a directory which mirrors the architecture and the board directories. So for example you'll put your board or documentation in doc board and then the name of your board, that kind of thing. So I think there's a minor change but it should help people find things a bit more easily. And I'm just going to mention some things, some other random things. These are things that I've worked on and that I wanted to have to put up with me talking about basically. I won't take too long. The first thing is Binman. Binman is a firmware packer. It's not widely used. It's used by SunXI, Integra and a few other things in X86. It's written in Python. Basically the way you use it is you put a device tree description of your image in there somewhere and when you run Binman it will automatically produce an image. Here you can see it's taking SPL, it's taking the image, it's a bit weird but this is, have you heard of Coreboot? It's another bootloader. The state is making a Coreboot file system with these three files in it, with some compression and so on. So that's what Binman does. It's basically a one pass firmware packer based on a configuration description. So it's not run lots of commands to build up your image. You just describe it in one place and it very quickly puts it together. It's very handy for complex images to assign a particular piece of the image and put that data somewhere else and all that kind of thing. So the status of this is it's kind of, I wouldn't call it feature complete but it's been in use for a while and recently it's had a bit more effort and we'll work on it and we'll see how it goes. So those of you know me a little bit over the years, traditionally I've not had a huge amount of interest in X86 stuff. However, for various reasons, I was briefly the X86 maintainer for Uboot. We now have a much better maintainer, luckily. That has still maintained some interest in it. Uboot supports bare metal operation on various different X86 CPUs. Traditionally, X86 uses UFI and Coreboot and so on, but Intel FSP that's become standard now. There's actually not that much code needed in the bootloader. A lot of it is in the FSP. In fact, Intel has a thing called Slim Bootloader. Anyone heard of that? Yeah, it's very new but this effectively lets you boot using the FSP, this sort of binary blob stuff that Intel provides and very quickly get something running on a platform and Slim Bootloader recently supports Uboot as a payload, so you can jump into Uboot and then have all these features, all the Uboot features that you expect, but you haven't had to do very much work. So X86 is an interesting environment. I'll just quickly mention logging. Again, this is not widely used, it's fairly new, but if you build, for example, if you build Uboot with all the logging enabled and run it, it will produce huge amounts of stuff. All the debugs turn into printfs or whatever. So there's an ability now to categorise things. Let's say, for example, it's a USB message or a spy flash message and you can filter accordingly. There's different levels from debug up to info or warning or critical or whatever. And some little helpers like this thing here, which if there was an error, then we just return the, we log a message and return the error. Now this gets cut down to just simply a return of the error, but if you've got logging enabled, you get a message telling you why it returned with an error. This can be very handy when you're trying to debug a particular driver or whatever. So again, it's not really widely used, but I think we'll start to see the sort of thing used a bit more. And Pat Mann is really, really old. I really shouldn't be, I really shouldn't be talking about this and something that's new, but many people are not aware of it. It's just a little tool which lets you essentially build a patch set and send it to a mailing list. Here we're going to send it to Uboot and I'll CC this guy and we're going to, here's our cover letter and it will just produce the patches, tidy them up and email them off before you will let you check them first and that kind of thing. So just mention that. I'm not going to do a little demo. It doesn't run on my Chromebook. So it's going to talk at the end about what Uboot might look like in a few years. So Uboot is, it's very hard to predict because it's very much set by contributors. Someone will turn up and say, gosh, I wish Uboot could buy a supporter. I wish it supported, whatever it might be. And we never really know, you know, never really predict. It basically is driven by the market and by, you know, technical demands, right? And so lots of random things come along out of the blue. Uboot is basically there to quickly and easily boot your system into an operating system and whatever that system might look like and so as systems change trends change and so on, Uboot's obviously going to evolve. But here's a few things that I think I can predict with some confidence. I mentioned the test farm business and I think we'll likely see a lot of custodians having two or three boards or four boards sitting there, running tests, pointing to a particular tree, maybe it's master or some of the other trees on that lab and running automated tests and emailing me or somebody when they break things. So I, for example, I know that Nvidia does this because every now and then I'll get an email from some automated thing at Nvidia saying, you broke this. Not very often, I should hasten to say. But yeah, I don't think there's very many companies doing that. I listed some, I think, do it but it's not widespread. I think that will grow and the benefit is that regressions become less common. At the moment, if you're using a really widely used board, it pretty much always works but if using some weird board that, you know, and you've it's been two years since you updated Uboot and you're going back to update it, then maybe there'll be a problem because it's not getting a lot of testing. I think the driver model migration will start to come to an end. There's quite a lot of deadlines this year for most of the subsystems and k-config, I think there used to be 9,000 config options. We still have 4,500 out there, most of them are board specific but I think that migration maybe will come to an end at some point before the end of the universe. I think we're going to see more Linux code in Uboot, some of the subsystems that are coming around is a lot of pressure to make them work in a similar way and be able to update them from Linux back and forth and that sort of thing. So I think that's something we'll see and I'd like to see this but I don't know if it'll happen that new code comes with tests so when you write a new file system or when you driver or whatever there's a test that goes along with it to make sure that it works and that nobody breaks it down the track. And finally Uboot just keeps getting slightly bigger, a few bytes here, a few bytes there little new features and so on and it's extremely configurable. You can turn off an awful lot of stuff you know you can turn off a command line for example and save a huge amount but I do have a scraping concern that you know it's getting a little bit bigger to do the same thing as it did 10 years ago and so I think we'll likely see some effort in that area to sort of start to trim it down a little bit as well. So sorry that was a little bit abbreviated due to my laptop fell up but thank you for listening. I do want to say if you've never seen a patch to the Uboot mailing list now would be a great time to do it. It's a pretty friendly mailing list I think people most of the time you know all in it together and get on pretty well and they're happy to help there's an IRC as well where people are always helping out I'm not very good at that but yeah if you don't have any trouble please sing out my details at the bottom if you email the Uboot mailing list and CC me you'll get me so that's it I don't know if anyone wants to have any questions but thank you very much sure are you talking about Buildman this thing better in what way if you're building your own board you typically do an increased use make we use an incremental build yes you can use Buildman every time you want to build for your board but it's not very efficient for that it's more to do with all of them yeah I mean I don't know love to improve it it's basically it doesn't use it's incremental in the sense that when it builds the first commit and then it builds next ones they are incremental so it's not just rebuilding each one very fast I mean I know 24 hours to build 200,000 commits is not too bad yes there's a config file that lets you select the toolchain so you can do what you want there but yeah patches are definitely welcome anyone else yes LPDDR training well I'm seeing for example Rockchip recently moved to using TPL and doing the training there because the code is so large yeah I think I don't know where that's going to go I'm also just recently been looking at until Apollo Lake and I think it needs 180k of memory for the memory phase and it takes something like 30 seconds 25 seconds to do the memory training so well I think you might have problems probably not as bad as that it is a challenge that the technology is getting more and more bleeding edge and more and more advanced and I'm not too sure where that's going to end up anything else okay well thank you very much for listening