We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

barebox, the bootloader for Linux kernel developers

00:00

Formal Metadata

Title
barebox, the bootloader for Linux kernel developers
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Embedded doesn't mean we can't have nice things. As Linux kernel developers we have grown accustomed to the comfort afforded to us by Kconfig, device trees, the device-driver model, multi-platform kernel images, the kernel having sane defaults and virtual filesystems giving us shell-level access to debug and introspect the system. Why can't we have this in the boot environment? We can and you'll see how, welcome to barebox. What began as a rejected patchset for adding Kconfig to U-Boot has now been a full-fledged bootloader in its own right for 13 years. barebox is powering millions of devices around the world. In his talk, Marco will give a brief overview of barebox from a kernel developer's point of view and show how easy it is to add support for a new i.MX8M board. The attendees will see barebox in action and learn how to leverage the VFS for hardware bringup, kernel debugging and booting the system in production.
BootingBootingSoftware developerKernel (computing)Software developerComputer animation
Lie groupKernel (computing)WhiteboardPatch (Unix)BuildingRootMeta elementDevice driverData modelComputer configurationLogarithmCompilerSoftware testingSoftware frameworkField programmable gate arrayDevice driverDecision theoryBootingMechanism designWhiteboardAxiom of choiceMultiplication signSoftware frameworkMeta elementCodeLatent heatCASE <Informatik>Complete metric spaceNetwork topologyConfiguration spaceEndliche ModelltheorieTheory of relativityKernel (computing)Menu (computing)Computer architectureAdaptive behaviorSource codeBlock (periodic table)Keyboard shortcutRevision controlSinc functionFunctional (mathematics)EmailLine (geometry)Core dumpPatch (Unix)Graph (mathematics)Electronic mailing list
Computer-generated imagerySystem on a chipEmailWhiteboardStructural loadBootingData modelDynamic random-access memoryRead-only memoryCodeCompilation albumDynamic random-access memoryOverlay-NetzBootingPoint (geometry)Network topologyFunctional (mathematics)Medical imagingCodeWhiteboardDevice driverBlock (periodic table)MereologyLatent heatMechanism designStructural loadScripting languageAddress spaceKernel (computing)Computer fileBinary codeSoftwareLevel (video gaming)Multiplication signSingle-precision floating-point formatRobotPersonal identification numberFirmwareBootingConnectivity (graph theory)Different (Kate Ryan album)DDR SDRAMStatic random-access memoryEmailElectronic visual displayUltraviolet photoelectron spectroscopy
WhiteboardComplete metric spaceLink (knot theory)VirtualizationEmulationGastropod shellPhysical systemEmulatorBootingKernel (computing)MereologyFile systemSemiconductor memoryRight angleComputer animationLecture/Conference
MultiplicationFormal languageConfiguration spaceWhiteboardComputer animation
Scripting languageConfiguration space
Wide area networkIRIS-TLink (knot theory)Configuration spaceWhiteboardType theoryFerry CorstenKernel (computing)Visual systemSource code
Infinite conjugacy class propertyMaxima and minimaInternational Date LineGamma functionFormal grammarLibrary (computing)Lie groupIntrusion detection systemView (database)
Execution unitMedical imagingBinary space partitioningConfiguration space
Chi-squared distributionComputer-assisted translationMedical imagingPlastikkarteFlash memoryRule of inferenceLimit (category theory)WhiteboardComputer architecture
Finite element methodMultiplication signGoodness of fitScripting languageIntegrated development environmentText editorWeb 2.0Computer animation
Video game consoleBoom (sailing)BootingDirectory serviceWhiteboardPatch (Unix)Line (geometry)Multiplication signComplete metric spaceDisk read-and-write headComputer animation
Program flowchart
Transcript: English(auto-generated)
So, hi everyone, welcome to my talk, welcome to Barebox and first of all, can all of you raise your hands, who ever heard of Barebox? Or, okay, that's quite some. And to use
it actually in some projects. Okay, that's more than I thought. Okay, as I thought, I'm Marco, I'm from Pentatonix, I'm an embedded software developer. Yeah, my thoughts are related to kernel, to bootloader, to BSP stuff, graphic stuff and so on, so on. Most of the time,
I contribute my work to upstream, sometimes not. I'm living in the north of Germany. Yeah, and that's it. And the agenda is just a brief introduction to Barebox who is not becoming familiar with. And then let's add a new driver, so an example. Then add a new
board, so you can see how you can add your own board and upstream it to Barebox because we always welcome new boards. And then we make a short hands-on, hopefully we have some time for it. And yeah, okay. Then welcome to Barebox. Barebox started in the
year 2007 as a patchlet of Ubuntu and the patchlet was called Ubuntu 3.2. This patchlet was retracted and then yeah, Sasha renamed it and yeah, made an official fork of it
in 2009. We have monthly releases, we have mainline support in PDX list and we want to have mainline support in Yocto and open embedded core. I sent patches just yesterday.
You can find the link below or in the slides. Please, any discussion is welcome. And if it's not getting into open embedded core, yeah, you can pull it from meta PDX or meta Barebox. And okay, yeah, we have 330 contributors around and yeah, it sounds not that much but
we are living, Barebox is living, we have around 1,400 commits per year and okay, the graph is not that optimal. It would be wise all the time but yeah, 1,400 it's not that bad.
And we are live. So let's add a new driver. And what are our design decisions in Barebox? We are coming from Linux or we don't want to re-run the wheel the third time or the 10th time.
So we are taking the Linux device driver model and stripping it down to a bootloader use case. All the configuration is done via device tree since day one, since we get forked. And yeah,
device tree and kconfig, some of it, most of it device tree. And we also, since we reuse the Linux device driver model, we also reuse the driver frameworks. We just strip it down to meet our requirements and then push it and it's mostly just in copy and paste
with small adaptions. And so then let's add a new driver. As I said, it's in copy and paste, copy it from the Linux source, copy it to the Barebox source and then adapt the code. So how does it look? And some example, I took the clock from some block chip and I made a diff. You can
see the diff above. It's Linux 6.1 or 6.2 I thought. So it's 6.2 RC blah, blah. And yeah, just adapt the headers because, okay, of course, Barebox does not have all those
headers and replace them with some Barebox headers and then replace some functions we do not support. That's not very important. It's just replace some functions, remove it or replace it. Yeah. So we adapted the driver. We are finally done. So we have ported our new clock
driver for this rock chip. So we have changed 50 lines of code for a driver of size about 171 lines of code. This makes about 1% or 2% of adapted code and we ported the driver to Barebox
to a bootloader. Most of the time when you port the driver, clock drivers are a bit specific but some drivers do IRQ. In Barebox we don't have IRQs so you need to port it to some
polling mechanism but we have helpers for that. So we are welcome you to port your driver or your driver of choice you need into a bootloader. So then after we ported the driver we need to compile it. So let's add the kconfig in the makefile because we are kind of related bootloader. So let's add a kconfig menu entry and at the makefile. It looks like a kernel. So
then we are finally done. We need to enable it, we need to compile it and we have everything. And of course we can test it with what? With the Linux device tree because we are device tree
based and since we are using the complete driver from Linux we also have to complete bindings from Linux. So we can use the upstream Linux device tree, you don't have to do anything just copy and paste. So yeah, feels like writing a kernel driver isn't it? To me at least. So to sum
up this a bit, the barebox drivers are just a stripped down Linux version driver. And drivers can be ported with little effort. There may be some more effort if you have more complex drivers or if you port frameworks. But by frameworks that really depends. There are
some really easy frameworks and there are some frameworks which are huge. So I added some examples which frameworks we already support. A very decent one is the NetDSA. I think some of
you know the DSA stuff. This distributed architecture for switches. I think it's called distributed switch architecture anyway. And we support it in barebox because we are using the NetDSA framework from Linux. So we can do NetDSA with my bootloader. So you can speak with your
switch like you do in Linux. So that's very impressive for a bootloader. And yeah. Then let's move on. We have added our driver. Let's move on and add a new board. Before we can add a new board I wanted to explain you some stuff. Some internals of
barebox I don't want to go into details because we don't have that much time. If we have more time at the end I will show some more examples. And yeah of course you can raise your hand if you have questions in the end. Anyway we have a single binary in barebox
which you flash to the target. But this is composed of several components. One of it is the sock header. This is really yeah. One of it is the sock header. Then we have this pre-bootloader. Then we have some firmware blocks like device tree like yeah third-party firmware blocks.
TFA or ATF or DDR firmware. Yeah depends. Depends on your sock also. And then we have the actual bootloader. So as you can see there is a singleton image but it is composed of
different firmwares or different blocks. In barebox we do this composing for the pre-bootloader and for the firmware and for the actual bootloader we do link it together and the sock header is appended. So yeah also the sock header is very sock specific
and this appending mechanism depends on this image creation tool which is also sock specific. So then also some booting stuff need to be known before you can add the board.
And most or most modern socks booting from a bootworm. So you plug in the check and then the bootworm comes up. The bootworm loads some stuff from yeah the boot medium you configured via some GPIOs or some pins and then it's loading the yeah some kilobytes into some
static ram and then it jumps to the static ram and then executes the pre-bootloader and then the bootloader and the bootloader finally the kernel. So now look into Deeper and it's a new bot. So as I said the bootworm is loading this sock header. It's decoding this sock
header. It's really sock specific and it's executing the software which was loaded from the boot medium. Then the pre-bootloader gets loaded by the bootworm and set up the DRAM and then it's loading the real bootloader to the DRAM after it set it up the DRAM
and then it jumps to the actual bootloader or if you have some more decent socks like army 8 based socks then it's jumping to the TFA and the TFA is jumping to the bootloader which we previously loaded to the DRAM. So okay now we know it and now we add the pre-bootloader
stuff. These pre-bootloader stuff don't have any support of device tree or so. It's a kind of low level stuff. It's kind of dirty stuff. Anyway in barebox everything starts
at the entry function. The entry function is always the first point where it starts and okay let's add a IMX8MNEVK with this entry function. We have some helper functions after we load it into the SRAM and then we are calling the NXP. This is some bot specific code which we get here
and this set up the UART. So we have pre-bootloader low level debug stuff and then as the function calls start ATF. This function setups the DDR as I said. It loads the
barebox to the DRAM or DDR and starts the TFA and the TFA is then jumping into the loaded image or into the given image into the image which we loaded previously at the specific address we told TFA. And after we loaded this we get started by this last function and that's the
actually barebox entry function. And here you can see the pre-bootloader is passing the device tree. So the pre-bootloader also loaded the device tree and is passing the device tree
finally to barebox. So barebox is just running with the device tree. So now let's coming to the barebox to the bootloader. This is the stuff where all the metric happens where all your board specific fix ups does happen like you have some overlays
for some displays you have different displays do some detection and then apply device tree overlays so your device tree is finally finished finally fixed up for the kernel and the kernel don't have to do anything. This can such stuff can happen in the board code and yeah
such a board code is also a driver in barebox and after the board code finished to load everything and do all the magic it jumps to the kernel. So as you can see here this is the
entry function for a board code again this looks again for me to a kernel like a kernel driver you have some driver struct where you can put all the functions and you have this compatible which is also checked and then depending on the compatible which is given the driver is loaded
or executed or not and then you have the board function and within the board function you do this magic stuff I told you do detect where to come from do some matching stuff and
set up this is some kind of special in barebox we have some barebox updates handler this is some kind of yeah you know this magic in the rail submarine where you can have some
scripts to load something from mmc to some metric addresses and here are metric addresses and here are metric addresses and there are involved five commands or so in barebox we have the barebox update command and this is the handler for it we just forget the handler and in barebox we can just call barebox update and finished so there is just one command
involved and yeah then finally this board code is fixing up the file and then it yeah finished and starting the kernel and the kernel is do all the remaining stuff so that's not part of my talk
and yeah okay so we have added a driver we have added a new board and everything apart the pre-bootloader stuff feels like a kernel to me so I hope I can make you a bit excited
about and you can visit the link this is barebox hosted online on the tiny emu emulator yeah just click on it and you can try it out uh yeah what else barebox barebox says now it's
coming to the improved part barebox has a rich shell with auto completion the shell has history this shell supports scripting and so on this shell is also colored what you would see when you visit the link what do we have also we do also have virtual file systems this means
no more uh commands and offsets like you know from ruble it's just copy a to b it's like unix it's like linux so we have ls we have rm we have auto mount you you know auto mount
from system d where you visit some directory and magic happens and it gets mounted automatically we also do have that in our bootloader and we also have memory mapped io access so we can visit or we can check the memory we can manipulate manipulate the memory
via md via memory right so mb and yeah as i said earlier we have this barebox update command which is pretty amazing because it's hiding all the ugly stuff it's just barebox update and
you are done and also pretty amazing in barebox we have multi-image support it's some language of barebox it's something you are compiling barebox and then with one compile with one def config we can build 100 or more boards and this is
something i wanted to show you right now with an hands-on so now it's i hope everything works as expected so yes uh is it readable or should i increase the size okay okay so
it's just a small script i wrote uh it does nothing just it applies make def config then
it enters the def config so i can show you something about barebox so it's like again it's like a linux kernel and here you can see system types and here you can see all the boards we have enabled so all the boards not just one board
and okay exit yeah everything is fine and then it's calling make compile so okay that's nothing fancy here about the fancy stuff starts at the end
let that happen and hopefully so okay now we are at the end we are finished compiling all the stuff and now
we are building our images and we are building around one as i said we are building around 100 images right now with one command with one def config and that's pretty amazing because i i know how some or i know bsp is where you have just two different uboot configs to have
one uboot for an sd card and one uboot for an emmc or one uboot for a spy and one uboot for an sd that's that's not the kind we are working we're saying one image rule all them
so uh and then also you compile it and you can select as many boards as you want as soon or yeah it has some limitation the sock must be the same so we all the architecture so this was yet imx seven sorry imx four seven so all imx six and so on and
and now we can see uh cat uh so now okay
flash images so we have built 132 images just in one minute
and that's not doable with uboot at least with my knowledge i can't do it with uboot and yeah of course then as i said we have this oh if it would work uh yeah we have this
online barebox and then we also have an editor we have also vi but vi is not that good working
within the web but we have also added and then we can edit some stuff like going here and hitting blah blah or haha anyway uh as you could have seen the script and good first time it's nothing special it's just a script which checks some environment
and then that's what uh that's it i wrote it just uh yeah half an hour ago
and then we can handle this and see okay global first time ref is not set and then we can say okay since we have history we can move up and i didn't edit
then we say global first time oh nope also auto completion so global first time
and then we say hello for stem 20 yeah 23 and yeah that was a short head on
it's pretty amazing barebox i really i really would like it to see you if you have contributed barebox if you send patches if you bring your board's main line and yeah let us enjoy barebox