WEBVTT 00:00.000 --> 00:10.800 Well, come everyone, thank you for being here. 00:10.800 --> 00:16.160 I make all of the knacker from root comets, you can read. 00:16.160 --> 00:25.440 Yes, so the target audience for this talk is for people who already have a bit of 00:25.440 --> 00:30.080 knowledge of Emily Linux, the wood process, but the device tree is, otherwise, yeah, it's 00:30.080 --> 00:34.960 going to be a bit complicated, a bit of a bit of Emily Linux systems. 00:34.960 --> 00:39.240 If you don't, you can pause the year at PDF if you're lucky to be remote or watching 00:39.240 --> 00:42.680 that a few years in the future. 00:42.680 --> 00:47.520 I'd be delighted to help you learn all this, if necessary, I'm a trainer too. 00:47.520 --> 00:52.360 And stay in the room if you are at first them because you can't go away anyway over this. 00:52.360 --> 00:58.160 This room is not as packed as I expected it to be. 00:58.160 --> 01:00.720 So why may I not support? 01:00.720 --> 01:06.160 I guess I don't have to convince you, but look at for example, think about 3S or Michael, I'm 01:06.160 --> 01:08.120 talking about this one. 01:08.120 --> 01:19.080 So look at it, as it's supported by ASUS, you have a 510 canal tree, a custom U-boot, which is 01:19.080 --> 01:24.120 slightly old, oops, to say the list. 01:24.120 --> 01:30.560 They are no kernel and yes, they do ship yuccto and that's why my custom actually chose 01:30.560 --> 01:31.560 it. 01:31.560 --> 01:37.560 But if you look at it carefully, it's an old, the custom, which is reaching end of life. 01:37.560 --> 01:44.960 Plus, don't have a look at the layout itself, it's some issues, yeah, so there are no kernel 01:44.960 --> 01:53.680 U-boot updates, obviously from those trees, yuccto is no longer supported since, oh yeah, 01:53.680 --> 02:00.320 actually since the 2024, where is that to the custom, yeah, I think so, anyway, it's 02:00.320 --> 02:08.800 reaching end of life, there was a repost trip to build the image, I mean, it's hard to 02:08.800 --> 02:15.760 digest, I would say, and even if you manage to build it manually, I mean, reading the 02:15.760 --> 02:21.760 script to see what I'm supposed to do, I don't want to run repo, eventually the script 02:21.760 --> 02:28.320 will the kernel well panic for some reason, it was supposed to run, but I don't want 02:28.320 --> 02:34.440 to know, I mean, I don't want to invest in the past, so we just let completely ignore 02:34.440 --> 02:38.240 that meta-layer and move on. 02:38.240 --> 02:45.840 Another example, which I've worked on for the same customer, they weren't interested in 02:45.840 --> 02:52.040 orange by 3b because it's like a better form factor compared to their previous design, 02:52.040 --> 03:02.200 there's a Linux 66 kernel tree downstream as well, and also U-boot 2210, quite old as well, 03:02.200 --> 03:08.080 but it's those are fixed again, if you look at the distribution support, it's orange 03:08.080 --> 03:16.800 by OS, which is based on Arch Linux, 5.10, I went with 22 to 22, or 4, with 6.6, 03:16.800 --> 03:22.920 debut on 12, 6.6 as well, Android and OpenWAT with all these based on 6.6, which is 03:22.920 --> 03:29.400 a bit old, and they offer a shell script to build some images, but I didn't manage to 03:29.400 --> 03:33.960 understand this script anyway, that's really not obvious how it works, so the main issues 03:33.960 --> 03:39.480 are, there's no kernel in U-boot-up dates, and the judge offering a shell script again, 03:39.480 --> 03:45.560 to build some images again, same philosophy, and there's no support at all for any proper 03:45.560 --> 03:52.160 build system, so a bit disappointing, so the first things to do, if you have a board of 03:52.160 --> 03:57.120 this kind, of course, is, yeah, try to work on it, like to get your hands on it and 03:57.120 --> 04:02.080 start with the perspective of making a main line, of course, so first, who can, and find 04:02.080 --> 04:09.680 a serial port for the board, my first customer didn't have it, like, had managed to work 04:09.680 --> 04:14.800 with the board without the serial port, which is brave, but better to have the serial 04:14.800 --> 04:20.120 port, find documentation for the board, of course, so that's to, again, check this for 04:20.120 --> 04:26.800 people who want to contribute a new board to the Linux kernel and other projects, so yeah, 04:26.800 --> 04:32.240 thanks to the documentation from the orange pi 3b, which is based on Roxip, as you 04:32.240 --> 04:37.280 have said, and there's a button to skip a spinole, and actually quite important, otherwise, 04:37.280 --> 04:41.200 there is something on spinole that the board will want to boot on first, so it will 04:41.200 --> 04:43.240 ignore my SD card otherwise. 04:43.240 --> 04:50.240 Find a reference image from the vendor, that's the only case where it can be useful, find 04:50.240 --> 04:57.440 a schematic if any, also created a dedicated note for your work on this board, consolidating 04:57.440 --> 05:02.800 all the resources you find, because you will come back to this repeatedly, but not, you 05:02.800 --> 05:07.920 will be interrupted by real work as well, so make sure you learn, you keep a note of the 05:07.920 --> 05:14.920 valuable things you learn, so how to work on main line in X, right? 05:15.880 --> 05:23.160 Chances are to get started that the main line Linux kernel will already boot on your 05:23.160 --> 05:32.200 board out of the box, actually, and well, you may have to write a device tree, but if other 05:32.200 --> 05:36.600 boards already with the same associated already boot on your board, that can work out of the 05:36.600 --> 05:40.520 box, and sometimes with the device tree from the other board, so that's a good sign, right? 05:40.520 --> 05:45.640 It's the good way to start, so yeah, just what a quick device tree with the right SOC, 05:45.640 --> 05:52.440 you are corresponding to the main serial port, and the debug port, I mean, and you should 05:52.440 --> 05:56.840 be good to go, don't hesitate, of course, to reuse stuff from other DTS files, you're not 05:56.840 --> 06:03.880 submitting to the Linux kernel, meaning at this point yet, so you can do whatever you want, 06:03.880 --> 06:07.640 and you can then start with a reference image, and you just replace the kernel, and then 06:07.640 --> 06:13.960 the device tree by your own, and that's fairly easy to do, so that's the default device tree 06:13.960 --> 06:21.480 for the orange pie RV2, which I worked on. Basically, it's just like enabling a console, 06:22.440 --> 06:27.960 depending, of course, the compatible strings I will go through this, and improving that a few 06:27.960 --> 06:35.640 things work, and you're good to go. Also, now we have something about that boot, 06:35.640 --> 06:41.480 a basic device tree, what should you do to share it with all our friends at first-end, for example, 06:41.480 --> 06:47.720 so before submitting a DTS for you board, you have to register a new binding for it, 06:47.720 --> 06:55.640 because otherwise the device tree checks will fail, so that's one, for K1, the K1 ship, 06:55.640 --> 07:02.920 like the orange pie RV2, based on the rest five, so just have to add your board to the list, 07:03.080 --> 07:13.960 basically. Then BYOD, which is not what you usually know, it's like bring, build your own 07:13.960 --> 07:21.160 device tree, and kernel, so of course, it's a cookbook, it's not like not rocket science, 07:21.160 --> 07:25.480 for many of you, but for people who are new, it's good to have this reference to do it by yourself. 07:25.880 --> 07:32.280 So, you clone the master branch of the linear tree, you go to the retro directory, you can 07:32.280 --> 07:37.800 you create your own device tree, at the right location, like in arch architecture boot, DTS, 07:37.800 --> 07:44.520 slash vendor, and it's always suck dashboard, the DTS, and then you also add this file to the 07:44.520 --> 07:51.000 make file so that it gets built when you run main DTS, and to compile your kernel now, you just 07:51.080 --> 07:57.800 don't have to fetch across compiler, just export LLVM to a, you call one, that you will build 07:57.800 --> 08:02.920 the kernel with K1, no cross compiler needed, you just have to set the target architecture and 08:02.920 --> 08:08.760 the make file of the kernel, we'll do the magic. You compile the device tree with make DTS, 08:10.280 --> 08:17.720 like we generated a device tree there, and compile the kernel, yeah, make my NOSJ number of CPUs, 08:18.040 --> 08:25.480 and ultimately you have arch architecture boot image, normally that's the binary that you can 08:26.520 --> 08:32.120 boot, right? So, if you're lucky, you're in the separate case when the kernel binary is 08:32.120 --> 08:36.680 readily available in the boot directory, in some boot partition, just replace the old one by the 08:36.680 --> 08:42.440 new one that you built and you're good to go, also of course copy the device tree, make it back up 08:42.520 --> 08:49.640 in case something goes wrong, and you're good, that should boot, in case it's, it's 08:49.640 --> 08:54.600 increasingly frequent now that you have, you don't have the kernel readily available, you have 08:54.600 --> 08:59.560 actually a 50-inch that contains the kernel and device tree and that's what you boot loads, 09:00.280 --> 09:06.920 in that case, it's fairly easy to replace the payloads inside there by your own. So, 09:07.880 --> 09:12.280 I'm showing you how to do it, so you've used this device a lot this week, I guess, but 09:13.000 --> 09:19.880 so you just use DTC actually to decompile the binary, which is it's still a piece of device tree, 09:20.600 --> 09:29.000 to back to a device tree source, like ITS, you add up with a file that has like a big binary 09:29.000 --> 09:34.120 parts inside, you just remove those lines and replace them with the equivalent, like sash 09:34.200 --> 09:40.280 ink bin and the name of the file you want to include, and you're good to go, and you will 09:40.280 --> 09:44.840 recompile this of course with MKMH from this file, and then you have a new one that you can use for 09:44.840 --> 09:52.520 booting, your new newly compiled kernel and DTCB. It's super easy to do, in case you don't have 09:52.520 --> 09:58.760 storage yet in your kernel, like the kernel doesn't support the storage yet, you can always boot 09:58.840 --> 10:04.280 on image runFS, so it's a piece of kernel that's loaded in run by the bootloader, or included 10:04.280 --> 10:10.920 in the kernel image, and yeah, it's easy to build one, easy one with busy box and efficient scripts. 10:11.960 --> 10:16.760 I did that in my presentation in the next one scratch, and I did the next one scratch actually, 10:18.200 --> 10:24.040 and if you also have network access, the kernel may already support it, if your device tree is 10:24.120 --> 10:31.960 right, you can boot on an FS server, so that the file system that you will use will be available 10:31.960 --> 10:36.920 over the network, and it's a directory on your development PC, essentially. They're easy to 10:36.920 --> 10:44.040 update and improve the file system like that. So I put some information, for example, for the 10:44.040 --> 10:51.240 banana type F3 board that I contributed to in the on the yokto site, you would explain how to 10:51.240 --> 10:59.560 set up an FS on your client and on your server. Now some board device tree coding that 10:59.560 --> 11:05.080 guidelines are learned the hard way, I'm not sure, I'm not sure, I'm gonna say the hard way, 11:05.080 --> 11:13.720 but because you could think I'm missing something that I'm not meaning. So yeah, you have 11:13.720 --> 11:18.760 some device tree coding style that's really well important to know and follow, like nodes of 11:18.760 --> 11:25.240 any bugs should be in the sending order, a sending address order, that's good, otherwise people will 11:25.240 --> 11:33.080 tell you. If there's no address, you order a phenomenon clearly by no name, the status property should 11:33.080 --> 11:37.880 become, come after the child nodes, before the child nodes, sorry, and a property of the same 11:37.880 --> 11:44.920 type, like the aliases should be numbered in natural order, like 1, 3, 12, 20, which is not the 11:44.920 --> 11:53.080 alfanymrak order, of course. And when you submit your first DTS for one board, submitted in one 11:53.080 --> 12:00.120 commit, don't say add, you are at PCI, add, isn't it? I'm somebody told me that and gift here, 12:00.120 --> 12:07.720 this gris, but, so there's one guy who you could disagree with, it's only that. 12:08.520 --> 12:13.160 Very important thing, before you submit an embarrass yourself in public, when make it 12:13.160 --> 12:20.200 a bit of course, followed by a bit main DTS check to validate your changes, you can run 12:20.200 --> 12:28.040 checkpatch.pl to on the modified files also, you have to verify your coding style and spaces 12:28.040 --> 12:32.440 and things like that. You will never feel embarrassed, I promise, if you run those, you can always 12:32.440 --> 12:38.280 say that those tools didn't tell you anything. Be careful, of course, make it to be check 12:38.280 --> 12:45.480 won't stop, won't stop, coding style issues. So checkpatch is important too. So on the 12:45.480 --> 12:51.720 importance of all this, you should have a look at this, this great presentation from Mr. K. 12:51.880 --> 12:58.440 Okay, it's tough, status of the three validation in Linux, Linux kernel, that was shown at 12:58.440 --> 13:05.400 plumbers. So great presentation, I'm grateful for Pristoff always being here to educate 13:05.400 --> 13:17.480 me and correct my mistakes. Okay, so right, good commit messages, it's very important as well. 13:18.440 --> 13:24.840 So this is a more guidelines from Kristoff and since we have Belgium, I put some character 13:24.840 --> 13:32.200 that we'll check, try to check run a checklist as well, is a Belgian policeman well known. 13:34.040 --> 13:39.800 So yeah, explain why you're doing something. Don't comment on the where the DTS coming from, 13:39.800 --> 13:46.360 I was told not to, like this is like this board and you have like also some style you can use for 13:46.680 --> 13:52.040 references. So general advice, it would be found on submitting patches that HTML in the current 13:52.040 --> 13:59.080 under documentation. Then sending and resounding, there are lots of things you need to know 13:59.080 --> 14:02.920 to get your changes accepted. So you didn't generate patches, you write a cover letter, 14:03.720 --> 14:07.880 you send it to write people, so you get the output of scripts, you can to maintain the 14:07.880 --> 14:13.720 PL, you receive, you should add the reviewed by and tested by announcements, track your submissions 14:13.800 --> 14:20.280 and all it's done is actually, well, that's quite tedious and that manually but then there's 14:20.280 --> 14:25.320 a tool to do that, which you know. By the way, know what it means when it becomes somebody 14:26.120 --> 14:34.040 asks you to, small and an equal V, so you have to do some dynamics, gymnastics, which is not so 14:34.040 --> 14:37.880 bad and look at the answer here. So it means please send a V too. 14:37.960 --> 14:47.800 Which I didn't know that jargon. So used before for this, for, I mean, do managing your patches 14:47.800 --> 14:54.440 in the right way. Before, for example, can fetch a patch, if you want to test a patch, before Shazam, 14:54.440 --> 15:04.520 message ID, and it fetches the patch series in your getery by magic. You can also pass the URL of a 15:04.600 --> 15:11.720 load to the kernel org, URL and you get the whole patch series in a branch in your local tree that's 15:11.720 --> 15:18.520 brilliant. So here's a workflow for doing that by yourself again, as I've said, using before. 15:18.520 --> 15:25.000 So check out the reference branch, the reference branch, like GPT master, or even create a new branch, 15:25.800 --> 15:31.480 with before, with before prep and the name of the branch, or you can enroll the existing branch, 15:31.480 --> 15:39.160 if you already made your commits. So get prep minus E reference branch. So in flat, you implement 15:39.160 --> 15:45.240 and commit your changes, that's your changes of course. You use before to create and edit the 15:45.240 --> 15:51.000 the cover letter, before prep, dash dash edit cover. Super easy. I used to do that manually with 15:51.000 --> 15:55.480 get branch, that dash dash edit the structure, but it is much more easy than that way. 15:56.360 --> 16:01.720 I prepared a list of recipients before prep, dash dash auto to CCC, so you don't have to mess up with 16:01.720 --> 16:07.000 scripts that will query, get maintainer, and put the right things, it's hard, actually. 16:07.720 --> 16:13.560 And then you can send the patches to yourself for your own review, a default send, with dash dash 16:13.560 --> 16:18.200 reflect, and then you have, you can send, you already send the patches to the lists with before send. 16:18.600 --> 16:27.880 So some experience sharing, be patient, your code may depend on other submissions, typically 16:27.880 --> 16:36.520 drive out dates, that was my case when I was working on a K1, a risk five. And when you're 16:36.520 --> 16:44.920 late in the RC series, we are now, so much code has been shared and in various trees that's 16:45.000 --> 16:49.400 really hard to know what is going to be in the next main line. And if you submit the patch, 16:49.400 --> 16:54.760 you have to share lots of dependencies that's tricky. So it's better to wait for the next 16:54.760 --> 16:59.560 hour see when this does my opinion, until you know for sure that what code has landed in main 16:59.560 --> 17:06.440 line and you have a stable base to share your patches about. I also promised to talk about main 17:06.440 --> 17:11.720 line you go it, but unfortunately I didn't have, I couldn't, I didn't have time much time to do 17:11.720 --> 17:18.200 to work on it and January was a crazy month. So the only thing I want to share here is 17:18.200 --> 17:24.680 let's trick I used on Spacemeat K1. So the board was typically booting on the, with the first 17:24.680 --> 17:32.360 age bootloader that was loading the bootloader in a 50-inch. So basically you boot, open SBI and 17:32.360 --> 17:39.160 you boot, UTV, DTV. And since there was no, on this board there's no, on this case, 17:39.880 --> 17:45.560 so see there's no MMC support yet at all, neither in boot in main line you boot nor in the 17:45.560 --> 17:53.320 current. So the idea was to piggyback this first stage in bootloader which is still from the 17:53.320 --> 17:59.720 vendor to load everything in RAM in one shot in a single 50-inch. So I was loading not only 17:59.720 --> 18:05.240 you boot, but also the links current and the current DTV which allowed me to load everything right 18:05.240 --> 18:10.120 so I was shot and then I could load the main line you boot kernel and the main line Linux kernel 18:11.400 --> 18:16.680 main line you boot of course you understood in one shot. That was nice. So I have a workflow now 18:17.480 --> 18:22.360 for K1 to be clear that boot, main line operation SBI, main line you boot and main line Linux. 18:23.720 --> 18:31.480 Even though it's imperfect but it's good start. Super projector, your toy is great to 18:31.480 --> 18:37.000 let people have a platform, generate images, without having to mess up with the architecture 18:37.000 --> 18:42.520 details like how you're supposed to be, to the out your flash storage, how you're supposed 18:42.520 --> 18:48.200 to generate the firmware. I mean that's not so interesting you may want to focus on the kernel 18:48.200 --> 18:55.560 or in your boot instead, right? So the priority of course is to have a full main line stack but at 18:55.560 --> 18:59.480 the beginning of course you may want to focus on main line Linux support because your boot is 18:59.560 --> 19:07.320 derived from main line Linux and so I mean with this perspective it's acceptable in your 19:07.320 --> 19:13.400 code for example to build something with the main line with the vendor kernel and firmware 19:15.400 --> 19:22.040 I mean the vendor huboot kernel maybe not but the vendor huboot at least and firmware is good to go 19:22.040 --> 19:28.840 this way you can work on the main line kernel at least. So here I'm sharing how to support 19:30.440 --> 19:35.800 a new board and in your talk quickly you have to specify the list of device trees that you want 19:35.800 --> 19:41.960 to put to store in your boot partition, the boot configuration file that's your boot machine and also 19:41.960 --> 19:50.600 the recipe that will build the kernel and the boot case file is a specification of the partitions 19:50.600 --> 19:56.520 for pretty straightforward so here's an example machine definition for orange by 3D based on 19:57.480 --> 20:02.840 I'm doing exactly what Nikola was asking the supporting the new board with here it's a 20:02.840 --> 20:11.240 rock chip 35566 board and yeah it just had to support all the device trees because there are two 20:11.240 --> 20:15.800 variants I'm supporting the two of them you boot will have to find out which revision I'm using 20:17.560 --> 20:24.280 and yes this is to build the kernel modules and this is the configuration I'm using the generic one 20:24.920 --> 20:32.360 for no I have one actually and the includes here specified the layout the layouts and a few 20:32.360 --> 20:36.840 few more settings because other boards of this type are already supported in meta-rock chip. 20:38.840 --> 20:45.560 So meta-rock chip is a great and clean example to imitate it's just wants to have as kernels that are 20:45.560 --> 20:54.040 in main line because they don't want to add a recipe for custom kernels like even a pullback 20:54.680 --> 20:59.800 meta-linux main line is not accepted they don't want to add a new dependency on the layer 21:01.240 --> 21:06.840 as a wrap up it's not very difficult to start contributing for support and you board 21:08.920 --> 21:13.000 you really it's it's it's like a game you start by imitating 21:13.320 --> 21:18.040 imitating we and use code for similar boards and plenty of them are there it's a good way to 21:18.040 --> 21:23.480 with experience it's really exciting and addictive like I was a bit drawn away from my projects 21:23.480 --> 21:29.480 in November and December when I was working on that I mean that's so exciting and at the end when 21:29.480 --> 21:34.280 the kernel is out you really feel like celebrating like in this picture there's a big celebration 21:34.280 --> 21:43.480 going on why not you in a room is my name because he took the photograph thanks and of course 21:43.560 --> 21:48.360 ultimately it allows you to get in touch with a small community of people with shared interests 21:48.360 --> 21:52.280 and that will become friends ultimately because you have the same balls and you meet them at first 21:52.280 --> 21:59.320 them and this could also open the door to career opportunities and it's easy like you just 21:59.320 --> 22:05.800 imitate you learn you don't have like to have the bar speed low and the fruit is hanging low 22:06.120 --> 22:13.080 so if you I hope I'm I'm at least to interest you so you if you have had a wire to support 22:13.080 --> 22:20.040 want to be commenting with future friends that's great if you're really new to this but you 22:20.040 --> 22:25.400 you want to start don't hesitate to copy me or even submit the code to me ahead of time what's best 22:25.400 --> 22:32.360 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 22:32.440 --> 22:38.920 review your code as well and there's also ways for me to learn more everyone as a reviewer you 22:38.920 --> 22:45.480 learn a lot as well but so that's the references to the slides I mean I haven't posted the slides 22:45.480 --> 22:52.280 yes but that's the location where there will be and I support this beautiful city of Minneapolis 22:53.400 --> 22:59.320 who is a it's trying to organize a next conference in a very hard and a tough time so those 22:59.320 --> 23:04.360 guys are great thank you