barebox, the bootloader for Linux kernel developers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| 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 | 10.5446/61796 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
BootingBootingSoftware developerKernel (computing)Software developerComputer animation
00:37
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
07:51
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
15:05
WhiteboardComplete metric spaceLink (knot theory)VirtualizationEmulationGastropod shellPhysical systemEmulatorBootingKernel (computing)MereologyFile systemSemiconductor memoryRight angleComputer animationLecture/Conference
16:52
MultiplicationFormal languageConfiguration spaceWhiteboardComputer animation
17:44
Scripting languageConfiguration space
18:04
Wide area networkIRIS-TLink (knot theory)Configuration spaceWhiteboardType theoryFerry CorstenKernel (computing)Visual systemSource code
18:29
Infinite conjugacy class propertyMaxima and minimaInternational Date LineGamma functionFormal grammarLibrary (computing)Lie groupIntrusion detection systemView (database)
18:50
Execution unitMedical imagingBinary space partitioningConfiguration space
19:21
Chi-squared distributionComputer-assisted translationMedical imagingPlastikkarteFlash memoryRule of inferenceLimit (category theory)WhiteboardComputer architecture
21:03
Finite element methodMultiplication signGoodness of fitScripting languageIntegrated development environmentText editorWeb 2.0Computer animation
22:00
Video game consoleBoom (sailing)BootingDirectory serviceWhiteboardPatch (Unix)Line (geometry)Multiplication signComplete metric spaceDisk read-and-write headComputer animation
23:15
Program flowchart
Transcript: English(auto-generated)
00:09
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
00:25
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,
00:47
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
01:07
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
01:27
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
01:44
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.
02:02
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
02:27
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.
02:49
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.
03:04
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,
03:20
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
03:42
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
04:04
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
04:21
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
04:46
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
05:02
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
05:21
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
05:50
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
06:01
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
06:25
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
06:47
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
07:02
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
07:25
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
07:46
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
08:06
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.
08:25
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
08:41
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
09:03
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.
09:22
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
09:42
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
10:00
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
10:25
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
10:47
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
11:03
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
11:28
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
11:43
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
12:10
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
12:24
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
12:42
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
13:07
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
13:22
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
13:47
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
14:05
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
14:21
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
14:47
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
15:04
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
15:23
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
15:44
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
16:06
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
16:23
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
16:44
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
17:03
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
17:26
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
18:00
it's just a small script i wrote uh it does nothing just it applies make def config then
18:08
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
18:26
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
18:42
let that happen and hopefully so okay now we are at the end we are finished compiling all the stuff and now
19:02
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
19:27
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
19:41
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
20:06
and now we can see uh cat uh so now okay
20:33
flash images so we have built 132 images just in one minute
20:46
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
21:12
online barebox and then we also have an editor we have also vi but vi is not that good working
21:21
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
21:51
and then that's what uh that's it i wrote it just uh yeah half an hour ago
22:00
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
22:25
then we say global first time oh nope also auto completion so global first time
22:47
and then we say hello for stem 20 yeah 23 and yeah that was a short head on
23:00
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