Welcome to my talk about the upstream embedded Linux on Risk5 and basically that's about
me.
I joined Coating last year and working there on embedded Linux stuff now.
The banana pie F3, that's this board here.
I will also demo it at the end.
So it's industrial grade RIS5 platform.
It has this pacemit K1, 8 core SOC, it's quite powerful.
I would say from the cheaper SPC, it's probably the most powerful right now.
It is available with 2, 4, 8 or 6, and 6, and 5, with EMC on board, it has 2 gigabytes in it which
is kind of nice for industrial use for use P3O, also as PCI Express, and it has for graphics
it has an HDMI output dual CSI.
like I said, it starts, I mean that's like the two-kick version starts at like 60 bucks.
All the experts, wherever you source your stuff.
Okay, when you get that, and of course at the beginning, there is not too much around.
So the vendor has some stuff, I looked at that.
The latest version is 204.
It got released in December.
That one also works now really with the 16-kick version as well.
And before testing, I used it as image.
You can boot it from SD card and downstream sources are available.
There is some stuff from the chip vendor on Githy as well as from banana pie.
They have a GitHub account.
It's this Scinovoid stuff.
They use an old OpenSBI version 1.3.
And you boot 2022-10, Linux kernel 6-6-63.
And the rest of the user space is based on Ubuntu 20-404.
And they also provide some APTs or so you can actually update your stuff.
And other features, this GCC-142 base, or LLVM-188.
One, and for the graphics, they use Meso20401.
But yeah, our ugly Chinese landed on stream stuff, not.
Then toolchain.
It was actually the first time I went into the risk five space.
So I was only familiar with ARM so far.
So I had to find out where you get your toolchain.
And there is this risk five collaborations on GitHub.
There is five collab.
And they provide kind of convenient for me as a X86 user.
Even so I could now put the risk five motherboard in my framework.
But right now I'm on some rising stuff.
So there they have pre-built toolchain that were fairly well for me.
The latest one available as of January 20 is a GCC-142, or LLVM-1917.
Also on that GitHub page you find guidance.
You know, if you want to build your own toolchain for major Linux districts,
with all the dependencies and stuff you would need, or also for macOS,
with there whatever proofing they use, and not much macOS guys.
I don't know, but you could probably easily find out there.
I was looking at upstream reboot on that board.
Initial support actually just got merged before Christmas on December 18.
It's this GitHub here.
It also has some documentation.
However, that they talk about using downstream openness BI from that vendor GitHub stuff.
I asked guy about that, whatever, but I didn't write it with just upstream openness BI
and for me to work just fine.
So it's confirmed working.
And in flight, as of January 20, there is a fifth version of a patch set that also probes the DRAM,
because that was my other question to the initial patch that it hardcoated the RAM size,
but I have different of those boards with different RAM sizes, not.
And now that there is on the mailing list version 5 that out to detect that.
Typically just reads from the RAM controller, what configuration it is, and then that's it automatically not.
What else is to do?
So far, the SPL support is missing.
So in that same documentation, they write how you basically just have to use the Chinese super troopersing
you leave the SPL from that when the downstream stuff and you only replace your boot property.
So for now, nobody looked into the SPL stuff.
So it relies on the vendor one.
And then of course the next stuff will be to add more missing peripheral drivers.
Right now that boot is not much useful, not it just like console serial console.
That's it, it doesn't support any kind of peripheral storage or anything.
But yeah, at least so far so good.
That is sorry.
Oh no, what happened?
Can you still hear me?
That is how that looks.
So on the you see on the left side, that basically the SPL output is from that.
Possum it downstream stuff and then it spawns your boot property.
This is later stop stream.
Also with that DRAM patch applied, as it shows here the 16 gig that this port has.
Okay, then let's have a look at the kernel.
Up stream kernel.
Initial support actually just got merged on January 17.
However, as you guys probably know how that works, it's only in dash next so far.
So it's targeting to be released in 640.
And the pieces that are there is a device tree, pink control and also the console you are.
Then there are another bunch of patches in flight right now as of January 20.
There is version 4 of GPIO support, which I also gave it a spin that that one they used.
Heart beat LED to blink that not so we can pretty nicely see whether that is working or not.
Then they also have patch set version 4 of the clock control support.
That one I applied however, you would kind of now need also peripheral drivers that then use that not so sure.
Whether it does match without any of that.
But yeah, it built and we still know.
Then another driver that just recently got posted, but first version is for the panic.
They call that the P1 panic.
It's also from the pacemid company they also do the panic for it.
And yeah, that patch set you see there on the to do.
That one didn't even build for me.
I think it's missing some other glue pieces who knows.
But for now that one I haven't seen that working.
But another one I have seen working is version 4 patch of dysquercies support.
However, that would be a peripheral driver not, but it doesn't use the clock yet.
So I think it relies probably on the bootloader having enabled that clock or something like that.
Because it magically works, but it doesn't talk to the clock.
I also had to hand tweak that it was missing all the device three parts, which is kind of as if you have ever worked with that stuff.
It's sometimes a little bit tricky, especially in the downstream.
They have a total different way that the orange is whole stuff.
Also with the interrupts, because there are different interrupt controls and all these kind of details.
But I hand tweak that and the good thing is, and I also listed it references.
I mean, the patch emitter has fairly good reference stuff on the internet available.
However, which I find a little bit inconvenient, you cannot just download it as a PDF or something like that.
They just have this website that has all the reference manual and stuff, and you kind of browse through that.
But it really is there, and you can find out what interrupts and addresses.
So I was able to construct the device three.
At least I think it has like a dozen channels I see, and I only concentrated on one of them, which has an ear prom on it.
And I was able to poke the ear prom, so that driver also seems to be fine.
And then, of course, all the stuff will be more peripheral drivers to be more useful.
Not too bad.
That is how that looks.
In this case, I actually use, yeah, as I said, you can't really use upstream hubo, because that one doesn't really have any peripheral driver, where you can download anything else.
So I had to use downstream hubo to run upstream Linux, and when you use the vendor stuff, you get,
In the environment, you get all this detector, to be at all this kind of stuff.
But of course, it doesn't work with the defaults that downstream uses to boot downstream Linux.
And I just used this basically set the boot orgs just to the console that you actually also get some output, not, and then I used whatever downstream RAM disk in this case,
and boot it like that, because remember the kernel doesn't have any further peripheral drivers.
So, at least I get the RAM disk and can poke with that.
You see here, you need RAMFS, and there, even that you need RAMFS, conveniently has the iSquare C Transfercing content, which was kind of cool.
So I was able to test whether that iSquare C stuff I had to get that actually really works.
And you see that here.
Okay.
Then let's have a look at, you know, more like build systems and complete kind of distrust and not.
One that is much used with encoding is basically free desktop SDKs.
We are the guys that are, I guess, the main supporters of it.
Free desktop SDK as a build system, it uses build stream, build box.
It might not be that known to most guys, it's basically, they only do native compilation.
That was, of course, a little bit problem not, so they don't do cross compilation.
So, I did write with QMU user mode emulation.
That is also known as QMU's static.
And that actually works amazingly well, but, of course, it is really slow.
And compiling like that, the kernel took like way overnight, not.
And yeah, I mean, it kind of works, but it's not very convenient, not.
So I went to have it and told him, well, give me the money.
And we have that, not luckily we have nice milk-wive pioneer machines.
So, on 64 core, plenty of RAM and stuff, and they really fast.
And on that machine, it works just fine to build that stuff, not.
Yeah, but you have seen Ben also talked about risk-fifes stuff.
We are quite frequent contribute in that space.
Free desktop SDK on this board is working progress.
Basically, there have been two of my colleagues, Tom Rodriguez and Matio Martelli working on it.
And there is now a merge request.
I have it also listed in the references if you are interested.
It has, at least here, the build stream elements to build that, not.
Basically, we have a component open SPI for the pacemid K1.
That basically builds the downstream open SPI.
Then we have a U-boot element that builds the downstream U-boot.
And we have Linux kernel element.
Usually, of course, we does to best decay wood.
That's not good.
We does to best decay wood.
There's somewhat top-stream kernel, but in this case, we cannot do that.
So we have to use a separate element to build the downstream kernel, not.
And then basically, that has to do with the way this board boots, not.
It needs it's boot chain in a certain way.
I mean, the boot drum, expect it that way.
And for that, there is a VMware boot loader pacemid K1 element that basically uses
Chinese to generate this image of those above pieces.
Plus, there is, like, on the very first block on the SD card, it expects.
So called boot info.
That determines all the other pieces and stuff like that.
That's just some kind of a 80-by-t boot info header.
At then, use a space.
One can use regular rest-wise use a space.
For example, VMminimal FE.
And that Chinese generates a disk image, which includes the FE and whatever other pieces not.
To do, we have to do more testing and I am now to remain in issues.
Like I said, thanks to my colleagues who contributed that stuff.
And yeah, you can find the much requests in the references.
And there is, of course, discussion going on about some details there.
That is, free desktop SDK, how that works.
We've built streams, so the BST command basically, like,
a bit bake for those guys that know that, not.
And then you specify, we've done stream BSP.
You specify the space emit on the score K1.
And then you can say, you want to build this boot loader element.
And that, of course, builds all the dependencies and all that stuff.
And then once you have built it, you can check out artifacts.
How you can be done. You give it a direct, really, the puts the stuff there.
The same can be done with every FE stuff.
And that is, then I list here.
Also, you see how the size is out of these parts.
And basically, boot loader, there are two variants.
And that material did one for the SD card, where it just gives you this image,
that you can basically,
DD to your SD card, not, or not DD.
To DD or not to DD, that you can join my talk tomorrow, not.
I would not DD it, but I still casually talk about DD, not maybe I should change that language as well.
Anyway, and for the nor you, you have to then basically upload this single piece on your own.
But he talks about that in the merge request.
It's documented not.
I left that for reference there.
And same, this image for the EFI stuff.
Okay? Then, you have the project.
There is a, metari's five on GitHub, not that you guys are probably familiar with.
I also, to get more and do the risk five topic.
I also have some other of the, you know, general available boards like the Milk Five Tool or the Vision Five Tool.
And all those are, for example, supported as machines in the Metari's five.
And yeah, it's a general hardware-specific BSB overlay for risk five-based devices.
And in, in, in, in July there was actually an inquiry as an issue on that GitHub.
That's, somebody asked about BPIF3.
Support, yeah, but so far, the only thing I found anywhere, there was no progress ever since.
So to do is basically everything.
Actually, you're not, but it's just a little bit of work.
So, I've started working on a machine configuration.
It's the Conf machine, Benar Pi, BPIF3.
And then, yeah, a recipe for the bootloader.
That, that builds the downstream new boot.
And then, a recipe for the Linux kernel.
There, the only thing that I had to do is, I had to disable some failing stuff.
I guess, the way the October builds the kernel, it's somehow.
Try to build some stuff that doesn't build in this super ugly downstream stuff.
So, so, but with that, it's basically works.
And then, of course, it needs a weak image that puts all these parts together.
And also adds this 85 booting for thing.
And that is basically where I'm still working on right now.
And then, I need to do some more testing and I need some remaining issues.
And I put the references, a link to my GitHub.
I will put this current status of the stuff there, and you can check there.
And I also plan to then submit it now.
Okay.
Very good.
Then, we have some time for the live demo, which.
I brought here.
That is more or less what we have here.
Let's see.
How we do that.
I have here.
Then increase the font a little bit.
That basically, I have here an FTDI thing that just does the console not.
And I still the power here.
It can actually be powered either by good old 12-volt barrel or by USB-C.
And I just use a USB-C here.
Let's see.
Somehow.
Something like that, exactly.
This is actually the downstream Biendo stuff.
Just to kind of reference.
Now, whatever it is, it kind of killed.
Now.
I think the default password is Bionbo and they only have a router count as far as I know.
That's basically what you get.
Like I said, 6, 6, 36 and kind of works.
And now, I have another SD card.
I put it.
Yeah.
I have another SD card and I have here.
You put sources, for example.
And we can try, for example, this U-bo die-to-beating.
And in the U-booth sources, I can also make that bigger.
You find that documented board, a semi-manipide.
That's the document that I mentioned, not blah blah blah.
And then they basically say, burning, burn your fingers.
Let's see.
So the fourth partition of SD card.
Let's check that.
Let's block note.
So this is this SD card.
And the fourth one is this two-maker thing is the boot load amount.
So we can basically TD that U-boot ITP thing to do.
SDA4.
Make sure you don't write your whatever.
Let's have a look.
We put this SD card in.
And then this guy.
And we reapply power.
So he's doing here.
It's now running.
Main line U-boot, of course, like I said, it's not.
It doesn't have easy net or anything, but it has some driver-model drivers.
You see, it's basically the serial driver, which, by the way, that was kind of an interesting thing,
because I don't know, Mark is not here, not back in the days when we played with PXAs.
And it looks like, for who knows how, but this Chinese company spots him it.
They actually use U-art IP from back from the PXA.
So from Intel or right, I mean, who knows how they got that, but that's what they're using.
And that's also why it's really easy.
In U-boot, the driver is there, not just the regular IT-2, 50 driver with this special whatever PXA,
register mapping, and that just seems to work, not.
And that's more or less it. It doesn't, I mean, it has the CPUs and the console, and doesn't do anything else.
Okay.
Then, the next piece will be, I already, a little bit, prepared it, so we don't run out of time.
I already put the kernel on that SD card, but now we need the bootloader that can actually boot that,
otherwise it's kind of not going to work.
So, we go back to this one, and now we did the another bootloader again.
So, let's see.
I don't know what to do.
And I don't know if I just maybe have that right, but it is all.
Let's see.
Micro SD cards are so small, so you can hardly handle them, not.
Wait on the Nano SD card.
We apply power.
Here you go.
Now we are in whatever downstream you boot again, not.
And then, I have somewhere some notes.
Basically, this is what I had on the slide, not.
I came around that, around Polish Wilson, and set boot orgs, and we do that thing.
We're in this initramffs, and it's roaming 6-13 dash next, with all this stuff, not.
And, like I said, there is this i square c transfer thing, that you can play with, not.
Woo.
Yeah, I think that doesn't always work.
Yeah.
All I think means read 8 will be 8 bytes, and at will be 80 is the i square c address.
And the one is the pass, not.
I don't know.
Is that the device on the board?
Yeah, exactly.
So it's a mepron, but I don't know why.
It's probably just a demo effect.
No, no, that's the only thing, exactly.
That is a way to see.
Anyway, that's about it.
Let's start this off upstream on embedded 3-5 stuff, not.
Thank you very much.
Any questions?
Thank you.
That looks very good.
I actually looked at the SPL.
Okay.
There is a binary block for the DRAM training.
And after like 2 weeks of Gidra, we now have an open source implementation.
Do you want that?
Do you want to upstream it?
Yeah, I guess sooner or later, some about the issue to stop stream, you know.
If you do have some doubt, we need to translate it from rest to see, but that's a trivial code.
No.
We'll get in touch with you.
Okay.
Thank you very much.
What's in the byte info?
The first thing you'd like, what is that contained?
I haven't looked in detail, actually.
Yeah.
I assume it's just some kind of a header that then points to the other pieces or something,
but what I haven't indeed looked, I think.
In downstream, they use some tight and stuff even to generate it or something.
So I think it's not totally closed or anything like that, but the question will be a little bit,
what do we even really need and what how do we want to do it, not in upstream, basically.
And I think they use the same header in on the SD card or in the EMMC or in an order or something like that.
So I think it's just like, I don't know, I know from Toratex, the free scale stuff, not they also have some kind of a boot I don't remember how it's called.
I mix emits or something.
Okay, go ahead.
Do you have some, I tried Googling it before because I was interested in that board.
Sure.
It's very hard to come by that information, probably.
I'm hoping that you know what are the IP vendors of the different peripherals like networking.
Well.
EMMC graphics and sometimes they didn't do it on their own.
Like I said, under you are, I know that it's from PXA, but I have not checked on further pieces here.
And I'm not sure how much is known or listed somewhere or documented, but I don't know.
The downstream kernel device we claim to be that the kind of decontroller is compatible with a flex can from NXB.
Yeah, okay, the can controller.
Yeah, I don't know if they have boarded or got their hands on it, I don't know.
That was also a little bit my question.
Do you remember whether they stole that together or they really have an IP license or how they exactly do that?
Actually, it's almost convenient if they just stole it because then you can just use the drive or not.
But from a legal point of view, I mean, it doesn't sound like, I don't know, yeah.
Hello.
Have you tried the overclocking it?
Overclocking.
Have you tried it?
Oh, overclocking.
No, I haven't tried it.
Because the actual CPU was firstly advertised at 1.8.
But it usually comes now at 1.6.
So I did try and it works with 1.8.
Yeah.
I wanted to know if someone did more than that.
I have not tried it and I also read different sources.
They talk about different frequencies and stuff.
But how it works and whether they, I mean, I know also from like free scale, they kind of create their chips and they usually have a way to do that.
Not maybe the boot load or something to do that.
No.
It's early, it's not scared.
Yeah.
Here I don't know whether.
Yeah.
Okay.
But I think there is also a second version available.
It's called M1, not.
Yes.
And that has also supposedly different frequencies again.
But whether it's a different production process or something, I don't know.
The various patch set that you've referenced.
Would you say this is a community effort similar to Santi or other actually contacts from, you know, the various vendors involved in at least previewing the patches if not sending them upstream?
Yeah.
I think there isn't really kind of a community around it yet.
I would say.
I mean, it's just some patches from, I'm not sure where.
Yeah.
I don't think so, but I'm not fully sure.
I think this, this ram patch now on the YouTube, for example.
Maybe that was also only the discussion.
Yeah.
I really don't know.
I mean, those people didn't say anything to me, basically.
And they don't email addresses whatever, not to Gmail, whatever.
Okay.
There aren't any questions here.
Thank you very much.
It's a wrap.
Thank you.