Well, come everyone, thank you for being here.
I make all of the knacker from root comets, you can read.
Yes, so the target audience for this talk is for people who already have a bit of
knowledge of Emily Linux, the wood process, but the device tree is, otherwise, yeah, it's
going to be a bit complicated, a bit of a bit of Emily Linux systems.
If you don't, you can pause the year at PDF if you're lucky to be remote or watching
that a few years in the future.
I'd be delighted to help you learn all this, if necessary, I'm a trainer too.
And stay in the room if you are at first them because you can't go away anyway over this.
This room is not as packed as I expected it to be.
So why may I not support?
I guess I don't have to convince you, but look at for example, think about 3S or Michael, I'm
talking about this one.
So look at it, as it's supported by ASUS, you have a 510 canal tree, a custom U-boot, which is
slightly old, oops, to say the list.
They are no kernel and yes, they do ship yuccto and that's why my custom actually chose
it.
But if you look at it carefully, it's an old, the custom, which is reaching end of life.
Plus, don't have a look at the layout itself, it's some issues, yeah, so there are no kernel
U-boot updates, obviously from those trees, yuccto is no longer supported since, oh yeah,
actually since the 2024, where is that to the custom, yeah, I think so, anyway, it's
reaching end of life, there was a repost trip to build the image, I mean, it's hard to
digest, I would say, and even if you manage to build it manually, I mean, reading the
script to see what I'm supposed to do, I don't want to run repo, eventually the script
will the kernel well panic for some reason, it was supposed to run, but I don't want
to know, I mean, I don't want to invest in the past, so we just let completely ignore
that meta-layer and move on.
Another example, which I've worked on for the same customer, they weren't interested in
orange by 3b because it's like a better form factor compared to their previous design,
there's a Linux 66 kernel tree downstream as well, and also U-boot 2210, quite old as well,
but it's those are fixed again, if you look at the distribution support, it's orange
by OS, which is based on Arch Linux, 5.10, I went with 22 to 22, or 4, with 6.6,
debut on 12, 6.6 as well, Android and OpenWAT with all these based on 6.6, which is
a bit old, and they offer a shell script to build some images, but I didn't manage to
understand this script anyway, that's really not obvious how it works, so the main issues
are, there's no kernel in U-boot-up dates, and the judge offering a shell script again,
to build some images again, same philosophy, and there's no support at all for any proper
build system, so a bit disappointing, so the first things to do, if you have a board of
this kind, of course, is, yeah, try to work on it, like to get your hands on it and
start with the perspective of making a main line, of course, so first, who can, and find
a serial port for the board, my first customer didn't have it, like, had managed to work
with the board without the serial port, which is brave, but better to have the serial
port, find documentation for the board, of course, so that's to, again, check this for
people who want to contribute a new board to the Linux kernel and other projects, so yeah,
thanks to the documentation from the orange pi 3b, which is based on Roxip, as you
have said, and there's a button to skip a spinole, and actually quite important, otherwise,
there is something on spinole that the board will want to boot on first, so it will
ignore my SD card otherwise.
Find a reference image from the vendor, that's the only case where it can be useful, find
a schematic if any, also created a dedicated note for your work on this board, consolidating
all the resources you find, because you will come back to this repeatedly, but not, you
will be interrupted by real work as well, so make sure you learn, you keep a note of the
valuable things you learn, so how to work on main line in X, right?
Chances are to get started that the main line Linux kernel will already boot on your
board out of the box, actually, and well, you may have to write a device tree, but if other
boards already with the same associated already boot on your board, that can work out of the
box, and sometimes with the device tree from the other board, so that's a good sign, right?
It's the good way to start, so yeah, just what a quick device tree with the right SOC,
you are corresponding to the main serial port, and the debug port, I mean, and you should
be good to go, don't hesitate, of course, to reuse stuff from other DTS files, you're not
submitting to the Linux kernel, meaning at this point yet, so you can do whatever you want,
and you can then start with a reference image, and you just replace the kernel, and then
the device tree by your own, and that's fairly easy to do, so that's the default device tree
for the orange pie RV2, which I worked on. Basically, it's just like enabling a console,
depending, of course, the compatible strings I will go through this, and improving that a few
things work, and you're good to go. Also, now we have something about that boot,
a basic device tree, what should you do to share it with all our friends at first-end, for example,
so before submitting a DTS for you board, you have to register a new binding for it,
because otherwise the device tree checks will fail, so that's one, for K1, the K1 ship,
like the orange pie RV2, based on the rest five, so just have to add your board to the list,
basically. Then BYOD, which is not what you usually know, it's like bring, build your own
device tree, and kernel, so of course, it's a cookbook, it's not like not rocket science,
for many of you, but for people who are new, it's good to have this reference to do it by yourself.
So, you clone the master branch of the linear tree, you go to the retro directory, you can
you create your own device tree, at the right location, like in arch architecture boot, DTS,
slash vendor, and it's always suck dashboard, the DTS, and then you also add this file to the
make file so that it gets built when you run main DTS, and to compile your kernel now, you just
don't have to fetch across compiler, just export LLVM to a, you call one, that you will build
the kernel with K1, no cross compiler needed, you just have to set the target architecture and
the make file of the kernel, we'll do the magic. You compile the device tree with make DTS,
like we generated a device tree there, and compile the kernel, yeah, make my NOSJ number of CPUs,
and ultimately you have arch architecture boot image, normally that's the binary that you can
boot, right? So, if you're lucky, you're in the separate case when the kernel binary is
readily available in the boot directory, in some boot partition, just replace the old one by the
new one that you built and you're good to go, also of course copy the device tree, make it back up
in case something goes wrong, and you're good, that should boot, in case it's, it's
increasingly frequent now that you have, you don't have the kernel readily available, you have
actually a 50-inch that contains the kernel and device tree and that's what you boot loads,
in that case, it's fairly easy to replace the payloads inside there by your own. So,
I'm showing you how to do it, so you've used this device a lot this week, I guess, but
so you just use DTC actually to decompile the binary, which is it's still a piece of device tree,
to back to a device tree source, like ITS, you add up with a file that has like a big binary
parts inside, you just remove those lines and replace them with the equivalent, like sash
ink bin and the name of the file you want to include, and you're good to go, and you will
recompile this of course with MKMH from this file, and then you have a new one that you can use for
booting, your new newly compiled kernel and DTCB. It's super easy to do, in case you don't have
storage yet in your kernel, like the kernel doesn't support the storage yet, you can always boot
on image runFS, so it's a piece of kernel that's loaded in run by the bootloader, or included
in the kernel image, and yeah, it's easy to build one, easy one with busy box and efficient scripts.
I did that in my presentation in the next one scratch, and I did the next one scratch actually,
and if you also have network access, the kernel may already support it, if your device tree is
right, you can boot on an FS server, so that the file system that you will use will be available
over the network, and it's a directory on your development PC, essentially. They're easy to
update and improve the file system like that. So I put some information, for example, for the
banana type F3 board that I contributed to in the on the yokto site, you would explain how to
set up an FS on your client and on your server. Now some board device tree coding that
guidelines are learned the hard way, I'm not sure, I'm not sure, I'm gonna say the hard way,
but because you could think I'm missing something that I'm not meaning. So yeah, you have
some device tree coding style that's really well important to know and follow, like nodes of
any bugs should be in the sending order, a sending address order, that's good, otherwise people will
tell you. If there's no address, you order a phenomenon clearly by no name, the status property should
become, come after the child nodes, before the child nodes, sorry, and a property of the same
type, like the aliases should be numbered in natural order, like 1, 3, 12, 20, which is not the
alfanymrak order, of course. And when you submit your first DTS for one board, submitted in one
commit, don't say add, you are at PCI, add, isn't it? I'm somebody told me that and gift here,
this gris, but, so there's one guy who you could disagree with, it's only that.
Very important thing, before you submit an embarrass yourself in public, when make it
a bit of course, followed by a bit main DTS check to validate your changes, you can run
checkpatch.pl to on the modified files also, you have to verify your coding style and spaces
and things like that. You will never feel embarrassed, I promise, if you run those, you can always
say that those tools didn't tell you anything. Be careful, of course, make it to be check
won't stop, won't stop, coding style issues. So checkpatch is important too. So on the
importance of all this, you should have a look at this, this great presentation from Mr. K.
Okay, it's tough, status of the three validation in Linux, Linux kernel, that was shown at
plumbers. So great presentation, I'm grateful for Pristoff always being here to educate
me and correct my mistakes. Okay, so right, good commit messages, it's very important as well.
So this is a more guidelines from Kristoff and since we have Belgium, I put some character
that we'll check, try to check run a checklist as well, is a Belgian policeman well known.
So yeah, explain why you're doing something. Don't comment on the where the DTS coming from,
I was told not to, like this is like this board and you have like also some style you can use for
references. So general advice, it would be found on submitting patches that HTML in the current
under documentation. Then sending and resounding, there are lots of things you need to know
to get your changes accepted. So you didn't generate patches, you write a cover letter,
you send it to write people, so you get the output of scripts, you can to maintain the
PL, you receive, you should add the reviewed by and tested by announcements, track your submissions
and all it's done is actually, well, that's quite tedious and that manually but then there's
a tool to do that, which you know. By the way, know what it means when it becomes somebody
asks you to, small and an equal V, so you have to do some dynamics, gymnastics, which is not so
bad and look at the answer here. So it means please send a V too.
Which I didn't know that jargon. So used before for this, for, I mean, do managing your patches
in the right way. Before, for example, can fetch a patch, if you want to test a patch, before Shazam,
message ID, and it fetches the patch series in your getery by magic. You can also pass the URL of a
load to the kernel org, URL and you get the whole patch series in a branch in your local tree that's
brilliant. So here's a workflow for doing that by yourself again, as I've said, using before.
So check out the reference branch, the reference branch, like GPT master, or even create a new branch,
with before, with before prep and the name of the branch, or you can enroll the existing branch,
if you already made your commits. So get prep minus E reference branch. So in flat, you implement
and commit your changes, that's your changes of course. You use before to create and edit the
the cover letter, before prep, dash dash edit cover. Super easy. I used to do that manually with
get branch, that dash dash edit the structure, but it is much more easy than that way.
I prepared a list of recipients before prep, dash dash auto to CCC, so you don't have to mess up with
scripts that will query, get maintainer, and put the right things, it's hard, actually.
And then you can send the patches to yourself for your own review, a default send, with dash dash
reflect, and then you have, you can send, you already send the patches to the lists with before send.
So some experience sharing, be patient, your code may depend on other submissions, typically
drive out dates, that was my case when I was working on a K1, a risk five. And when you're
late in the RC series, we are now, so much code has been shared and in various trees that's
really hard to know what is going to be in the next main line. And if you submit the patch,
you have to share lots of dependencies that's tricky. So it's better to wait for the next
hour see when this does my opinion, until you know for sure that what code has landed in main
line and you have a stable base to share your patches about. I also promised to talk about main
line you go it, but unfortunately I didn't have, I couldn't, I didn't have time much time to do
to work on it and January was a crazy month. So the only thing I want to share here is
let's trick I used on Spacemeat K1. So the board was typically booting on the, with the first
age bootloader that was loading the bootloader in a 50-inch. So basically you boot, open SBI and
you boot, UTV, DTV. And since there was no, on this board there's no, on this case,
so see there's no MMC support yet at all, neither in boot in main line you boot nor in the
current. So the idea was to piggyback this first stage in bootloader which is still from the
vendor to load everything in RAM in one shot in a single 50-inch. So I was loading not only
you boot, but also the links current and the current DTV which allowed me to load everything right
so I was shot and then I could load the main line you boot kernel and the main line Linux kernel
main line you boot of course you understood in one shot. That was nice. So I have a workflow now
for K1 to be clear that boot, main line operation SBI, main line you boot and main line Linux.
Even though it's imperfect but it's good start. Super projector, your toy is great to
let people have a platform, generate images, without having to mess up with the architecture
details like how you're supposed to be, to the out your flash storage, how you're supposed
to generate the firmware. I mean that's not so interesting you may want to focus on the kernel
or in your boot instead, right? So the priority of course is to have a full main line stack but at
the beginning of course you may want to focus on main line Linux support because your boot is
derived from main line Linux and so I mean with this perspective it's acceptable in your
code for example to build something with the main line with the vendor kernel and firmware
I mean the vendor huboot kernel maybe not but the vendor huboot at least and firmware is good to go
this way you can work on the main line kernel at least. So here I'm sharing how to support
a new board and in your talk quickly you have to specify the list of device trees that you want
to put to store in your boot partition, the boot configuration file that's your boot machine and also
the recipe that will build the kernel and the boot case file is a specification of the partitions
for pretty straightforward so here's an example machine definition for orange by 3D based on
I'm doing exactly what Nikola was asking the supporting the new board with here it's a
rock chip 35566 board and yeah it just had to support all the device trees because there are two
variants I'm supporting the two of them you boot will have to find out which revision I'm using
and yes this is to build the kernel modules and this is the configuration I'm using the generic one
for no I have one actually and the includes here specified the layout the layouts and a few
few more settings because other boards of this type are already supported in meta-rock chip.
So meta-rock chip is a great and clean example to imitate it's just wants to have as kernels that are
in main line because they don't want to add a recipe for custom kernels like even a pullback
meta-linux main line is not accepted they don't want to add a new dependency on the layer
as a wrap up it's not very difficult to start contributing for support and you board
you really it's it's it's like a game you start by imitating
imitating we and use code for similar boards and plenty of them are there it's a good way to
with experience it's really exciting and addictive like I was a bit drawn away from my projects
in November and December when I was working on that I mean that's so exciting and at the end when
the kernel is out you really feel like celebrating like in this picture there's a big celebration
going on why not you in a room is my name because he took the photograph thanks and of course
ultimately it allows you to get in touch with a small community of people with shared interests
and that will become friends ultimately because you have the same balls and you meet them at first
them and this could also open the door to career opportunities and it's easy like you just
imitate you learn you don't have like to have the bar speed low and the fruit is hanging low
so if you I hope I'm I'm at least to interest you so you if you have had a wire to support
want to be commenting with future friends that's great if you're really new to this but you
you want to start don't hesitate to copy me or even submit the code to me ahead of time what's best
best to use the the the many lists anyway so copy me and if I can if I have time I'll be happy to
review your code as well and there's also ways for me to learn more everyone as a reviewer you
learn a lot as well but so that's the references to the slides I mean I haven't posted the slides
yes but that's the location where there will be and I support this beautiful city of Minneapolis
who is a it's trying to organize a next conference in a very hard and a tough time so those
guys are great thank you