WEBVTT 00:00.000 --> 00:21.340 Okay, so welcome, this is a talk about orange pi boards, or is 5 boards, like this one, 00:21.340 --> 00:28.000 this is orange pi RV2, this is orange pi R2s, pretty small, I will introduce them in detail 00:28.000 --> 00:29.000 anyway. 00:29.000 --> 00:37.680 So, I make a little bit of a self-employed consulting consultant, working for a company called 00:37.680 --> 00:46.120 RUKAMIT, and yes, I am an engineer and trainer at the same time, doing cool things, 00:46.120 --> 00:51.760 like working on a Yoto project, like helping customers to bring up their projects, 00:51.760 --> 00:57.480 and also working on the Linux kernel, and also optimised your embedded Linux systems, right? 00:58.160 --> 01:04.000 Plus, I have training courses with three materials, as well, on the handset to have a look, 01:04.000 --> 01:09.960 especially the Yoto course is the most advanced one, this also a common course, and some 01:09.960 --> 01:12.760 embedded Linux training materials, right? 01:12.760 --> 01:19.720 So, in instruction here, the goals of this presentation is to contribute to making 01:19.960 --> 01:21.960 a more popular, right? 01:21.960 --> 01:28.480 Like, it's trying to bring my own contribution, and this targets in particular support in 01:28.480 --> 01:37.640 me, Linux, Yoot, and Yoto, and so here the focus is on the orange pi R2s pi boards, more 01:37.640 --> 01:45.200 specifically, knowing that Marcel gave a great presentation about the other boards, like 01:45.440 --> 01:52.760 very wide area of boards, which it's hard to keep up collecting like he does, right? 01:52.760 --> 01:57.400 So, let's see how the progress that's done so far, and show you that you can contribute. 01:57.400 --> 02:04.320 There are still lots of things you can do at this stage, at the boards first, so you 02:04.320 --> 02:11.240 have orange pi R2, which drew for the first thing you told me about, like, when I was 02:11.240 --> 02:15.040 at embedded recipes, the recipes as he has a nice conference. 02:15.040 --> 02:21.920 So, basically, when it's a K1 core from SpaceMids, it cores actually, and it has like 02:21.920 --> 02:28.560 two gigabits, Ethernet ports, quite nice, also, I've been compared to Raspberry Pi, you 02:28.560 --> 02:35.160 have like two PCIe ports as well, like you can collect, connect PCIe Express devices, or 02:35.160 --> 02:39.720 especially SSD drives, so that's really nice. 02:39.720 --> 02:44.400 It exists in several versions, like two gigabits, four gigabits, eight gigabits, and when 02:44.400 --> 02:53.400 I ordered it, like in late September, October, it cost only 50 or 54 euros, and unfortunately 02:53.400 --> 03:02.000 now it's like more than double, so really annoyed by that, it's terrible, now it's 120, 03:02.000 --> 03:06.240 so pretty bad, but the board itself is great. 03:06.240 --> 03:10.360 It was hard to find the two gigabyte version, like for people who want to contribute without 03:10.360 --> 03:17.920 paying the too much rank around cost to the AI companies. 03:17.920 --> 03:24.960 So, yeah, questions, how many do you have the R2 board, yeah, more? 03:24.960 --> 03:31.960 Oh, nice, R4, yeah, R2, right, yeah, orange pi R2, how many would like 03:31.960 --> 03:35.040 to buy it, given the price? 03:35.040 --> 03:44.680 Yeah, if you can afford it, how many are waiting for K3, the one with RV32, to 23, right, that 03:44.680 --> 03:49.960 would be nice, so hopefully there will be an orange pi R1 as well, because they're nice 03:49.960 --> 03:56.280 design boards with like an attractive size, I mean those ones don't take that much size 03:56.360 --> 04:03.720 on your desktop, compared to the big, like Jupiter 5, or even better than a 5, is like 04:03.720 --> 04:09.240 rather big on my desktop, which I limited space. 04:09.240 --> 04:14.840 Yeah, the other one from the range, this range is orange pi R2s, also same processor, very 04:14.840 --> 04:22.400 close, and this one is interesting in the sense, it's really nice and relatively cheap, 04:22.400 --> 04:29.440 like switch for, for any networking activity, right, like it has not only the two one 04:29.440 --> 04:36.720 gigabits, it's a night port, but also the two to the five gigabits ones, for a price 04:36.720 --> 04:42.560 that was like, and bitable, like 32 euros, for two gigabytes of RAM, which was more than 04:42.560 --> 04:47.440 enough like two to run network, and that's why devices are to run open, and open the 04:47.440 --> 04:55.040 URT. So that was nice, now it's the price has increased again, like almost 150% 04:55.840 --> 05:03.920 unfortunately. So yeah, here here is what it looks like, unfortunately, it doesn't have any 05:03.920 --> 05:08.720 Wi-Fi, which would have been nice for something you want to use, that maybe has an access point 05:09.040 --> 05:15.200 in your office at home, like I was thinking about using it for filtering, for connecting on my 05:17.360 --> 05:22.640 internet, I mean, IoT objects in my home, which I have like a proprietary firmware, 05:22.640 --> 05:29.200 which could be exploited as chatbot, as bots maybe sometimes, if they are compromised, 05:29.200 --> 05:37.040 so I want to give those guys very little bandwidth and run very strict filtering rules 05:37.040 --> 05:41.520 against what they are traffic. That would be nice candidate for running my own software, 05:41.520 --> 05:47.280 without having to do an expensive equipment. Well, if I would be nice for this, but you can 05:47.280 --> 05:52.240 you could always attach one if you want through a small dongle on USB, that would work. 05:53.120 --> 05:58.720 And everything I'm missing is MMCSD for easy booting. They claim they have a TF card interface, 05:58.720 --> 06:06.080 but I got no clue of how to use it, because this very strange connector here, 06:08.000 --> 06:14.000 and didn't manage to find any accessory to use it, so it's like a SD card, but with a really 06:14.000 --> 06:21.440 proprietary connector, unfortunately. Another bad thing is that there are no schematics, I asked 06:21.440 --> 06:28.240 multiple times, but you know they are Chinese, so even if you've threatened them to increase tariffs 06:28.800 --> 06:35.760 like from the European Union, like sanctions, they don't care. The Americans, right? 06:36.640 --> 06:41.840 And another problem with those is that PCI Express is there on the board, of course, but it's 06:41.840 --> 06:52.240 used for powering the two gigabytes, even at the board, but it's not available any other way, 06:52.240 --> 07:00.720 which is a bit sad. I guess it's a price, let's compromise I guess, right? So how many have this one? 07:02.720 --> 07:10.000 Oh yeah, okay, one. Yeah, it's not as well advertised as the other one, but it's pretty nice. 07:11.680 --> 07:20.720 How many will you like to buy it, maybe? So where to buy? That's the question. You can follow the 07:20.800 --> 07:26.240 links on the product pages, I'm sharing. Unfortunately, there's no retailer outside of China. 07:28.400 --> 07:35.120 Yeah, you have to buy from the AliExpress store. You, well, they have a namazon link, but like 07:35.120 --> 07:43.200 it's either slow, expensive compared to a Xpress, and they are evil anyway. I mean, the master platform. 07:44.240 --> 07:50.000 So yeah, you need to go through AliExpress, let the links, they share to do that, so I recommend 07:50.080 --> 07:58.720 the store from the maker itself, which is called Shen Zhen Zhang Long, right? And it's reliable, 07:58.720 --> 08:04.400 I've done it multiple times. Yeah, you can trust them. Though you won't get a rarely clean 08:04.400 --> 08:11.280 invoice for your accounting goods, it's like some screenshot of the, it's not a proper invoice, 08:11.280 --> 08:17.920 but yeah, okay. I would advise to be aware of the other sellers on AliExpress, because they 08:18.000 --> 08:23.920 like sometimes like have suspicious low, suspiciously low prices, and sometimes I try it for a 08:23.920 --> 08:30.240 banana pie to get one through another supplier, and ultimately the other was canceled, 08:30.240 --> 08:36.320 because they accepted the other, but they had no stock. So I had to wait for AliExpress to 08:36.320 --> 08:42.480 realize that the other had never be shipped to be to re-refend it. Never mind, so be careful with those. 08:43.440 --> 08:50.000 Now let's talk about the vendor support for those boards, so both are supported through 08:50.000 --> 08:56.160 their orange pie, GitHub repositories, that were created at a time they shipped the created boards. 08:57.040 --> 09:06.000 So it's Linux66 and Ubweets2210, not very exciting, and especially as if you look at the latest 09:06.080 --> 09:12.080 commits, it's exactly when they release the board, and it's like shoot and scoot, right? Yeah, 09:12.800 --> 09:19.680 you just run away after releasing something, you lose interest, and you do go on doing something else. 09:19.680 --> 09:24.800 So that's typically typical event, how do we have under software repository, right? 09:25.520 --> 09:31.840 If you look at the OS images, you have opened the value RT, orange pie OS, which is open harmony, 09:32.480 --> 09:40.720 only for the RV2, Bob, and Ubweets22404. So, well, it's still a list, as far as Ubweets2210, 09:40.720 --> 09:46.160 you still have dates from Ubweets2, but who wants a device without a kernel of dates? 09:46.160 --> 09:53.120 Well, and maybe even dates at all, like, I don't know about Ubweets, the WRT and things like that, 09:53.120 --> 09:57.840 so, you know, who wants that? That's why, of course, you are here, and we are interested in 09:57.840 --> 10:02.880 community solutions, of course. So, the hardware itself without software is worth not much, 10:04.640 --> 10:11.440 except if you said it too, because the RAM is expensive. So, my landing efforts now, 10:11.440 --> 10:17.520 that have been done. So, if you look only at the device three, there's been little, 10:18.160 --> 10:24.080 like on the board themselves, right, like the DTS for the board. So, there's one for the R2, 10:24.080 --> 10:31.360 for orange pie RV2. There was initial work from Hendrik, Hamling, to support, like UART, 10:31.360 --> 10:38.480 and a few LEDs, and I added 188 and PDA, and PMDA support, PDA support, just imitating what was done on 10:38.480 --> 10:43.760 banning pie. So, that was not rocket science, that was pretty easy. And similarly, for orange pie, 10:43.760 --> 10:52.560 R2S, I just, like, guessed what the correct, correct device three would be, I tried it and it 10:52.560 --> 10:57.440 worked and it seemed to make sense. So, yeah, I just posted it and it got accepted. So, but was 10:57.440 --> 11:04.800 relatively easy to do. But, this being said, there's a lot of ground work being done by contributors, 11:04.800 --> 11:11.280 especially people from SpaceMet, actually, there's a lot of ongoing work to make a better support 11:11.280 --> 11:16.640 for the SOCs. So, yeah, I mean, we are not alone, and they are doing a great work, 11:16.640 --> 11:20.880 that appears on other boards that are similar as well. So, yeah, we can reuse that stuff, 11:21.760 --> 11:30.000 especially in the in the in the 620 kernel that's coming on 620 RC1 that's coming like in two weeks. 11:31.840 --> 11:40.640 So, yeah, let's share some status. What's already available and what's remained to be built. 11:40.640 --> 11:45.920 So, in mainline, for R2, you have the UART that's there, infinite, DPA, ULA, LEDs, 11:46.880 --> 11:53.680 high square C works, 80, 80, 24 E-prom works. So, it's just that I package it with like, 11:53.680 --> 12:01.840 I posted it together with the some patches that were trying to enable MMCSD, like the one, 12:01.840 --> 12:07.600 the thing that doesn't work yet. And so, that part got didn't go anywhere and then I didn't 12:07.600 --> 12:12.400 repost the high square C ones, but high square C works thanks to the mainline drivers. 12:13.360 --> 12:18.640 We should also pretty close with PCI Express, that was merged. So, yeah, that's the work. 12:19.600 --> 12:28.160 And for Wi-Fi and Bluetooth, it actually worked. It's been some guy, Alperac, actually made it work with 12:28.160 --> 12:37.360 the developer kernel, like, I mean, that's just an external AP62, 506 chips. So, that's standard, 12:37.360 --> 12:43.760 and we have, like, external modules for firmware to make it work. That should work. 12:44.880 --> 12:53.280 MMC, as an optional module, right? So, Marcel said it worked and I confirm actually did it works. 12:53.280 --> 12:57.760 The question is just how, how do you share that? Like, you have to write a device free 12:57.760 --> 13:04.400 for the board with the MMC. Well, yeah, the MMC or not, because it's the module, Dubai and plugin. 13:05.360 --> 13:12.160 USB2 and 3 seem to be like, like, the two work as well, because of the recent contributions. 13:12.160 --> 13:18.320 What's going to be harder is MMCSD, because, as Marcel explained, the controller is used, 13:18.320 --> 13:21.760 the thing controller is used, but in a different configuration. So, you have to figure out how to 13:21.760 --> 13:29.040 really properly make it work. I did actually make it work in red only mode, but then the kernel, 13:29.040 --> 13:34.880 like, I could detect the partitions on the MMSD card, but it didn't work in red mode. Like, 13:34.880 --> 13:42.320 if I cats, I mean, I copied the contents of the storage that the block device that I was seeing 13:42.320 --> 13:48.720 into slide-down slash null, it just died. So, something weird, like, with interrupts. So, yeah, 13:48.720 --> 13:53.760 with somebody, some people need to, we need help to, for people to have a look at that 13:53.760 --> 14:00.480 part and see how to make it work. Maybe learning from the vendor kernels, that's because it 14:00.480 --> 14:06.640 works on that side. For orange by R2S, like the networking device, what you have you 14:06.640 --> 14:12.560 work, one gigabyte, Ethernet, MMC, that works, MMC works. And on the way to mainland, you have 14:12.560 --> 14:17.600 ice class C as well, and the EPROM for storing the Mac address, that's part 2. And we should be 14:17.600 --> 14:22.960 pretty close for PCA Express, so that would be a fantastic device for testing, like, the super 14:22.960 --> 14:30.080 high speed Ethernet, and USB 2 and 3 should be close as well. I'm already using USB 2, 14:30.080 --> 14:40.080 actually, but like, from the bootloader side, to boot it. So, what's in line for 620? 14:41.120 --> 14:45.920 RM does, as I also said, as well, are accepted a bunch of commits. I mean, in the, in the, is 14:46.640 --> 14:53.200 sok tree. So, that, that's very likely to be accepted by Linux, in during the 620 much window. 14:53.920 --> 14:59.040 So, that's a nice base, like, I mean, the list is much longer than the way I'm sharing here. 14:59.040 --> 15:03.120 So, yeah, that's, that's a great news. We have lots of activity on the driver side. 15:04.240 --> 15:07.840 So, to support the ball, we should have, like, most things that we need. 15:08.560 --> 15:12.640 So, how you can help? That's the main thing. There's quite a lot of flow hanging fruit, 15:12.720 --> 15:15.760 like, for you guys, there's an opportunity to get involved. So, that's nice. 15:16.400 --> 15:23.120 So, I would advise you to wait for Linux 20, 620 RC1, to, like, to have some patches that are 15:23.120 --> 15:31.040 based on some solid, solid, base code code base. Otherwise, you don't want to collect patches 15:31.040 --> 15:35.760 here, and then just wait for RC1 to be ready, and then, you know, you have all those features 15:35.760 --> 15:41.040 enabled, and everybody understands what your patches are based on, right? 15:42.000 --> 15:46.160 To be fun to implement, we've lots of new features that are missing. So, just look at 15:47.120 --> 15:52.240 the missing parts, try to implement, just play with that, it's fun, I promise. 15:52.240 --> 15:57.680 If, just, like, adding one piece after the other and contributing, it's really fun, and we're 15:57.680 --> 16:00.800 willing. So, yeah, it was busy in December, working on that. 16:02.560 --> 16:10.560 Please, also help with supporting MMPCSD, right? But, yeah, it doesn't work yet at all. So, there's 16:10.640 --> 16:19.200 a conversation that, when people studied the mathematics and the data sheets and came up with, 16:19.200 --> 16:24.000 like, the realization that that was a different configuration, and so, people started 16:25.600 --> 16:31.040 saying that we will have a look, but nothing has emerged yet. And once you have a patch, 16:31.040 --> 16:38.240 it's super easy to do with, you can use the B4 tool, really nice to prepare and send your patches 16:38.240 --> 16:42.640 to the mailing list and manage the iterations as well. Like, if you have reviews, 16:42.640 --> 16:48.320 they will automatically be added by B4. That's really brilliant. It really helps you to comply with 16:48.320 --> 16:56.080 the kernel way of managing your submissions. It's not only for a maintenance, but also for 16:56.080 --> 17:03.520 contributors. And, yes, talking about, like, the went to start. So, I would say, the 15th of February, 17:03.520 --> 17:11.680 when the 20, 620 RC1 is scheduled to be released. In case you don't know, there's a nice 17:11.680 --> 17:16.160 calendar. You can use, you can import as a shared network calendar. Just use it, add it, and 17:16.160 --> 17:21.040 to your calendar application, and you get the dates for the module window and the final releases 17:21.920 --> 17:29.120 as predicted, pretty accurate for, like, probably one year. I didn't see how long it went, 17:29.200 --> 17:38.000 but that's funny. Talking about Huboot now, there's not much done yet, and functionally, 17:38.720 --> 17:44.560 I did boot the board with the banner Nepi and the head of config that exists. 17:45.280 --> 17:51.440 I guess I should create one dedicated one for the two boards, but maybe it would be worth creating 17:51.440 --> 17:57.520 a generic K1 configuration that would work for all boards in the same way. Or, if we want to support 17:57.520 --> 18:03.600 specific boards, yes, we could do like one board per board, but when, when, definitely, 18:03.600 --> 18:09.680 five per board, I don't know. So, there's no support for MMCSD, either in the new wood, of course. 18:09.680 --> 18:12.640 So, but the focus should be the next, let's make it work. So, on the next, and then we, 18:13.200 --> 18:20.080 we backport kind of, we port the driver from the next two to the boot. So, the next is not 18:20.080 --> 18:28.240 this from RAM, by the vendor Huboot SPL so far. I will show you how we can do that. And ultimately, 18:28.880 --> 18:33.360 what would be nice to, is to add some logic to detect the amount of RAM in each model. 18:34.240 --> 18:38.640 This way, we don't have to create separate device trees for, like, two gigabytes, four gigabytes, 18:38.640 --> 18:46.080 eight gigabytes. So, there should be a bit of logic to do that. For orange by R2S, I haven't tried it yet 18:46.080 --> 18:52.800 to use my 90 boot, but I'm close, like I had a very hectic amount for January. So, in that case, 18:52.800 --> 18:57.360 like a conference event, I mean, conference driven development didn't work much for me, 18:58.080 --> 19:04.240 because of a lot of project work. So, yeah, so, you, my 90 boot will work, I'm fairly sure. 19:05.760 --> 19:13.680 We should port the, the same driver to, I mean, the SDHCI driver to, to boot from, 19:13.920 --> 19:21.840 EMMC, and then this one works in Linux, should, should work on Ubital as well. That should be doable. 19:23.040 --> 19:28.320 And similarly, yes, I'm loading Linux from from RAM, from the vendor Huboot SPL. 19:30.880 --> 19:36.160 The next question effectively is the Huboot SPL, the first-stage boot order. Daniel, 19:36.160 --> 19:42.480 who was here, maybe still here? No, he left. Daniel, my first key, who didn't implement the K1 DRAM training, 19:42.560 --> 19:49.200 as we discussed, like, in Marcel's talk. So, there should be a way to stop, depending on the vendor code, 19:49.200 --> 19:54.080 yes, for, for that part, that they're perhaps still used the vendor code. So, according to Marcel, 19:54.080 --> 20:00.000 it's just like something really counterintuitive for you guys. Like, it's, it's transforming 20:00.000 --> 20:04.960 rest code and putting it to seed. But if somebody does that, like, to seek out for Uboot, 20:04.960 --> 20:09.760 that would be great, because that, that would allow us to do without the vendor code, what would be nice. 20:10.640 --> 20:18.320 Also, you may test, help to test the Uboot SPL patches that were published earlier this month, 20:18.320 --> 20:24.800 as Marcel said. So, there's the series of commits that bring more support to K1, not only, 20:24.800 --> 20:30.320 like, if SPL, I think, but also, I guess, other parts. So, that's interesting. 20:32.240 --> 20:38.000 Yeah, so, the next thing about this work from Marcel is, like, he works on, you, he works on 20:38.000 --> 20:45.920 Uboot, that's core boot without C, meaning in rest, of course. So, you take up the C, 20:45.920 --> 20:53.040 so, you have rest inside. Oh, yes. So, a trick I did to, to boot the, the board, that allowed me 20:53.040 --> 20:59.040 to boot mainline, uh, so, Bandoet from, firstly, but other, yes. But mainline, open SBI, mainline, 20:59.040 --> 21:05.440 new boot, mainline, Linux. The trick was, I had no MNC, but I could load everything from RAM, 21:06.000 --> 21:11.040 a two RAM, from the first stage boot of the, normally, the way the first stage boot of the works, 21:11.040 --> 21:16.480 is load, it's loading a 50-inch containing Uboot, open SBI, and the Uboot DTB, 21:17.280 --> 21:23.760 two RAM. The, the, the, the easy trick was to modify here the 50-inch to contain the Linux kernel, 21:23.760 --> 21:29.040 and it's DTB, and possibly even a small in-tram FS. Well, I'm using an FS, actually. So, that's 21:29.120 --> 21:35.280 no in-tram FS, but you load, uh, all this bunch to RAM, uh, taking advantage of the FS, 21:35.280 --> 21:39.120 the first stage boot load that does. So, loading everything to RAM, and then, when you, 21:39.120 --> 21:43.760 I new boot is a, to load, to load the kernel from where it was loaded in RAM. 21:44.720 --> 21:50.160 So, that's a nice trick. And when you have a similar board, that doesn't have support for storage yet, 21:50.160 --> 21:56.800 but there's some code that can load, you boot, uh, to, to RAM. Well, you could use it to load 21:56.880 --> 22:02.320 the Linux kernel to RAM as well. That's the nice thing. Uh, how, unfortunately, that was limited 22:02.320 --> 22:08.400 to 64 megabytes in my experiments. So, I, I couldn't go really beyond, including the kernel, 22:08.400 --> 22:14.400 the DTB, and the various small in-tram FS. Otherwise, I would, I've gone bigger. 22:17.120 --> 22:23.360 And then the last part is Yoko support. Yoko is useful, because it makes it easy to build images, 22:23.440 --> 22:29.920 without having to, uh, relieve, uh, worry about, like, how the, uh, that's specific. So, see, 22:29.920 --> 22:34.640 it's supposed to boot, and what the partitions, the expects on the storage. So, that's actually 22:34.640 --> 22:39.920 nice to be, to have like a nice builder, pretty bold builder that allows you to build any image 22:39.920 --> 22:46.320 from a given, uh, a given board, right? So, I, I believe, uh, and that's what I did, like, supporting, 22:46.320 --> 22:52.160 uh, do those bots in Yoko should help people get, uh, contribute, because they can easily build 22:52.320 --> 22:56.960 some images that can, they can modify, they can regenerate with a new kernel, new main 22:56.960 --> 23:01.760 length kernel, new YouTube boot. Though, it's still possible to hack the, uh, a ready-made images 23:01.760 --> 23:07.440 from, um, Ubuntu, for example, like, that are shipped by the vendor, just to replace the kernel 23:07.440 --> 23:13.200 they ship by your kernel, your custom bait kernel. That's not so complicated anyway. Just to replace 23:13.200 --> 23:19.600 the kernel in a fat partition, or even replace the kernel in a 50-mage, it's like, just, this is 23:19.600 --> 23:25.360 assembling, replacing the components, and putting it back in, and it's just, just work, right? 23:26.400 --> 23:36.160 So, what, what have we done, uh, in, uh, Yoko, we have, uh, Alperac was, uh, introduced, like, in October, 23:36.560 --> 23:41.760 uh, support for orange by RV2 based on the downstream kernel, and, um, bootloader. 23:43.440 --> 23:48.080 That was a good first stage, because it allowed me to add, like, the mainline only one. 23:48.800 --> 23:53.040 So, mainline, you, uh, open his BI as I said, mainline, you boot mainline kernel, booting everything 23:53.040 --> 23:56.480 from around. So, it's a bit limited, because that's the mainline kernel, but at least we, 23:57.200 --> 24:01.680 everything working from almost everything is set to first stage bootloader, that boot from, uh, 24:01.680 --> 24:07.920 that's booting on that board. And for orange by RVS, we have also vendor, and bootloader support, 24:07.920 --> 24:13.520 and image with vendor, and, and bootloader's, uh, kernels, right, right, yeah, that from 24:13.520 --> 24:21.680 flat, uh, banilla. I was supported, like, added last week. Uh, upcoming work with, uh, be, like, integrating 24:21.680 --> 24:27.520 new kernel features as they become available. So, obviously we're waiting for, uh, Linux 2019, 24:27.520 --> 24:34.320 or even better, 620 RC1, the meta-playing layer in Yoko is, like, pretty flexible, they will accept, 24:34.320 --> 24:40.320 like, pretty customized, uh, recipe changes, uh, to support some hardware, the matter is support 24:40.400 --> 24:44.880 new hardware, uh, and enable people to build images from them. It's not like meta-rock chip, for 24:44.880 --> 24:49.680 example, which is pretty straight. They really want the board to be in mainline, uh, before integrating 24:49.680 --> 24:54.080 it, because they don't want to depend on some external recipes, like kernel recipes, like, 24:54.080 --> 24:59.280 meta- mainline Linux mainline from Paul Barker, it's nice, but it, like, adds some dependencies to 24:59.280 --> 25:03.520 another recipe. We don't want, they, they don't want that. So, that's a super clean, super clean 25:03.600 --> 25:10.240 meta-layer, but for riff-fabets, much more, uh, flexible. Though you got good review errors and 25:11.040 --> 25:15.600 and it's, it's a nice, a nice experience to, to interact with those guys and learn from them. 25:17.440 --> 25:22.080 Uh, one more thing is it would be to generate a fully flashable image. For the moment, 25:22.080 --> 25:27.280 um, I still, I'm generating a new image with Yoko, but I still have to tweak the very beginning of 25:27.360 --> 25:34.240 the partition, a daily image, to add the, um, one tiny part that's used by the first stage 25:34.240 --> 25:39.520 boot order, and I couldn't do that with the weak tool that your top uses. Like, I, I, 25:39.520 --> 25:44.000 probably will have to write a plugin that does like what they do for writing a noun, 25:44.000 --> 25:53.200 MBR, uh, sector, at the beginning of an x86 image. I haven't figured out, I mean, I haven't found 25:53.200 --> 25:58.480 the time to, to do that yet. Of course, there, there would be also some recipe cleanups, 25:58.480 --> 26:03.440 um, that's needed. Like, uh, meta-riss-fabets work in progress. There are lots of, like, 26:03.440 --> 26:08.320 bolts that are supported, but there's not, there's not enough co-chering between the bolts. 26:08.320 --> 26:11.360 So, you, you, you, you guys, if you have your talk experience, you can help also, 26:11.360 --> 26:19.200 think this, this, this up. Right? So, there's, uh, where's, there's help needed. Uh, I, I, I, I, 26:19.200 --> 26:25.840 also would like to have a way to flash EMMC on, uh, our twist like this, this, this board, 26:25.840 --> 26:30.480 this one, this has only EMMC, and if you break it, uh, I could, I could flash it from Linux in some ways, 26:30.480 --> 26:36.080 but if I break it, how do I do that? Do that? So, orange pie has the Windows proprietary 26:36.080 --> 26:41.680 flasher. Don't, I'm not really excited about it. And also proprietary tool that they call 26:41.680 --> 26:46.000 Titan flash that could work for Linux, but it's proprietary. I don't want to run that on my laptop. 26:46.400 --> 26:52.240 So, I guess I would run it on, uh, on the run, uh, like, uh, uh, laptop with nothing on it. 26:53.600 --> 26:54.640 Um, no money. Yes. 26:54.640 --> 26:58.800 In front of the two of you, and then you could use flash, I could see what's going on or you'd be. 26:59.520 --> 27:01.120 Ah, okay. 27:03.120 --> 27:04.800 I mean, uh, yeah, okay. 27:09.280 --> 27:09.920 What did you say? 27:11.120 --> 27:15.040 Okay, I guess, so the, the question, the suggestion was to use Q and U 27:15.040 --> 27:20.640 to, um, to run the software like Titan flash, right, and see the traffic and help to understand. 27:20.640 --> 27:24.080 What anyway, it's supposed to be supported through ADB and fast boot, 27:24.080 --> 27:28.000 but I didn't manage to see it on my computer, and I don't remember the exact details, but 27:28.560 --> 27:32.960 it was like, there's something specific to that CPU or something like that. 27:32.960 --> 27:38.000 Like, I'm, I'm supposed to be in, um, ADB mode, like, when I press the button, but I couldn't see it. 27:38.000 --> 27:44.480 Yeah, okay. And the, uh, J-tech, I don't think the, the question is, do they have J-tech? 27:44.480 --> 27:45.520 Yeah, I don't think so. 27:47.520 --> 27:50.800 Yeah, maybe, but is it exposed on the board? 27:52.000 --> 27:57.520 So, okay, that's, I mean, people with ADB and fast boot experience may have a look 27:57.520 --> 27:58.560 uh, with a pre-hate. 28:00.160 --> 28:05.120 Uh, and one solution would be, maybe, to use, uh, bootly and stack boot on the space meet, 28:05.120 --> 28:07.920 okay, one is also, maybe, that's a solution. 28:07.920 --> 28:10.720 Uh, anyone tried this on this kind of CPU? 28:11.680 --> 28:13.280 If you have, I mean, trust it too. 28:14.640 --> 28:18.000 Other leads would be to find the orange pie out to a schematic, 28:18.720 --> 28:24.800 using, uh, something else than, then negotiation and threats, because that doesn't work. 28:26.320 --> 28:28.720 That's, that's, uh, I didn't do that. 28:28.720 --> 28:32.720 And other ideas for making that board better, those board better would be nice. 28:33.680 --> 28:38.960 So, uh, what to remember here? Uh, the top priority, of course, is to widen the kernel support. 28:38.960 --> 28:42.080 And that's the, the low hanging fruit. There are lots of things that are ready. 28:42.480 --> 28:47.360 You just have the drivers, you have example boards like vanilla pie, which, which is slightly ahead, 28:47.360 --> 28:51.040 a few boards that have like some showing how to use some of the drivers. 28:51.040 --> 28:56.640 So, yeah, it's really low hanging fruit to bring your small contribution to, to that board, 28:56.640 --> 28:58.000 and that would be much appreciated. 28:59.360 --> 29:03.840 And you, yes, as I said, you can also learn from the other K1 boards, right? Uh, like, 29:03.920 --> 29:09.440 vanilla pie, a three, milk, five, two, Peter, although it's a, like, uh, mini PC, a mini IT X1, 29:09.440 --> 29:14.640 next to it for, for my place. Uh, we, uh, we need a MMC support. 29:14.640 --> 29:19.680 I would be great to have it like to use it properly. Uh, you could also then, when this 29:19.680 --> 29:22.640 works, you could contribute to the mainline, but order, that would be great. 29:24.000 --> 29:30.080 And yeah, any contribution to Dr. Two, uh, uh, welcome to make to help people that want to use this board. 29:31.040 --> 29:36.160 So, some links, uh, the presentation earlier today from now side was great. 29:36.720 --> 29:41.920 So, like covering many more boards, and also giving you more details about what's going on on the driver's side. 29:42.960 --> 29:47.200 And you also have, oh, yes, uh, the, the Metaries 5 documentation. 29:47.200 --> 29:53.040 We documented the way to flash, uh, and boots, uh, those two boards like out to us, and, uh, 29:53.120 --> 29:58.560 RV2, right, uh, with only the mainline kernel. So that should be useful, right? Hopefully. 29:59.280 --> 30:04.080 So, um, open two questions. Uh, we have five minutes. So please. 30:05.120 --> 30:11.440 I saw you had a, uh, a deep problem on there. Do you actually check if they're different for different boards? 30:11.440 --> 30:15.440 Is that, that's, uh, uh, you, uh, you could, uh, for the staff at two points. 30:15.440 --> 30:19.840 So they, you just need one new board for all the staff, I thought, because they can see what 30:19.920 --> 30:24.880 all of the on from reading the, uh, okay, that's good idea. So they, uh, the suggestion was to check the 30:24.880 --> 30:30.560 e-prong for some things that you would could use for identifying the, like, two gigabyte for gigabytes, 30:30.560 --> 30:34.240 either device. That's how stuff I've already done, so you could look at that book. 30:34.800 --> 30:39.840 Oh, thanks. Which one? The, uh, J8, 71, 0, 0, the staff out. 30:41.200 --> 30:41.520 Oh, yeah. 30:41.920 --> 30:56.160 So the SPR wrong. To check the board. Thanks, good idea. 30:58.960 --> 31:04.960 Anything else? Have you seen this product in any devices? 31:04.960 --> 31:09.600 Yeah, but you think it's, it just makes it a hobby, so you can make it in the board. 31:10.800 --> 31:14.560 What do you mean, uh, you, uh, you have a, uh, you haven't seen a, you've been playing to a 31:14.560 --> 31:19.040 washing machine or a, I think, machine or something like that. You reckon you're actually 31:19.040 --> 31:21.520 making them just for people to think where or directly. 31:21.520 --> 31:26.880 Yeah, so the question is whether it's included in more real-life projects. I haven't seen it yet, 31:26.880 --> 31:31.440 but I'm not like, I've just, starting using it, like, two, three months back. 31:32.160 --> 31:36.080 So don't have enough information. That's a nice board, I would say. 31:36.080 --> 31:40.320 But who would like to use, like, uh, Ubuntu with a custom crown on it? 31:44.320 --> 31:49.360 Yeah, originally it was like super cheap and super powerful and with lots of connections. 31:49.360 --> 31:50.800 Well, that was great. Yes. 31:56.800 --> 32:00.880 Oh, okay, the question, the remark was, it's not going to be 32:00.880 --> 32:05.680 620. It's going to be kernels. Uh, 7.0 RC1. Oh, yeah. So that note, 620. 32:09.360 --> 32:09.680 Thanks. 32:12.720 --> 32:19.120 Yeah, so again, let's have opportunities to, to play, like, I mean, I find it like nice to try to 32:19.120 --> 32:24.000 hack a device tree using other examples and making things work. That's not rocket science. 32:24.000 --> 32:30.240 That's very easy, actually. Um, all you have to do then is create a proper commit that's 32:30.320 --> 32:34.080 accepted by the community, but the community will review your code definitely and help you 32:34.080 --> 32:40.320 making make it better the next time. Uh, so yeah, don't hesitate to contribute, that would be great. 32:41.840 --> 32:44.960 Any other? All right, so we're done. Thank you. 32:46.240 --> 32:46.960 End of the problem.