 లైటులు సురర్టిస్త్ధర్టివ్యో సుడిం మపుటవానూ హరన్నంవగానిక్్డోమిచారిం ఇరరోవాలి ఆబికోపెమేన్టికస్దావికన్ వా్యోటుడిక్సతా� I am Jagan, I am mostly working for Linux and maintain and forward boot and some few subsystems and I even work for Bill Dutronyakto. It is an agenda of this talk and the agenda is, I have described the agenda to start with the nutshell of view boot and keep on adding one by one and at the end I can detail explain what is the future plans and what are the mistakes we did. So the part 1 topic would be like a nutshell and the nutshell I can cover all the topics like a brief history and what exactly the view boot means and what was the source code, how you built from the sources and how the view boot has grown since from the birth to now and what are the boot sequences and what are the ideal tools for view boot right now using. Sorry, the history, it is a brief history like start from Vox and Dunks in about 10 years back and now it is moving to Tom Rainey as a master maintainer and now it is supporting all of the most of the architectures right now in our industry. And we have recent days of last month 2019.01, sorry it is not a mistake and we have a community like other open source community in the open source field and we very much follow the same strategy like we release every 2 months and out of the 2 months first 2 weeks will be a merge window for the new features and the rest of the period is for stabilization for fixes. So the same like any typical open source project like maintainers will send the peers and all the patches would be main line list. And this happened to be in the since from the last release and we have changed the release cycle to 3 months due to some request in the main list, now it is been changed to 3 months and 3 weeks merge window. These are the hardware support we supported till now and we have all of the most of the hardware or processors in the industry we supported even the RISC 5 in the recent U-boot versions. So we have many more developers and almost 10, 8, 3 different boards in the main line. So what exactly is the boot loader? What exactly is the U-boot means? Just say for example it is in the nutshell in the layman terminology a boot loader can be a first firmware loader after boot run and it will launch the Linux kernel or rainy applications. So that is a typical boot loader and in the starting when the process start U-boot results in something like a boot loader phase. Like there are some architectures from NXP, they directly boot the boot U-boot from the boot ROM. So the initial stage of the U-boot is something like this phase. Since it has been started there was information from the SOC loaders like individual SOC vendors from SOC like Xerings or free scale is coming with some kind of a SOC loader. They are not into open source at that time like that purely depends on a DDR configuration and along with some FPGA configuration those are not mainline yet are not been to any GPL license. So U-boot can taken care this part in 2014 or somewhere they come in with a solution called SPL. So the SOC loader can be upstream to U-boot. So the code of the SOC loader no part of the U-boot loader. So it can be terminalized as SPL like a secondary programmable loader. So in this stage U-boot can able to load all kind of a SOCs with different boot flows. And as U-boot has been growing further there was a there was an information like there was one more problem. It came up like SPL has some limitation since it's running from the SM. So SPL cannot fit all SOC related SM. So we came up with one more solution called as TPL. So if anybody wants less memory like K8K or less than 8K they should use TPL. And the boot flow is something like TPL and SPL and U-boot proper. So the year goes U-boot become U-boot proper. Though SOC loaders will become another stage boot loaders. This is normal build steps how to build a U-boot. And all the three different stages the boot loader source code is the same. The build system itself is changing a bit to build aspect to stages. And this is a typical U-boot tree. We just follow the same as Linux but with some kind of a commands for user interface. And as I told you like we have three stages of U-boot. And the build process starts with normal scripting. And it first it will boot the U-boot proper like in the left side there is 17 number. It starts with the U-boot proper. And the build step is moving towards SPL and it will build SPL images. And if the board supports other TPL it will build the next TPL images. This is a typical U-boot sequence from the power on reset. There was a global descriptor for the entire U-boot source code. Like what was the memory starting and memory ending. It is the framework for all the global details will be initiated in the initial stage. And it will look for initialization code like Bode on scoref. Where it is SPL or TPL or U-boot proper there are two different sequences. So if it is SPL or TPL it will allocate some memory and it will create some LED bug. And it will create a DDR memory. So the next stage boot loaders can use the same memory. But in case of this SPL the SPL will run from the SRAM. Now on the SPL you will find out whether it is U-boot proper or SPL. If it is find as SPL it will load boot mode device. Like if I boot from the NAND or MMC the respective NAND driver will load the respective images. So at the end SPL will find out there was one more stage called Falcon. I will describe in the later. If it is a Falcon it will boot the Linux directly. And if it is not Falcon it will identify whether I need to go for GD stage and whether I need to go for ATF or OPTI. Say for example U-boot proper. It will relocate the memory like since SPL is running from the SRAM while initiating DDR it will relocate by itself to the top of the memory so that the next image like Linux kernel can use the offset from the 32K. The U-boot proper sequence is something like a common sequence. That is why I have a init sequence underscore R where you can what are the configurations you enable in U-boot. All the configurations will be part of the sequence. And finally if it is auto boot it will boot Linux or it can come with U-boot shell. This is how the typical sequence. And we have a loading sources. Any kind of peripheral media source that can be useful here. And we have a simple debug printf and we have config dbeg and dlew. This is a llew debug information. It is very useful for porting the new hardware devices. These are typical tools that we are using in U-boot like a pathman for sending patches to the main list without concerning too much about what you are doing with a normal gate. And we have buildman like if you send a series of patches the buildman will build all the series with respect to all the architectures. And there was one more concept called packaging multiple images. Like I told you like three different stages of U-boot like U-boot proper at TPL and SPL. Each stage will create a different image. The buildman is useful to create one image from out of all three. This is how typical buildman look like. We need to specify the file output and some offsets. How it will load. This is a normal testing like we still use a travesy and test by a trace normal like anything. And the next part is image boot. First is a legacy boot like since from the U-boot starting we have booting the Z-image and U-image fields. But there is like it has a fixed offset and U-boot can it may have some U-boot format. So the problem with this image was like there is no flexibility and there is a problem with indexing and we cannot add some security features to the image. So there is no scope of the security addition. So we come up with the concept called fit flatten U-image and just like a buildman it will have a DT structure by specifying all the images. So in the images itself we can even specify the hash. So the single image can create while redundant for each and every security. This is how it is fit loaded. And we can even expand the fit complexity like we can even add multiple kernels and multiple DTVs and even the RAM disk. This is a special feature that works mostly in the servers and we can even add the bit file like FPGA so that it could be part of the single image and even we can add ATF for the ARM64 and we can add opt-in if anyone want to run from the trust zone and if any of the new image type you can add it. And the fit extension is a verified boot like how I can add a fit image with a security. It's like a software security. We need to create a public and private keys and the public key we need to go put it on some trusted source and private key could be part of the u-boot. So on the verification process we can decompress the public key and u-boot will verify the same thing. This is about in case of software security we need to pump the public key to u-boot DTS so that u-boot verification process will identify the public can create the hash and it will boot the proper hash if it is good or bad. And this is a real security like I have tried in the MS6 at the same stage but in case of u-boot DTS I need to flash into a fuse. So during the verification process I can compare the hash from the fuse and I can u-boot can validate the image. This is a pure security from your point of view and this is encryption. The main difference between the signed image versus encryption was like I need to create an image with a payload like if I have a u-boot image once I create an encryption it cannot become a normal u-boot it will have adding some assets by encrypting the image. Since IMAX comes with some kind of OTP during the decryption it will get the OTP and it will validate the security so the decryption process will allow in the u-boot like this. And the ATF stage this is what normal u-boot flow and we need to add ATF on top of the SPL During the ARM64 boot flow SPL will go to the ATF and ATF will run some SIM code and to move back to the u-boot proper. And this is the opti flow like I can add opti on top of SPL so even there are two different kind of use cases even we can load the opti after SPL and u-boot and even load before loading to Linux and we can load after u-boot proper and this is opti use case in the ARM v8 like I can load SPL, ATF and opti is normal and even I can load by combining this in case of ARM v8 as I said the Falcon boot there was a concept called Falcon where I can skip the u-boot completely and I can boot the Linux from SPL so this can be used case from boot time optimization or something so the skipping doesn't mean that you need to skip the u-boot we need to configure the Falcon in the first stage of u-boot so you need to go and drag run to u-boot and create the Falcon and the board next time will boot from SPL to Linux this is how we calculated boot time with respect to Falcon we ended up with half of the boot stage and in 2017 we added something like a u-face support since most of the accessories ARM v8 is coming with u-fi so u-boot come up with the v-fi boot by specifying some kind of u-fi image if you want to boot a BHD image u-boot can boot it from there directly there was a nice documentation about this if you want in one Lexis and there was a boot ops like how we can pass the command line arguments from the u-boot but the problem with the main boot ops like it's board specific we need to have a different kind of a language with respect to all the board configurations so we come up with a concept called a distro boot like a distribution boot by default so it can be default for all the distributions like we cannot take any board specific logic here this is how u-boot xt-linux 1.6 look like and the next phase like u-boot features the first one is a k-config and I will describe all the features that are built from the scratch to now so the first stage is the k-config at the u-boot starting point we didn't use the k-config so it was a normal build steps so in 2014 we ended up using the k-config look like a linux but since we have three different stages the k-config can be categorized into three different config files each config file for the each stage and we even add the ftt support like we can reuse the same dtb for u-boot since the same thing using from the linux so even we can specify the dtb and we can build the u-boot with dtb this is like a normal dtb flow and we have some specific use case for the dtb nodes like we always sync the dtbs from the linux if you want any dtbs or nodes properties with respect to u-boot it could be part of some u-boot.dtsi file this is how u-boot.dtsi file look like and there was a requirement from the linux I wanted to change the dtb node by moving to linux before I need to change something to some property disable becomes I need to do it like enable or something that in u-boot before going to linux by using lib ftt so I can grab the node and I can go to the node and traverse to the node and I can update the node if I wanted to update the node the problem with this is like we need to traverse the entire tree and there was a problem with the speed and we need to rebuild the sources again so we come up with the concept called live tree like instead of pointing to the offset I can pointing to the pointer to the particular node so I can directly go to the pointer to the node and I can update the dtb property this is how live tree look like this is a sample code for how we can write a live tree and we even add ftt overflows like overlays like there was a hats hardware on top of like raspberry price if the dtb on the particular board or hat is not in the mainland they are coming up with a concept called overlays so we even load the overlays by means of fit as a manual this is how we have a overlay dtb and this is how we can load the overlays dtb like the load address I can specify the code dtb file and the nest asht with the overlays dtb so it can take the overlays and it will boot the linux this is how we can boot the normal overlays in the manual manner the next concept I like like a driver model and this was introduced to make more features to the view boot I just keep track more the initial stage of view boot we have a drivers like calling the function calls from the board so they are not redundant they are ended up with we cannot use the multiple controllers with the same flow so we have a problem like direct function calls multiple there is no scalable and difficult to maintain so we ended up concept called driver model look like this each device has a hard device and along with the driver and there is u-class so say for example I have a spy flash I have a spy flash device from the dtb and I have a driver like if it is a controller driver it could be a gink controller and u-class is the core this is like a homogenous with respect to the linux device model the linux device model has something like we can have a device type bus type the very category is based on the device topology but here all the all the devices are homogenous like each and every device has a driver and u-class this is a simple modular but there are some issues with SPL if you want to use in SPL you need to bear some size the beauty of this driver model is the lazy initialization in case of bootloader you don't need to initialize everything like what linux does initialization whenever I need I can initialize it in u-boot console so this is a typical driver model we have all cpu driver models like if it is a cpu I wanted to get the information the u-class underscore cpu and if it is a ddr driver I have a u-class underscore ram and if it is a shared memory I have a driver concept called u-class underscore smm if it is mbox I have a u-class underscore mbox and if it is a RTC this is like how cpu driver model look like and this is a power driver models all the driver models will fashion something like this same like each and every driver we have a u-class driver with respect to controller drivers and there are some core core concept like a clock we set pin control all this categorizing into something like this so we have a generic pie driver and even pin control and we have peripherals like serial u-art spy flash and gpo and ethernet all the fit into the same category of the u-class flow this is how typical u-boo driver model look like I have written a driver like jink underscore q-spy it is a controller driver and this u-class driver is a core this is how we can pass the operations and we have one more layer like a Linux so the u-class can be parent to the other u-class and it can be child to the other u-class so here block is u-class and it is a child for u-class underscore mmc and we have u-class for block is SATA SCSI and NVMe this is how we can interact with u-class and this is a u-boot usb u-class framework we even handle peripherals and everything and we have since I told you like if you use FDT we can have a restriction for the size so you can skip the FDT by concept called off-and-score platform data this is something like a legacy Linux platform device I don't want to use a device tree but I can use driver-to-node by using this device installation this is how we can upgrade the u-boot firmware we can use a device firmware and we can use a fast-boot even UMS and if you want to port the new hardware we need some kind of prerequisites like setting up the size and we need to know what serial you are using and you can use this this is how we can port the new hardware we can concentrate on the respective config files as well as with DTS files there was a nice presentation on this in detail presentation in the ELC 2017 if anyone want you can refer and this is how u-boot look like with the three stage boot loaders first it starts TPL and return from the boot ROM it will start from the Linux and the MMC SPL and it will again go to the MNC and it will start u-boot proper this is how the typical future plans if anyone wanted to participate in these areas it can be easy and this is the conclusion and thank you any questions about x86 support we would be used as a holder in the parametral and virtual machines even we have x86 boards Maribaud and we have nfx86 even we have a acp support in x86 only if there is you and me you can also load u-boot as a ps in qaml it is there to define them when i want to put in typical device device sorry i didn't get you i didn't get your question you need to specify the device from where you want to boot like i told you in the FDT overlay you need to specify the core device and the hash and you can specify whatever device you want to boot it is up to you you can also specify the standard in the boot configuration thanks questions can you explain a little bit more about the upcoming future upcoming futures would be like we are in a stage of removing all the legacy drivers like moving towards driver model so that can be a future plan again i can say because since it was started driver model has been started almost 3 years back so we are we are we already place a margins like milestones for each and every driver subsistence to merge otherwise the respective board will be removed from the main line so our initial goal for starting phase 1 goal would be move all the driver models has to be include files to find yes that is also one more plan i just described on the k k config migration the config which are very annoying the config which are not for that you need to refer the config underscore white list the config which are not in the k config there have been listed in that config file more questions thanks