 Hello, my name is Ben Webster and today I will be talking about the introduction to Uboot bootloader This talk was originally written by America's hut and Essentially it is licensed under the CC by SA 2.0 license share and share alike My main job is as an embedded Linux consultant Linux current kernel engineer and trainer and course author for the Linux Foundation And today we will be discussing Uboot and how it gets used in the embedded industry So let's first talk about bootloaders Bootloaders are generally in multiple stages and indeed there's no different in the embedded world Basically, there's usually two or three levels of bootloader before we get to the Linux kernel Initially, there is the first stage bootloader and this on SOC's in the embedded world Typically resides inside the boot ROM of the chip itself It basically takes the reset vector and tends to initialize enough of the hardware so that it then can read the first user-controlled bootloader From storage before it goes up from there The next of course is the first user-controlled bootloader. It's usually in several parts as well It is it is fairly common to have the first part of that be what's called the SPL or secondary program loader Now in the case of Uboot This is a cut-down version of Uboot that essentially initializes the rest of the hardware such that it can then load a More featureful version of Uboot, which would then load the Linux kernel from there Uboot of course beyond the SPL tends to bring other Features and so on things like an interactive shell boot monitor debugging tools the ability to mess around with hardware to test Things and so on The reason why we tend to have a separated SPL from bootloader is the SPL Tends not to change much. It tends to just be enough Capabilities in order to load the rest of Uboot whereas Uboot itself being a bootloader much larger surface where problems can happen The ability to upgrade or change Uboot in order to solve problems in the field is typically very nice So whereas one doesn't tend to want to change the SPL much Uboot itself can sometimes be uploaded and or rather upgraded This is what Uboot looks like when it boots and you can see here that the SPL has Loaded first and then it's turned around and load loaded a larger more featureful Uboot in order to do the rest of the work It also shows you which CPU I squared C DRAM these sorts of things and then gives you an opportunity to drop into the command prompt Or it will start the default boot up sequence For the Linux kernel in this particular case, so press space and you get to a prompt that looks like this Again the SPL is a secondary program loader the idea effectively is it's just enough of the Uboot so that in fact it can then load a second part now This could be Uboot itself a bigger version of Uboot. It could be the Linux kernel It could be a tertiary program loader in certain situations For instance on things like one and sometimes it you need another level of bootloader to basically read Extra information before you can get to the real kernel, but TPLs aren't often used very much Now let's look at the basic Uboot commands Uboot has a couple of different options for its shells. There's the older original shell Which actually never had a name or there's what's called the hush shell The hush shell was something that was ported over from busy box originally It's a much better choice in general just because it has more options and indeed we will be talking about the hush shell in the rest of this Talk it's very similar to the born shell. So very much like a unique shell in many respects It does have a key value storage for environment, which can be made persistent and indeed support scripting which allows for Failover and upgrades and other kinds of things if you so wish pretty much do whatever you want to with it First of all like any good command line, of course There's a help and indeed if you type help and then press enter it will show you all the various commands their help and What have you? Now it's pretty useful and indeed you can actually go one step further and get help on individual commands You'll notice here that we've done help on echo help on BD info and it tells you what the commands mean and other kinds of information Also, if a command has sub commands help is very useful. It will list those what they do Here's an example of the USB subsystem. So, you know, you'd start reset it Stop it see a tree of it. So if you have USB hardware, you can poke around a little bit and see how it works Now let's first look at the echo command. So just like any shell echo allows you to echo out You know text and that sort of thing Unlike the born shell or or any kind of shell scripting, however It does not support control sequences like perhaps you're used to the only one it does support is backslash C Which you have to escape and that what what that'll do is it will suppress a new line So as an example here, you'll see that we've echoed out hello world and then we've echoed out foo Backslash backslash C echo bar and of course, it's pushed together foo and bar it as a result of suppressing that new line BD info is another command that allows you to look around the actual board itself And you'll see here it prints a lot of the settings that are in that are specific to this particular hardware So what ethernet device is being used what the load address is where DRAM is all that other good stuff So you can see all the sort of fundamentals of the platform that you're on which is very helpful when you're trying to figure things out Now if you want more help There's in fact, of course a website at Denx.de Certainly, there's a IRC channel on free net that you can go to it's a hash u-boot And of course, there's the mailing list you boot at list.denx.de all of them are good places to ask for help and indeed the maintainers and sub-maintenors hang out on those places and can answer questions Next let's look at you boot memory access commands to see what's possible there mw and md These are useful for reading and writing values to memory and registers and other kinds of things Now by default it will actually look at a long which is 32 bits specified by the dot L Postfix, however, you can make it eight thirty sixteen thirty two or sixty four by using dot b dot w dot l and q Byte word long and quad word Now you can read multiple units of things at a time by providing a length The nice thing is is that once you provide a length the default for the next command is Replicated and indeed like anything on the command if you press enter by itself that will repeat the previous command So it allows you to essentially do a memory display and then press enter and it'll just keep on Incrementing through the addresses thereafter. So we show an example of that here Writing a value showing it and then indeed just memory displaying through it the things thereafter with just printing pressing enter I can also use some toggle things like Memory connected GPIOs and that sort of thing here. We're giving an example of of Playing with it the GPIOs that run the LEDs on the board that we're going to be demoing a little bit later So in this particular case looking at the bit fields that that control these particular LEDs Also look at memory access commands memory write memory display In this case, we're showing you an example of toggling GPOs GPIOs the hard way These GPIOs are connected to blue LEDs on the platform. We will be demoing a little bit later You can see that up here But this is how one can do it. So you can see how you can Basically set the GPIOs up and then indeed play with the values using memory write and we display We can also use memory modification commands these allow a little bit more interactive ways of dealing with memory So you can modify registers memory at addresses By using mm now mm is nice in the sense that it will auto increment as it goes through memory By starting at a particular address you can enter values and then press enter It'll take you to the next offset and it'll keep on doing that until you press q if you want to go back You can press the minus sign, but otherwise if you really want to not make a change and skip a line You can press enter, but it allows you to wander through through memory and make changes as you go And on the other hand does not just as the one entry and then that's it You can also copy memory so you can you know set values for instance that we've shown here Copy memory somewhere else and then indeed you can compare two different areas And so here you'll see we're giving an example of comparing memory between two addresses We'll show you what's the same what's different and so if you make a change It will in fact point out what that change happens to be Next let's look at you boot environment and scripting commands So the environment new boot is purely a key value storage it lives in RAM. There's a live value Live version rather now originally it's read from the uboot binary that it comes in however, it can be overwritten with a stored or persistent storage and so it will start with a default version look for updates and indeed what you get in memories is therefore the Combination of the two if you make changes you can of course save it so that the next time you reboot it will take you back to that So modifications can be made they can be saved they will survive reboots However, if you don't save them you go back to what the values you had from before So first of all let's look at printing values now there is the older print and command It is an alias for the more up-to-date versions of that Env is a command that has a number of subcommands one of them being print So whether you do an end print or a print and in fact you will get the same output So here is an example You'll see that if you type end print it will print the entire Environment table it will show you the size at the end if you want to just end print one of them or print end for one Of them like arch for instance It will just show that one thing and of course if you want to just see the value of something you have to echo whatever that the dollar Variable name is as you can see on the slide here You can also set values with set and or the newer version of course is and Set and so if you end set foo to bar of course when you do an end print of foo It will show you foo equals bar You can also ask to set values And so if you set if you say and ask and the name of a variable and then a prompt In fact, it will print the prompt you can then type in the value when you press enter It will assign the value to that variable. So an example here. We have cooks set to one two three four As a question and then indeed if you print it as you can see that cooks equals one two three four You can also edit a value. So and edit give the name of the variable Allows you to type in the new value when you print it, of course, it will be the new value When it comes to removing variables In shell you would normally type unset something in you boot. You just set it to nothing So you say M set and then put no value. It will in fact delete the variable as a result Of course, you can also save settings normally when you make changes They will be wiped out during the next reboot However, if you save your changes and you can save to raw nand or to a file system as a file Whatever however, it's set up But once you type save n and then reboot any changes you've made will persist and essentially will Come up the next time you boot up and go back to the command line. So you can change settings interactively, which is quite nice Of course, we can also run Variables as if they were scripts So whatever you type at the command line, you can put it into a variable And then when you run that variable as you can see in the example here It will do its thing now semi-colons can be used for separating Commands and so you'll see here that if we put two commands in a variable separated by semi-colon It's if you as if you typed one press enter and then press the other one again. So here. Hello world on the next line Variable expansion is also something you have to be careful of when you're using scripts Bear in mind that that if you just include a variable in a script essentially it will be Expand it immediately. So here's an example We set foo to bar and then we set cooks to echo dollar foo No, in that case, it will actually be expanded So you'll see if you set foo to a different value and then run cooks See that it is actually set to bar because it was originally expanded during that set and However, if you do if you escape the dollar sign, you'll see that if we do an end set of cooks echo backslash dollar foo This time of course when we print cooks, you'll see that the dollar foo has not yet been expanded When you print that in fact the appropriate value will be expanded at the time So just bear in mind you sometimes have to escape the dollar to make it work appropriately There are also very number of special variables in the environment table Things like ver which is set at boot time to show you the the version of you boot that you're currently running Of course things like standard in standard out standard error. These are all the sort of standard Standard IO things that you're used to Things like load adder. This is the default place where things get loaded by the the various Things commands that read from disk or from, you know, why modem or TFTP or what have you file size is a variable That's set whenever a file is loaded into memory. It's automatically set to the size of what was read Boot args is used to pass arguments to the Linux kernel of the command line So we need to set that before we will boot appropriately There's another very variable called boot command. Now. This is the default boot command when you just type boot It actually turns around and calls run boot command And this indeed is what gets run automatically if you don't press spacebar to get to the command line There's also a pre boot script now this runs before we start to auto boot. It allows you to set up things like You know the console appropriately or what have you Next we have network settings things like IP adder, which is the local IP address netmask right, you expect what that is server IP is typically the IP address from which we either got our IP address from DATP or where we will TFTP something from if We're using that technology and then we have the gateway IP Of course is of course the gateway for the network connections that we have Our ethernet MAC addresses of course can we have made we have more than one those are also stored in our environment table The set expert command is a bit like the expr command in in shell normal shell It supports a very narrow set of commands. However basically some arithmetic commands and some logical things like and or or x or This basically allows you to do different things to to modify variables here We have an example for instance of displaying a value at a particular address and you'll see here. We are Referencing that value using set expra and putting that into a variable in this case of into foo Then you'll notice that we can print the value of foo We can also set variables to different numbers and then for instance add them or subtract them or divide them What have you as an example here? It also allows you to do very simple Substitution so in this particular case you'll see that we're taking a reg x basically a a pattern and we are replacing it in a String so you'll see here that we have a a b b c c the pattern We have is a b plus which means a followed by one or more b's and we're saying replace that with an x and you'll see We go from a a b b c c in this case to a x c c based on that command Next let's look at shell conditional expressions and loops So here we of course can use just the straight-up true and false commands like we'd see in regular shell script and Indeed the dollar question mark gets Set to whatever the return code of the previous command is so true. We'll of course set the return code To zero as you as one would have in on the command line A normal born shell command line and false will set it to one again as one would expect Conditional expressions, of course, you can use things like if and while if true rather if condition then else Phi Same as in shell scripting. We can do those kinds of things So as an example here if true then hello else I go by right if I That will print hello. However, what you cannot do is you cannot do the inverse of something You can't say if not foo. Okay, if not true for instance, so I'll work around for that as in fact always use the else command so if You know if something then false else and then put what you would have Used in your your then otherwise in that second piece So it's not great, but it does work and indeed another way of doing it is an expression or Something at the command line that also works We have a couple of examples of how to do that here with or an and just to show you how that's possible again, it works just like on a Shell command a born shell command We also support test Which is a limited version of what came from hush. So of course we can say things like less than greater than equal Greater equal all that other good stuff and again You can mix this with ifs and while loops and so on and so forth and again here's some examples of how that all fits together Here's a for loop and indeed again. It works just like the born shell You'll see here that we have a sequence here a b c d and I will be set to each one of those values and indeed the Loop part of this the do echo dollar. I will print out each one of those in a different line As one would expect While loops again work just the same way. Here's an example of you know while true do echo Hello endless loop the way you get out of that was with a control C that will take you back to the command line again Just like you're doing regular shell programming next is you boot data loading commands and You can load things from all sorts of different kinds of storage. We can do this from you know SD cards USB storage devices like SATA drives NAND You know all sorts of different kinds of things and you can do both raw storage or indeed Support for different file systems. Many file systems are supported things like the straight-up DOS VFAT format Sadly not XFAT, but there is the EXT file system the Linux file system is supported UB and UBFS newer raw NANDs formats are also supported Unfortunately squash FS is not supported but just generally speaking you'll find that The the universal file system access commands things like LS load and so on will auto detect file systems and then run the appropriate Subcommands of the various file systems otherwise, which is rather handy So here's an example for instance of using an SD card Managed by the MMC subsystems doing an MMC rescan will basically look for cards or EMMC chips that might be available. You can of course print the partitions here MMC part We'll show you the partition of that thing You'll notice we do when we do an LS we have to specify the not only the subsystem We want to go to but also the device and the partition in this case. You'll see we're doing LS MMC zero so device zero one colon one rather which is the first partition so so LS MMC zero one list the first partition on the first SD device that you find and in this particular case you'll see that it we see that there's an id.txt file on it We can then load that into memory. I'll notice we if we type load MMC zero colon one Load adder is the address we want to load things to and then the name of the file It will run the appropriate load file system command For that partition and load that file into memory at load adder and then set the file size So you'll notice that on the next line when we do a memory display Of a byte dump of that that file we get the load adder we get file size It will basically do a hex dump in this particular case You'll see it was a text file so we can see what was in it and from memory We also support Network commands now you boot only supports UDP protocols so things like TFTP NFS DHCP boot P DNS right and if some of those protocols do support TCP, but not under UDP not under UBOOT So we can do all those sorts of things so things like reading files off TFTP or NFS that works Certainly getting an IP address over DHCP or boot P works ping Some ICMP is supported Very very handy. You'll find that TFTP and DHCP are largely linked TFTP by itself will just TFTP a file DHCP or at least getting an IP address from DHCP Infers that you also want to TFTP so it will auto load Something from whatever server it gets an IP address assuming there's a TFTP drive on it is a server on it as well Here's an example of Optionally setting your MAC address Theoretically that's in your environment already You'll see you can set your IP address statically if you don't use DHCP set your netmask the server IP This would allow you to ping it Of course you could also a TFTP something from it or indeed DHCP which would get an IP address and then TFTP as well and again the notice that we're going into load adder You can also load over a serial port. This is a bit old school But sometimes we have no other options and so since we're using a serial port to get to the command line We can use things like X modem Y modem S records Kermit All sort of the old ways we used to do these things all the time before we had ubiquitous network connections or USB So as an example for instance, we type load Y. We'll start up the Y modem protocol We can then use things like the SB minus T command from LZRs as said Package in order to upload things and so for instance if you're connecting over screen to the serial port as many people do Uh, once you type load Y if you then press control a and then exec bang bang SB minus capital T and the name of your binary. It will then load it appropriately Alternatively, you can open another shell and you can run screen minus X minus R capital X and the Basically the same command don't forget to escape the the two bangs The reason why we can do this is because screen allows you to do concurrent access So minus X basically connects to the same screen session And uh, we'll load your binary that way. So that also works Next we'll talk about booting the kernel Okay, presumably you're booting linux with uboot. Although it's possible to boot other things Uh, but linux can be basically wrapped in a couple of different ways. We can use a raw Z image, okay, which allows you to uh load a kernel that's been brought in from Just the raw build Linux of course itself decompresses into memory and so we can just use that Uh, the big problem here is there's no crc or other kind of hash Checking for problems. So no bit rot protection Uh, it just basically dumps it into memory. We jump to it and hope hope for the best It does support optional device tree Certainly in the case of we can either pass one in or one can be Appended to the kernel if we support that But generally speaking it basically works like it would work on any any, uh machine Now, uh, originally uboot supported the u image format and it's been around since the beginning The nice thing about it is it was a nice wrapper around an uncompressed kernel and indeed could implement its own compression Um, these days we don't use that because kernels are self decompressing CRC 32 checksums are always used so we could see whether the the kernel is in fact valid This is great when you have more than one kernel due to upgrades or what have you But the old u image format would only wrap a single file It does support an optional device tree, but you'd have to provide that separately however on newer systems and uh by newer This has been around for a while and that's something called a fit image And uh fit images are nice in the sense that they're they're kind of like tar files if you will They're multi component images and the nice thing is is is um Is they allow you to describe multiple internal files So you can for instance package up a kernel a device tree configuration and other things all in one file In fact better than that you can do more than one kernel if you need to Perhaps you're supporting more than one platform So these are all things that are possible. So it's based on the same device tree format It does support multiple different files and in different versions of files potentially You can program which algorithms you want to use for file integrity. It supports digital signatures There's all sorts of reasons that one would want to use it Now going back to booting from a uh zed image for that you need to use the boot zed command And indeed that will allow you to make that work properly We also have boot i now this will allow us to boot in arm 64 ar 64 image boot m Was originally designed for the u image command But in fact will automatically detect fit and do the appropriate thing there as well And then of course you've got the boot command variable Details what the default way of booting up happens to be and indeed you can learn more about all these different things by using the help command Next we'll we'll we'll see what uh booting a kernel Kind of looks like you'll see here that we're setting our our boot arguments In this case, we're setting our console And bod rate one might also want to set the root file system root file system type and so on But whatever you need to pass to your kernels is done here next Uh, you'll see that we're also loading a kernel here in this case Into the 82 million address from the first partition on the first m mc device Uh in our second line here, you'll see that we're also loading a device tree in this case for the pocket beagle Into memory again at a known location And then finally running boot z passing in the address of the kernel dash for an optional Initial ram disk, which we're not using in this case And then the final address is the address of the flatten device tree And notice that it finds the the ft t the dtb file Loads it and then it starts the kernel and we see it start out Device tree just really fast and there'll be a talk on this a little bit later Um essentially describes the hardware the the reason why we have it is because in embedded we often have hardware that cannot be enumerated or uh detected through normal means And so we have to describe what everything is and how it all connects So this tends to describe everything that's in our reference manuals on the schematic of the product that we're building Device tree is an acyclic graph It has a series of nodes and nested nodes and properties that essentially describe how everything fits together Each node represents a specific thing and each property describes aspects of that node or that that thing that it's describing Nodes can essentially Contain not only properties, but also child nodes. And so you can actually have a hierarchical set of Of devices and settings that allow everything to fit appropriately if you want to learn more There's a link here to the wikipedia Uh page which then points to all the different specifications and and the website and so on There's also the ability to Basically have pointers to other places within the the device tree and these are called p handles their references to labels that label other nodes and so for instance, you might set it to In an angle brackets ampersand l2 that would take you to the l2 label on whatever node it it was associated With and what that means is that we can basically link anything to anything else Which of course gives us that acyclic graph as opposed to a straight tree So here's an example of a device tree. You'll see we have a version 1 device tree here We've got our include at the top Device trees in the linux kernel are run through cpp. So we use the pound include Here we have a few different things that are listed. You'll see we have cpus and what have you but it shows you Roughly how it all fits together This is the format of device tree And here's a fit image and you'll notice it uses the same format. So device tree version 1 all the different Properties and then the different nodes with the different properties set as one would expect So similar uses the same Parser and that sort of thing to make things work properly here. You'll see that we have a kernel That's defined to be loaded from a particular location in our build Here we have a Flatten device tree same deal being pulled in from a particular location. Notice we specify the algorithm for doing File integrity and that sort of thing whether or not it uses compression or what have you And then here at the bottom we have our configuration that ties the kernel to the flatten device tree the hash algorithm Tells us what it is, right? And you can see how there'd be a possibility of having more than one configuration within the same Fit image notice at the bottom. This is how we compile it into the binary fit image So we take the ITS file which describes where all these things come from we run it through make image And it will spit out the fit image binary which we can then load onto the device So the fit image commands if you want to load Load that and boot from that you run boot m and then the address of the fit image Basically everything that's required is in there. It knows what's kernel what's configuration what's Device tree basically everything works appropriately Nice thing too is that when you type im info it will basically tell you what's going on in there Tell you what the os is the load address The kernel image, you know all the different metadata about it. It's quite nice And you can also extract information from from fit images So iam extract will allow you to pull things out of it and indeed to look through it Of course one can then use md the memory display command uboot also does support flatten device tree from the command line So you can both print and manipulate and change and add and Delete things from the the flatten device tree once it's in memory. So For instance, here's an example of loading that device tree and then in this case making You know printing out some stuff and seeing how it all fits together Again, one can add to it See what's there and then of course ultimately boot from it The idea of course with uboot is that one can read the flatten device tree Perhaps makes changes to it during a script before passing it on to the kernel So it completely understands that Next let's look at some miscellaneous uboot commands So we can also get all the different kinds of of hardware that happens to be there So things like gpio so we can Effectively do all the sorts of things one would expect we can read gpio set them clear them toggle them This allows us to essentially mess around with external devices both inputs and outputs And indeed we'll be showing how this works a bit later We'll be playing with some leds and some push buttons in the demos I squared c also has commands for it. So we can wander around on the bus we can Essentially read values from memory On the I squared c bus we can probe things we can Set the bus speed do all kinds of things one would expect to do in drivers we can do from the command line in Uboot and so we can essentially play with the hardware before we boot our real operating system and even use this in in Manufacturing or debugging when we're first putting boards together Next let's look at compiling uboot from source So you can get the source code from a git and indeed there is a a git repository at denx.de There's also a mirror of that on github. So you can get it from there as well The custodian trees are also available at all these are the places where essentially they're the sub-maintenors if you will for for uboot So they all work together And indeed you can get it over git or http so that all works appropriately It's a little bit like compiling the kernel in the sense that it has a series of of def configs You set cross compile in order to cross compile it But here you'll notice we're cloning the the uboot code We're then setting cross compile in this case because we're compiling it for arm just as an example We're setting the default configuration in this case for the satara chip That's used on the pocket vehicle that we'll be using in the in the demo And building from there Now We'll also see that uboot does have a sandbox version that you can run On in user mode to play with the commands without having to run it on real hardware and in fact, there's also qmu Targets and other things as well that allow you to play with it So it it runs in a number of situations where you can play with how it works And on that note, let's get to some demos and we'll play a little bit with things and again We will be using This setup here This board It is a pocket beagle and it is on a tech lab base and this will allow us to play with some of the things that Allow us to See how they work You can find more information about the pocket beagle and beaglebot.org and indeed tech lab as well You can buy them from the normal places You can find the slides these labs and the solutions at the following url And when you get the slides for this, you will be able to Give this a try So let's go through this and start from the beginning So first things first we are going to go to the command line And we are going to connect to it using in this case screen the usb serial port that we're going to be using is tty usb 0 and indeed if we look at We'll see that it is in fact there and indeed it is because we have connected This usb port here that we have access to the serial console So we have of course we also have to specify the baud rate so do that And i'm going to reset the board so you can see it Boot up and there we go And so you'll see there's the spl and there's you boot popping up Indeed if I type help all the different commands Press enter again, of course, it'll run it again. I can write help echo right help I to see see all the different commands that happen to be there Okay, so that's the first lab get to autoboot The next thing we're going to do is we are going to Try to boot a card from the sd card Now if I just run boot this this board will in fact board boot all by itself But instead what we're going to do is we are going to try and do it ourselves from Just typing in commands and indeed what i'm going to do Is i'm going to Cut and paste here So here i'm going to set the root file system. I'm going to set the console and like this And then what i'm going to do is i'm going to type mmc rescan Okay, i'm then going to load the kernel There it goes and then i'm going to load the Device tree and so here we go Just cutting and pasting so I don't make any typing errors. There we go And then we are going to boot the kernel No initial round disc and then The flatten device tree and so when we boot that up There we go. The kernel comes up and indeed We start up Until we get to the boot prompt to take a second and Come on There we go and indeed if we type in And notice that the username and password are specified over right there Okay, and here we are Indeed if we look at proc command line You'll see there is the boot arguments that were passed into the kernel Okay So Next thing is we're going to so that's that's the next command And notice that the solutions are also in the in the uh Slides Next what we're going to do is we're going to boot the kernel uh from the sd card with an adjusted device tree Okay, so basically what we're going to do is we're going to make a change to the device tree as we boot so we're going to reset the board And drop back to the command line And so what we're going to do now is we are going to um replace A change in the Um Flatten device tree And so mmc rescan And then we're going to set The boot arguments again Okay, and then we're going to load the kernel again Because of course we lost it when we rebooted There's the kernel We're going to load the flatten device tree again Okay, but this time what we're going to do is we are going to make a change to it So now what we're going to do is we're going to type ftd adder 0x88 this is the address we Loaded the flatten device tree into Okay, so if we do a Fdt list We'll see there is the device tree All right, so what we'll do is we'll Go up there and you can see the different values, right? You'll see the model is currently set to ti am through three five x pocket beagle Okay, and what we're going to do now is we're going to type ft set Model Hello world. Okay. So now when we run ftd list I'll see now the model is set to hello world okay, so Now when we do the boot said 0x8 to one two three four Now when we boot There we go So up at the top there you'll see that the model number will have been printed We'll just wait for it to boot and then what we'll do is we will log in And we will look at d-message to see what it was set to just to make it a little bit easier There we go And if we now do a d-message and grep for model See there it is machine model. Hello world okay Again, I'm going to reset the board and go back to Command line and we'll go to the next lab Next what we're going to do is we're going to play with the gpi input command and we're going to try and Read the value of a button Now the way we're going to do that is we are going to um Basically write a little command here just like this echo button not pressed And we're going to press enter now and notice we're not pressing a button So button not pressed at the bottom we're now going to take and press the button that's here and rerun the command Now it says button pressed and I'm going to let go Run the command not pressed Button pressed there you go So reading that particular thing we just in this case we happen to know that gpi 45 is in fact that button from the device tree and Indeed from the schematic of this particular board If you look on the website, it will show you what gpi's are connected to what Next what we're going to do is we are going to blink a The led there's four leds on here for blue leds right here that happened to be off at this particular point in time And the lab here basically gives some ideas of how these things work so what we're going to do is we're going to set up the um The leds appropriately set up the gpi appropriately and then we are going to do Little command here. So what we're going to do is we're going to set up A while loop We are going to set our Set a particular led We're going to sleep for a second. We are then going to clear that led Okay, and then we're going to sleep one again And we're going to finish and so if we look up here This guy's right there Notice that it links on and then off and then on and then off Right there and press control c and it stops Unless it's now off again Okay, let's look at the next one And look at uh task number five here and so here we are going to Play with The leds again and what we're going to do is we're going to turn them all on so these are GPIO 53 54 55 and 56 so instead of playing with the memory Addresses directly we're going to use the GPIO command instead And so the way that works effectively is Again, we're just going to write a quick while command here And we are going to Do a for loop And GPIO set dollar i We are going to sleep for one second GPIO clear Now let's watch right here What this is going to do is it's going to turn on the first one and then off the next one And then off the next one and then off and the next one off and then repeat So look right up here And there we go as it marches up bottom two three four Okay up there, of course And of course control c and it will stop where it was At that time all right Next we're going to look at uh loading something via y modem to see that work properly Okay, and to do that what we're going to do is we are going to first Leave We're going to leave screen And what we're going to do is we're going to create a file and what i've done already So i've created a file on slash temp called m dot text and in it i have hello equals world And foo equals bar Okay, and i'm going to reconnect using screen All right, and what i'm going to do here is i'm going to run The load y command and what this is going to do is it's going to load something into The address of load adder So here we go it's going to run control of y modem and i'm going to do a control a colon x sec bang bang sb for y modem strangely capital t minus capital t and then slash temp slash env dot txt and this should This is a knack because Took me a while to type There we go and it got sent and it got loaded So now what we're going to do is we are actually going to Do a memory display dot byte of load adder oops load adder rather File size, which is it's now set appropriately And you will see that it says hello world and foo equals bar as we would expect And then indeed we can do a Env import to bring it into our environment if we because we can do that Right and again file size This will essentially read it as if we're sourcing a script at the command line and Right and so it's actually read it in now and now when we do an env print. Oops print Hello, you'll notice that that is set and indeed env print foo foo equals bar Whereas if we reset Notice that env print foo not there env print Uh, hello Also not there. So we made those changes. We did not persist them and indeed when we rebooted Uh, away we went it disappeared and See that it was not set Next what we're going to do is we are going to uh build u boot in sandbox mode just to give that a try Okay, and the way we're going to do that Is we are going to Come over here now. I've already checked out Uh cloned rather um u boot Here it is. I've got this straight out of um Straight out of I get so I did that first command already Once in u boot what we're going to do is we're going to do a make Sandbox def config and what this will do Is it will actually create a configuration file For u boot to run in user space Not as a bootloader just as a just essentially allow it to run as a regular program. So you can do just simple Operations there debugging and such just on the the default non hardware facing stuff Uh, next we're going to build it and we're going to do this by doing a make minus j And we're going to speed things up by basically using all of our processors and proctels Returns the number of cpus I have And so when I run this it'll run a parallel make and build U boot When we're finished in fact there will be a elf version of u boot that we can then run at the command line And although we can't use it to boot anything It will in fact allow us to play with all the sort of regular shell things Which basically means you can essentially write commands and scripts and things without having to have a real platform We could have similarly done this sort of thing in qmu Okay, it's almost there There we go And so now you'll see we have a binary right there's a U boot binary there you'll see that is in fact a runnable uh x86 64 bit Uh device and indeed you'll notice that it looks just like we're putting a real Platform, but of course we're just emulating this in user space and you'll see that we have A environment table And all the sort of normal things one would expect A lot of you just poke around inside there Okay, and when you're finished you can just do a control c and we'll drop you back to the command line Okay, the next thing we're going to play with is some string manipulation using set set expere And uh our sex set expression rather That's how you say it and this will allow us to mess around a little bit with Uh a scenario in this case the idea is that a value has been read in let's say using a barcode reader something that sometimes happens during Uh manufacturing and uh Essentially something comes in as a string that doesn't actually look like a mac address and we want to make changes to that string So it it fits as a mac address now the assumption in this case is that our separators can be either an x a y or a z and so the idea Is to write a script that can handle that appropriately So the idea here is that first of all We ask for whatever that thing has to be in this case. We're going to use n vask Okay, and the idea is that a barcode reader might then oops Put that in place. Okay, so now when we do an m print Mac let's see that it's not set appropriately. Well in order to make that work What we might want to do instead Is use something like this this will take um Let's run this pattern which basically looks for Uh the separators right one or more instances of the separator And replace it with whatever's Uh Basically with uh colon so here it'll replace it with the colon like this So two values and then the separator will be replaced by the two values and a colon This will basically take 00 x and replace it with 00 colon and will do for all those different situations So what this means now is you'll see that my um eth adder is now set to a proper mac address with all the x's replaced by Uh a semicolon or by a colon rather All right, so just playing with a little bit of string manipulation And finally we are going to play a little bit with the accelerometer. Okay And uh, this is an iSquared C device on the tech lab. It's built into the the card here And so what we're going to do is we're going to use these commands in order to make this happen And again all the solutions for this are in the labs And so uh, here we go We are going to Oops i2 See dev 2 And then we are going to Set things up appropriately Um that command essentially sets up the uh the address that we're going to be talking to Um, we need to wake up the accelerometer. So it works appropriately And then what we're going to do is we're going to start reading the accelerometer information in a while loop And that will Oops, I did not cut and paste that appropriately Uh, so we're going to read it in a while loop really fast now That's going to go like this and it's hard to read here, but look at this Right here as I tilt the board you'll see it changes Okay, now if you look at the ASCII values, it's a little bit easier to see but you'll see if as I do this See how they change that's because the rate of change Because of the accelerometer basically when it's not moving nothing changes If I change it to on its side here And see that the values that are read from the accelerometer change with it It's harder to see that way because they're not printable characters, but there you go See so the orientation I'm only looking at one of the axes in this particular case You can see how that works appropriately Okay, and there's lots of other things one can play with use the things we came up for this particular Uh talk and again, these are the kinds of things that one would normally be doing If we were doing this in person, we'd be playing with these directly in this particular session But unfortunately we couldn't do that here You can in fact buy your own versions of these Certainly there's a little bit of soldering involved, but this baseboard and the Pocket Beagle you can source these two together locations at the The URLs that I posted earlier on And indeed these labs can be done based on that Thank you very much and we are now Now can take some questions So I hope everybody enjoyed that And certainly I'm open for questions now if people want to to ask them I've been trying to answer them as I can in the q&a Textbox there, but certainly if people want to ask more questions I can answer them through voice Uh just to go through some of the the questions that were asked during the the um, oh more questions. Sorry never mind lots of questions There we go One of the questions is is how are people getting the linux to boot up in one second? So this depends on a number of different things, but there's no simple answer to this Anybody who's been going to ELC for a long time will know that there's been lots of talks on how to make things faster The big thing about booting your your platform very very quickly is essentially making sure that the straightest path to being booted essentially is followed That tends to mean a lot of hard coding. It tends to mean Very little flexibility. Indeed. It means essentially jumping straight from It means having it as minimal a boot loader is as possible. It means having as as sort of a boot up path as possible and Quite frankly in in some situations it it also means cheating a lot Amongst other things. What do you consider booted up? Does does that mean that you can see the What looks like the control panel let's say on a on a touchscreen or does that mean it it's actually fully functional For instance, I worked on a head unit for a car at one point And the way we got around a lot of those problems Is during the boot up sequence the u-boot rather the the boot loader at the time, which was the u-boot Would throw up a splash screen that looked like the booted system For instance, and so it took people a few seconds before that actually touch it or if they did it just looked like it was lagging Basically things were coming up behind the scenes. So even though we had something that looked like a A startup screen in fact it was still booting behind the scenes So you'll find there's an awful lot of things people do to make things come up appropriately in some cases you can boot up very quickly in other cases there are other techniques but Minimally getting the things that people care about running before anything else is usually the technique Very few things actually boot in one second. They just get up to a point where they appear to be running in one second So hopefully that answers your question Jason another question here Are there built-in methods to access encrypted file systems? Generally speaking, so I don't have a good answer for that. I would say generally no The thing is is that to a large degree. I think normally what people care about more in bootloaders is that your That a secure boot is is more important. So there are certainly ways to deal with signed kernels and signed initial RAM disks and and such but As far as encrypted side of things that's typically handled by linux as it comes up. So I could be wrong there But to my knowledge directly accessing an encrypted file system from within you boot I've personally never done it. So it may be possible. I'm not aware of that being possible Perhaps it is and and I'm sure patches are accepted bear in mind that Uh You boot has a very strict policy on gpl only code and uh non patented things only So you'll find that a number of things in that realm in fact cannot be added to you boot as a result um Are there spi can commands? Like you are at nice wordsy. Uh, there are indeed spi. I'd have to look I believe there's can I haven't actually played with that Um, but certainly there are spi commands as well Uh, there's also ssi and I hope basically choose a subsystem. There's probably a command for it So you can actually deal with a lot of things directly that way as well Does you boot support usb? Yes, it does Uh, in fact, it um, it can do quite a lot in this particular case the example we're giving it does not support the usb Uh port we have on this particular board Uh, where is it here? So it doesn't it doesn't support this specific Uh, this one here However, it could it's just a matter of that the default uboot doesn't have support for for the tech lab directly Um, but uh, indeed it it certainly can support usb. Um, in fact booting over usb is the Uh, is one of the things that one can do uh directly on this board. Um using the effectively the gadget driver oops What else do we have here? Uh, are you using a bunch as your primary error? So can you so, um, actually what you're Uh for for the demos I do here. In fact, I was using a bunch in a vm. So certainly you can use a vm uh a bunch to Uh, it's actually surprisingly common in um embedded linux work Certainly most of the companies I go to the vast majority of them are using a bunch to um either in vms or uh natively Uh, that doesn't mean you can't use anything else It doesn't mean that it's necessarily the best distro for all the things, but certainly it works rather well I use a bunch to in all my classes that I teach Uh, because it's it's literally the 90 95 percent of what the people I deal with use, uh in the embedded industry Um now using it within a vm causes extra complications, but it certainly can be done You just need to know your hypervisor extremely well to make it work Um Next Fernando looking a bit into the use of nfs on uboot. I haven't Hello everybody. I don't know what happened there. I was told to reload my Slides and so I did Not slides my browser rather. Um, let's you know here So I'll just go back. Uh, nfs used in uboot is primarily used for development Uh development. We don't care quite so much about the Credential side of things. I personally haven't played with credentials. Certainly there When I'm using nfs from uboot Usually it's as a nfs root for the kernel and in those cases you're on a very Unsecured Network in the first place. So I tend to make sure that I always have it set over a very short piece of ethernet or You know a virtual network so Um Essentially credentials in nfs usually aren't used very heavily other than development and again you tend to be on a protected network at that point Hopefully one only you can access So, uh, yeah, that's It may be able to do it. I personally have never done it and never needed to What is the uboot linker scripts? Uh, so I think what what you mean by that is the linker script used to link uboot itself Linker scripts are used to put different parts of code and and uh read only data and so on from the kernel Uh specific addresses within the bind the resulting binary It's the linker script effectively describes what goes where in memory and therefore in the l file so things can be loaded appropriately Linker scripts are typically only cared about by people who care about the compiler or indeed uh systems level programming like When you're building a bootloader But to a large degree if you're just extending uboot, you just leave it the way it is the the vast majority of people Don't need to understand how it works. However, uh, if you look, uh, at Any dot o file or library and run it through nm or obj dump. Sorry rather, uh, you'll find that it's broken down into individual pieces sections they're called and if you look through the linker script In fact, it will describe what sections go where in memory and that's that's all linker script is whether it's for the kernel Or for user space or whatever else It's just that we in user space people tend to use the default Linker script for for uboot. It's typically per architecture in some cases per board Depending on where memories put and that sort of thing in the in the design um What else do we have here does uboot have access to linux file system? Uh, so that's a pretty broad question Can it have access to the linux file system? Yes Does it it depends on how you set things up? Um, certainly depending on where it is what what medium it's in Uh, what file system is being used? Might be it may or may not Certainly if it's using a fat file system or On a medium that can be read by uboot. Uh, if it's ext2 ext4 Um, if it's ub ubfs for instance There's a number of file systems that are supported and can be read And in fact that's used very heavily However, uh, that does not mean all things are supported. So for instance uboot cannot directly read squash fs Squash fs can be used by the kernel, but may not be able to be uh, rather Isn't accessible from uboot at Before the kernel starts up for instance as an example But otherwise, yes, you can load and save files to things like fat ext2 ext4 and so on Next screen how large is a typical uboot these days my last experience with Uh, I need more information there. Uh, what architecture? What board? What features do you want? The spl is quite small and it itself is a uboot So if you want to turn off all the features it can be relatively small The instruction set also matters. So a 64 bit instruction set your uboots can be twice as big as if it's a 32 bit one for instance um Lots of variables there. So, uh, it's still it's still in in the megabytes, you know megabytes range. So the smallest ones can be relatively Small, you know a quarter quarter megabyte for basically no functionality and a very very small processor The spl is roughly that size for an actual The the uboot boot loader side of things it can be you know on the order of a megabyte or bigger depending what other features you want in there So, uh, it's by no means itty bitty, but it's by no means huge. It's nothing like the size of the kernel for instance But again, but basically there's too many variables. I can't tell you exactly how big Uh, I can talk a little bit about driver porting like the older version to a newer one some pitfalls uh, so If you're using uboot remember it's gpl v2 and so If you are putting code into uboot You need to upstream it and if the code is upstream then essentially it will be dragged along with that Hopefully there is no porting to be done Um, but uh, just just bear in mind that that it is gpl v2. You are linking things directly into uboot. So um, as far as porting things it's something it can be done publicly on the mailing lists uh But yeah, I don't want to get too far much further into that because, um That there may be other things going on there Um Off topic. What is the get extension the shell? Uh, when you built uboot? Oh, you're talking about my my shell prompt look up, uh, just Google oh my bash Okay, there's a the the original one is called oh my cash K shell, but oh my bash with dashes in between. Uh, you'll find uh A whole lot of of interesting things for making your prompt look pretty like that and it's not just a get thing That supports all the things Uh Is the difference in device trees for uboot and the kernel? Are they the same? Uh, in theory the same in practice The changes made inside the kernel and the changes made inside uboot Uh can be different. So there is some coordination, but not completely if you Uh, if you get an embedded linux engineer if he doesn't use uboot together and um an embedded uboot person Who doesn't do a lot of kernel work together and have them talk you'll find that there are differences, but in theory Uh, in theory, they should be the same in practice. Uh, both are moving. Uh, at slightly different speeds so, um The the older stuff is largely the same, but there are indeed differences between the two in some situations Can you explain how to cross compile uboot? uh cross compiling uboot and the Linux kernel are essentially the same You specify your cross compiler and your architecture that you want to build for so, uh We do it in the labs in the slides you specify our arch equals and um cross compile which In which case you you specify the uh, what's called the um the prefix of the the compiler So when you you're running a cross compiler, you'll notice that it's um For instance arm linux gnu a bi hf dash gcc the bit Uh prior to gcc is called the prefix and so you set cross compile equals that bit with the dash at the end Uh when you compile and so instead of using gcc it will use the arm linux gnu a bi hf dash gcc version instead And that's basically it otherwise it's just like building the kernel cross compile. It's it's the same mechanism Um a lot of the same people work on both projects What else? Oh, thank you very much What are your thoughts on applying device to your overlays via uboot? Is this feature ready for prime time? so overlays, um, there's at least one person on the call it probably might still be on the call who have have better, uh Opinions on this but essentially overlays in uh in linux are are still problematic There's still lots of different things that are that are being thought of uh thought of to make things work there the nice thing about Applying overlays in uboot is it's kind of the original way all this was intended Uh uboot was really the place where you were supposed to play with flatten device trees before we booted up into a static Uh device tree set up So I would say overlays in uh uboot are very much the original intention Not so much overlays but modifying the uh flatten device tree During boot up before we started in the kernel. It was kind of the the whole idea Uh, so I think that's a really good idea It it sidesteps a lot of the problems that people have With uh live changes later on when the kernels booted um Certainly before we boot we have lots of time to do those kinds of things The boot loader can make any changes at once. There's no security From what it can and can't do so it's really a good time to do it. So Making changes to the flatten device tree before we boot the kernel Is kind of a a a a really good way of doing that Exactly how it's implemented of course changes depending on who does it So, uh, that has not been standardized yet, but as far as a good idea is concerned. Yes Does it support all the use cases? No, it does not so um You know, we still have a ways to go. Uh, is it ready for prime time? Theoretically, yes, um exact the exact implementation you use everyone does it slightly differently still so um But if you if you make your changes, uh using just a straight up, uh you boot uh script Absolutely, there's there's nothing wrong with that at all. That's completely ready. Uh, as far as overlaying a dtbo file You certainly can do it Bigel bone is a really good example of how that's uh, how that's done Or uh, yeah, and you know raspberry pi other people do similar kinds of things as well Uh, what else do we have here? Uh, can we have a live process after bootloader during The kernel and system boot for responding? Some systems inputs and bills and maybe right on the same buffer Uh, I think what you're asking is whether or not you can have two different things running at the same time uh Something running from u boot and the kernel booting at the same time In general, no, um in practice one can use There are various techniques on ways of splitting cores off to run different operating systems. So uh things like, um Perhaps not jailhouse, but but Uh, if you were to bring up let's say a hypervisor and starting the kernel and something else at the same time under a hypervisor being booted from you, but you could do that but Without involving other software. No, you cannot Like I said theoretically possible in practice Not just with kernel and u boot. There's other things involved to make that happen Can u boot interact with a tpm? I don't know the answer to that question. I'd have to look Um, uh at a guess I would say it probably could I'm not aware personally of of whether that's possible. There's uh, there are other people who are more uh They can probably answer that question better Uh, does u boot support secure secure boot? Uh, there are certainly aspects of u boot. Um, that that can that can build something like secure boot Uh, whether it supports exactly secure boot. I've personally never done it Again, there are other people who can better answer that question. Um, that's certainly you can do things that approximate u boot secure boot secure boot pardon me through checking signatures and such Does u boot support boot over pcie? Again, I don't know. Uh, the these are all starting to get in out of beginner range and into more advanced ranges. Um Uh, certainly I I'm aware of platforms where they have done that. Uh I I'm not sure whether it's it's directly directly supported Uh, generally speaking the way that works is is that the the boot monitor on the other side of of pcie tends to Put what you want into memory at the appropriate place and then you can read that from the u boot on the the platform you're on so Uh, certainly certainly there are aspects of that you can do but exactly how that works. I I haven't personally done Uh, I've heard that bearbox is way better than u boot. Can you explain why? So so matt I just want to ask which um, Which uh, text editor to use this this is very much Uh an emacs versus a vi thing. Uh A lot of a lot of the reasons that bearbox originally existed. Um Uh, u boot now does many of the same things. So it's it's really a an either or situation, but thank you very much for the question Remind me to ask a similar kind of question during your talk Uh Mohammed, uh, do you know about any industrial application where u boot has been added? Uh used as an artis although just as the boot loader u boot Has quite a lot of features like some open source artis Uh, u boot is not an artis. Uh, let's be very clear about this It is it it has never been and has never intended to be real time. Uh, it is a boot loader and a boot loader only Um, if somebody wants to use it in art as an artis There are far better options than than Of the u boot. I I I agree that it it appears to have many of the same qualities, but it is not an artis I would not bet the farm on that particular one. Uh, so, uh Could one do that? I worked for a company at one point who basically used it for the, um We we manufactured the entire platform from u boot and so all sorts of extra code Uh was scripted in there to make that all work from U boot and so we very much used it as the os during the manufacturing process to do what needed to be done Uh, but it really isn't a good fit for that. I wouldn't suggest it So no, I would suggest uh, not not doing that again. There's far better better options Um, any resource where I can learn how to customize u boot for custom boards Uh, I'm not sure what you mean by customize Do you mean porting the code so it runs on a particular board? Or do you mean changing the scripting so it it does the appropriate thing at boot time? Typically support for a particular soc is your starting point And then anything you need to do specifically for the hardware that's underneath you can do in scripting uh, so, um Resources really all the normal places the website the mailing list Um, and that sort of thing specific resources. Um, I can't think of any specific ones Can the bill will be programmed directly with mac os terminal? uh So This is specific to a particular dev board Um, none of the dev boards are specific to using linux as the as the host Uh connection wherever you want to run a a terminal server Program, uh, I use screen in the demos if you're on Uh windows, you could use a hypervisor or not hypervisor. Um hyper terminal or whatever is currently used now Um potty, I suppose But yeah, there's there's nothing you could From um from mac you can use screen you could use um Whatever I think there's a program called serial that you can get There's a lot of different options, but yeah You have to build these things on linux, but as far as accessing the serial port Um side of things. Yeah, you can do that from any operating system We just use the beagle board because it's what our hardware kits that we would have used in class would have been otherwise Had we all been uh physically present at this conference Uh, I like your setup for presenting the embedded Uh, what tools it's it's obs. It's straight up open broadcast system I've got a green screen behind me and uh, I don't know if I can show that No, I can't okay. I don't have that setup, but um Yeah, it's just a straight up stream deck. Um You know some some lights and and a green screen. It's and and obs. That's pretty much it Uh, can you boot verify images before loading them? I using signatures and keys. Uh, you certainly can do that. Yes, that is possible Uh Where are you reading the questions and comments? It seems like there is another chat window um No, I'm I'm looking at the the q and a uh, the q and a box. Uh, where everybody's Asking their questions. Uh, so yeah, it's not a chat. It's it's the q and a but I'm just reading the questions And then answering them a voice And that seems to be all of the questions I currently have in the q So if anybody has any other questions Uh, now's the time to ask them Okay Going once Going twice All right, I'd like to thank everyone very much for Uh, attending. I hope everybody enjoyed. Um, enjoyed the talk got some answers from things and uh, I uh, I hope that um, everyone has uh, fun playing with you boot and uh, getting you know, getting your projects working the way they want to and uh Um, remember that you can do most things from the scripting. You don't have to write c code for all these things I've seen far too many people try to uh Try to to script their boot up in c. You do not need to do that. Okay. Look at the scripts that are there You can do almost everything from the command line Anyway, thank you very much and um Uh, enjoy the next uh talk