 Hello everyone, it's nice to see all of you here Some of you were on the previous talk and those of you who were then Will probably better understand what I will say. My name is Łukasz. I work at Samsuk R&D Institute Poland Today I would like to share with you an idea we've got in my team. We decided to replace a Bootloader on one of our development platforms with Linux kernel and the handful of user land tools this by no means is something new we we did it because others did it before us and Here on FOSDM. I have already seen at least two talks about it So but we've got our approach which I would like to share with you We think there are several good reasons to do that one of them us being a little bit lazy as Probably some of you here too And liking others to help us do our job We want to avoid double effort that is required to develop the to bring up a new platform because Code for both Linux kernel and the bootloader needs to be developed to get a functional platform And there is we think there is no need to to do to create code for both Linux and bootloader Because the talk is rather short. I and I really don't want to miss the ending I will do my best to tell you everything I've got and Then I will answer your questions This presentation has got two two parts Unlike what's on the screen the first describes more or less the current state of publicly available bootloaders on Arm Cortex a CPUs Angelo said a lot more about that The second is about our work How we think it is possible to improve the situation For those who are unfamiliar with The topic on arm. There is no standard firmware Like bios or UEFI on x86. That is why it is a bootloader's job to Configure most important hardware components Let me ask how many of you have touched a bootloader code or an architecture dependent Linux code That runs before start come a kernel function just like Okay, we're on the same page That's nice In this maybe some of you are more clever than I am In this presentation I assume the booting process comprises the following Stages the firmware is a piece of this is what others called RBL RBL this is a piece of immutable code that comes With a CPU it cannot be changed by any means then there is a bootloader aka SPL divided into several stages and then the of course there is an OS the code that Implements the application the device was designed for like desktop environmental multimedia system or Choose yours An additional task bootloader sometimes perform is an OS update especially when the OS is broken This means a bootloader should be very robust As it may be the only way to unbreek a device We concluded that the available bootloaders for arm have so significant Drawbacks and we need to improve upon that the following the experience of the Linux boot project We decided to use Linux as a bootloader These are the three most common Bootloaders I could find for arm each of them support different architectures to There is a lot more proprietary commercial custom ones Until now in our work We have used to you boot on most development platforms and some custom bootloaders on on products Every new platform needs a bootloader to be ported to it, you know, we build a PCB you Smash an SOC onto it to boot it you you need a bootloader Just to repeat. I mean all the code from that is loaded by from rom And that runs until Linux kicks in so that's what I consider a bootloader Porting a bootloader to a new platform Requires writing platform setup code Which will configure a Which will configure the platform to be usable it turns on DRAM some clocks some some Voltage set some voltages on board Some basic peripherals like console Then there is a general purpose code Which deals with loading OS kernel from a storage or from a network and starting it in In addition in traditional bootloaders the range of options here in this area is somewhat limited For on the other hand for Linux there are tons of device drivers dozens of file systems and More than one network stuck to and Thanks to Kexec Linux can act as a bootloader And start completely new kernel load it from wherever you want and Started as a new system This is a droid xu4 it is based on Exynos 5422 SOC and it has been a reference platform for Tizen OS for the past couple of years and almost everyone in our office has one in their drawer. That's why That's why we chose it for for this proof-of-concept It's well supported in the mainline Linux and we knew that if it doesn't boot Then it is our fault. We're doing something wrong It wasn't entirely true, but that's not the point Now we we fixed like probably two bugs somewhere in the compressor Code that nobody looks into it works and we did something different and it appeared Fixed was needed There have been a number of similar attempts to push Linux as close to to hardware as possible Mostly on xx86 platforms and as I as I learned today on risk 5 2 We work with ARM platform and thus our approach is slightly different Please do keep in mind also that this was kind of a side project and We focused on getting the most important functionality available and We're not bothered by any convenience feature too much Okay, the boot on Android looks as follows there are three blobs provided by the vendor which is hard kernel and They are flashed with a special with a With appropriate script they are flashed on to SD or emmc card So so the board can boot BL1 does the very basic platform setup Which is turning on DRAM and reads BL2 BL2 loads trust zone and and an unsigned U-boot image Trust zone Blob appears to be doing nothing because there are a lot of null bytes so We don't have source code source code for it. It doesn't do anything. I think No, it doesn't behave wrong. We we don't have any problems with it. Let's stay with that All three blobs need to these three blobs need to be signed A hard kernel signs Trust zone handler and BL2 upon request on their forum But this is a little bit cumbersome to change them. So we decided we will replace U-boot just you but no we we didn't replace any any of these There is however as you might see There is the name of the last the last no the BL2 Suggest the largest hurdle we faced that is one megabyte limit on the on the U-boot image we had to We had to fit within that limit after a quick recap We found these four tasks were essential essential to boot the boot the board With Linux kernel as a bootloader Platform setup as I said this was rather quick The BL1 and BL2 code does all of the setup except for console We did console with a small. I don't know 50 60 bytes Shim That's that's easy one megabyte is very very little for a kernel device tree and the Reasonable reasonable whatever that means user land after my disabling more almost everything in kernel what we could our that image took like 950 kilobytes so we we were left with 50 or 60 kilobytes for for the user land part For the record Without struck such Such strict limit we would build a separate bootloading kernel Anyway with different configuration than than the one we used for for the OS so Two kernels is are always we think required maybe not Maybe the first one could not could be not that much limited Linux Luckily K luckily K exec worked However, we had recently some other boards which had some problems with with K exec It appears to be the problem with drivers of some devices that don't shut down Devices properly and when a new kernel starts drivers try to probe devices The devices are in states that cannot be handled at the probing stage by By the drivers, so this this will need investigation Although we weren't much into providing user land tools Just a few bits to to load the kernel started we found the you root Used in linux boot for example To be a very nice piece of software for that much better than In our opinion much better than other such toolboxes Alas, it doesn't support K exec on arm. We had to use K exec tools and and But that's just a minor problem Thanks to TMP FS Which unlike old style RAM disk is able to expand In RAM as new data is saved. We could split our init ram FS archive into two the first stage Comprises only a tiny in it we call half in its half stage in it Which mounts fat partition unboxed stage to archive or stage one full archive Execute slash in it that is expected to be in the archive and replace this HSE need There is no limit for the stage to archive except of course the size of RAM Size and speed of storage and such things Eurot short for universal route Is is a really nice piece of software. I'd like to recommend you if you build Bootloading environments, it is a set of basic tools. There is a shell text editor LS cut and You know stuff that you find in all the boxes out there But unlike other boxes it is written in go It can be deployed in two modes source and busy box mode the former is need because the only binary that is On on the init ram FS is a is go compiler and Every tool that you use is compiled on demand Unfortunately, it requires much more space and Rather strong CPU on arm. It was too slow to to build the commands The busy box mode is a single binary with multiple sim links Calling multiple functions at the moment What we've got we can configure the kernel to build an Image for a selected board in our case it is xu4 To boot without you boot and start another fully fledged kernel Although xu4 cannot act as a USB device To use Linux on other our boards We need to develop function FS base tool to receive files To to to receive and Download to to the flash we also need to make kexec tool in your root work on arm Why you may ask? From our perspective there are following Advantage advantages to this approach Let's effort during platform bring up Because we avoid code duplication this Extends also to maintenance you don't end up with I don't know for example PMIC driver into Repositories in linux kernel where you need it for power management and in bootloader where you needed to to bring up the platform Linux More flexibility linux both the kernel and the user land is much more capable and flexible than than bootloaders available to areas we we consider crucial our network support and security Although it is possible to boot over a network today only TFTP is available for file transfer, which is perfectly fine from a client perspective However without an authentication. It is not a protocol. I would deploy it outside any local network support for crypto libraries is very new and quite limited as far as I can tell And finally from our experience The general purpose code like file systems like network stock like I don't know USB stuck not not the driver for for the for the hardware, but the rest of the stock Is somewhat is somewhat in better shape in in the linux kernel and is Maintained More regular that that is our experience In summary the the key features of our approach of what we did We are definitely arm-centric because that's the platform we work with We assume however it that it applies directly to other platforms, which don't employ standards-based firmware Like BIOS or you like BIOS or UEFI our motivation to push lean push linux as close to the hardware as possible Is a little different than on x86? We're not concerned. We're not concerned much about security like management engine on 86 that affect platforms user But rather we want to help vendors ourselves included to minimize the effort To prepare To bring up the platform to avoid the the unnecessary effort to prepare two versions of device drivers and Keep file systems up-to-date and so on and so on Our goal is to find a place and means in the linux kernel source tree To keep platform board dependent code, which can which can do platform set up before the kernel starts and can be And can be built together with the kernel to form a single binary that The firmware the the rhombus loader can can load Alternatively signed the SPL although this might look like we try to resurrect the board files. We don't the platform specific code that we need Is it's not the same as us the the board files that were used before Device tree became popular the code needs to Bring up only several components Which are not access which are not controlled later on with With this in place Porting linux would require less effort a less amount of work and you get really really powerful boot environment These are the guys that helped me a lot by either providing knowledge or allowing me to work on this as a site project and special things go to Mateusz who wrote the the the small in it the HS in it and Squeezed it really hard to to fit in the limit Okay, I managed somehow are there any question I Guess it's more. Oh, it's loud. I guess it's more common than a question, but I guess the question comes along First of I think it's an amazing idea to use linux as your driver toolkit because then you only write your drivers once right Doing those in you boot and in linux at the same time as a terrible idea either way simply because we You always get this typical fork effect where you have diverging drivers for like sooner or later the biggest your IC is Your how to put this The platform unit code is something that the arm world was really proud of to finally get rid of I Don't see us reinventing that and we're reintroducing it in a 64 bit arm world. It just is not going to happen We need to find a different way to get this tiny platform unit code in between your Basically your BL2 and the the actual inox kernel and this is why I really would like to brainstorm with you on Cool ideas we can do I think we have a couple of things on the plate of what is possible to create a tiny shim that Runs before linux so that you don't have to put platform code into in into the linux kernel itself and the tree itself I'm very sorry, but there was something I Could you come and? Quick repeat me the question without the mic about the mic the platform unit code you're putting into Before the linux kernel, so is it actually separate standalone float? It's a single file, but it's in linux in the source tree. Yes. I think we need to work on Okay, the question the question was Is the shim we you we prepend to linux kernel inside the carnal tree? Yes, we want to be it inside the carnal tree and I haven't mentioned that I have posted patches RFC patches to to the list and they are Available for commenting so it's it's not like we want to push something we want to discuss it But because linux kernel that the source tree can become a single a single stop shop for for vendors for people to boot You know code that boots That's we definitely open for discussion Okay, it appears I finished Yeah So I thank you too