So that's very cool, and one of the reasons which makes it possible is that we have MMC card support now so we can actually put the file system somewhere, which is really convenient. We have simple FB support. Simple FB is an interface between U-Boot and the kernel, that the kernel knows which

piece of memory is used for the frame buffer, but also which clocks are used for the frame buffer, so it shouldn't turn off those clocks. We had a huge flame fest on a number of upstream mailing lists to get the API between the kernel, and U-Boot fleshed out here. That took me a lot of blood, sweat, and tears, so to say. But it's there now, it's upstream, it's done, and it's working.

And we even already have support for the latest, as you see from Alwin or the AAD, but this is basic support. This is currently at the same level as where we were last time for the A10, A13, so you get a UART basically, and you can boot from a memory image. So what's coming?

Let me first tell you a little bit about how we bring up a new SoC for Sang-C. The Sang-C SoC itself has a little boot ROM inside, which is not capable of doing a lot. What it can do is it can load up to 24K of code from an SD card,

and copy that to its internal SRAM and execute it. So this is basically where we have a powerful SoC, but we're still talking microcontroller-ish stuff, right? We have 24K of code, that's it. In the 24K of code, we need to set up the DRAM controller. Well, first we need to program the power management IC, which is an external IC,

which creates all the voltages which are necessary on a board. We need to program that so that the DRAM actually gets power, because if you don't give it any power, the DRAM won't work very well. Once the DRAM is powered up, we need to program the DRAM controller to actually talk to the DRAM and set all the timing parameters correctly for the DRAM used on the board.

And then what happens is that there is also in the 24K a simple SD card driver, which will load the real U-Boot, which is about 400, 500K, so half a Mac of code, to DRAM, and then we will jump into the real U-Boot.

So that's how basically a boot for U-Boot works. We have a tiny first loader, which is called the SPL, which stands for secondary payload, because the primary payload is the boot run which is wired inside the SOC, this is which starts executing. The secondary payload is the tiny loader, which needs to initialize the powers and DRAM, and then copy the real U-Boot into DRAM and jump to DRAM,

and then the actual U-Boot runs, and the actual U-Boot is therefore sometimes called the tertiary payload, which will load the Linux kernel, which is what we actually want. So that's the quaterary payload. So getting up a new SOC means that we need to build both an SPL and a U-Boot binary.

If you look at the custom bootloader, the proprietary bootloader, which all Windows ships, that also uses two stages. They call what we call the SPL boot zero, and then sometimes they have an extra thing called boot one, and then they load U-Boot, and on some versions they load U-Boot directly from boot zero. So what we usually do is we start with just building only a U-Boot binary,

so we don't have to worry about power management, IC, DRAM, init, etc. And then once we have the normal U-Boot working using all winners own boot zero, which is a proprietary blob basically, to do the DRAM init, then we start working on our own SPL to replace the DRAM controller.

So this means that the steps for getting up a new board are first of all just getting the basic U-Boot going, using all winners own proprietary bootloader. And then once that works, we need to figure out how the clock tree setup

and the power management IC and the DRAM controller actually works. This is nasty stuff, especially the DRAM controller, because there are no dogs. All winner usually is working with us, they're giving us data sheets and whatever, but whatever IP block they are buying for their DRAM controller has some clause in the contract which they have with the IP vendor for that DRAM controller,

that they cannot tell us anything. They cannot give us code, they cannot give us data sheets, they give us nothing except boot zero. So to get to A23 up and running, as I said before, we now have A23 support, so including SPL in U-Boot, I basically had to

disassemble boot zero and look at every instruction what it was doing manually. A33 support is coming up. I was hoping it would be very similar to A23 since it's been compatible, but they put in a different DRAM controller. So yesterday when I was in the train here, I spent two hours going through arm disassembly again,

figuring out how the DRAM init for A33 works. And I'm probably still going to spend 20, 30 more hours going to arm disassembly, and then hopefully we will have DRAM init for A33. So this gives you an idea where we are, at least for the A33. Currently we are at me staring at disassembly listings,

but there are more socks which we want to support. A80, the all-winner A80, the octa-core, the big little one. Step one is complete, so we have a basic U-Boot bin which we can load with all winners boot zero. Step two is looking complicated because they are using two PMICs who are chained together.

So they don't have one IC which creates all the voltages on the board, they have two. And they're chained together somehow. And we don't have schematics of the board, so we don't know which voltage of the PMIC is going where, and we have about 16 PMIC voltages which we need to configure. But we don't know which one is going where or what it's powering.

So this is still a bit of head scratching, and I've parked this for now and I'm looking at the A33 because that looks to be lower hanging fruit at the moment. Then there also is something which is called the A83, which is the budget version of the A80. I know you can buy tablets with this sock in there. That's what I know of this SOC.

I know the marketing speak. I know there are tablets which I can buy, which I haven't done yet. So that gives you an idea of where the A83 support is. It's basically non-existent at the moment.

The kernel roadmap. Real soon now we have a contributor called Chen Yu who does lots of really great work. He's over there. Who does lots of great work for all-winner support. And real soon now we should in the upstream kernel have CPU frequency scaling support. So currently what happens is we ramp up the SOC CPU core voltage

in U-Boot to the maximum voltage. We ramp up the clock speeds to the maximum clock speeds. And that's what it's running at. That's what we're supporting. So this is running nice and hot. It's nice and warm. We should have CPU frequency scaling support soon. We should soon have A80 USB and MMC slash SD card support.

Again, thanks to Chen Yu. We have someone working on a DMA controller driver and an audio codec support. Those two go hand in hand. So we should soon be able to do audio output, at least over the analog outputs which a lot of boards have.

I think we still need to figure out how to route that into HDMI. We know that the chip can do audio over HDMI and that is what you want if you don't have any headphone connector like this thing. We know it's there. Once we have the basic audio codec support, it should be just a matter of gluing the two together. Famous last words.

So that's something to, well actually that's not something which we can do until we have a kernel mode setting driver for video. Right, because we need to integrate that at the kernel level. So work in progress is NAND support. NAND support is a problem because all the all winner devices use RollNAND. It's not like an SSD where there's a fancy controller

which does a flash translation layer. It's RollNAND. You need to do everything yourself. The Linux kernel has a subsystem for this called the MTD, the Memory Technology Devices subsystem. And that is basically from the 80s. It's not really from the 80s. We didn't have Linux in the 80s yet, but it's old.

It's meant for single level SLC, single level flash chips, and nowadays everything is multi-level. It doesn't support that yet. We need support at the flash translation layer in the kernel for MLC devices. We have some patches for those, but no one is maintaining it,

so no one is able to review those patches. So if you know anyone who's interested in doing MTD stuff in Linux, we could use help for the NAND support. Someone, I don't remember his name, I must admit, has posted a patch set a while back for support for the hardware crypto engine. So you can do things like DES and AES in hardware on the SOC.

I put those up as WIP, but they seem to currently be a bit stagnant. I hope someone will pick up that patch set again, or the original contributor will start working on it again soon. The last thing which is being worked on, which should be ready soon, is a driver for the AXP8221 PMIC.

The AXP8 chips from all winner are the power management ICs, so the one which make all the voltages, and which you can use to configure, for example, the CPU core voltage, and we want that because if we can't configure the CPU core voltage, then we can do frequency scaling and voltage scaling matching that. So once we have that merged,

we can probably also look forward to CPU frequency scaling for the A23. And who knows, maybe it will be the same for the A33. Planned, as in someone will start working on this soon, is a USB OTG support. This is a very important one.

I said before we have OTG support in U-Boot, which means that I can take a cheap tablet and unplug any USB keyboard and interact with U-Boot, and then I can tell U-Boot to boot the kernel, and then I no longer have a working USB keyboard, because the kernel doesn't support OTG yet. So once we have this one, so I will start working on this real soon, and it looks pretty doable.

I also did the U-Boot patches, so I know what I'm talking about. Then you should be able to sort of use a tablet with a USB keyboard with stock Linux. And we also want to have a kernel mode setting driver, so we don't need to not only just take over the framework for setup by U-Boot, but do smarter stuff like change resolutions

or dynamically detect something is plugged in and react to that, etc. And Boris Brazilian, I hope I'm pronouncing his name correct, probably not, will hopefully soon start working on that, or he may already be working on that. And that leaves us with exactly five minutes for question.

Yeah, so let me repeat the question. The remark was we had MLC NAND working something like six years ago,

so if it's not in the kernel, something is wrong. You need to talk to Boris Brazilian about that, because he's doing the NAND stuff. I don't know the details. Something with randomizer support and hardware ECC, and we need support for those features and something like that. Yes, we are getting support in the form of we can ask them questions,

which they may or may not answer. Basically, they answer almost every question, except when we have questions about the DRAM controller. We have full documentation, except for the DRAM controller and the GPU, of course. So in general, Allwinner is supportive. It's as supportive as they can be, giving their contracts with the IP vendors, which they deal with from whom they buy the IP,

which they use in their SOC. But yes, we have support from Allwinner. They help us. We can ask them questions and usually get answers and things like that. Yes, there is a lot of info which we can get from their kernel sources.

Yes, they do have something which could be considered GPO violations, depending on your interpretation of the GPO, because they ship some object files instead of shipping source for every module, which they ship. That's something up for debate.

I mean, NVIDIA is doing the same for their binary blob driver for x86 GPUs. So that's debatable. I don't want to really go there, because Allwinner is cooperating with us, and I don't want to tell them, yeah, but you are doing stuff which we don't like. Some people do yell very loudly that Allwinner is violating the GPL. I think that within the SOC world,

they are one of the better vendors. Not the best, but one of the better. So for most of the stuff, the problem is not that we don't have the code. It's just that the Allwinner code is so horrible that it usually is better to just completely start from scratch than reusing their code.

Or at least you need to do a lot of cleanup. Except for the DRAM controller, we have no code. Yes, but that's not part of the kernel. That's part of the bootloader. So they are not violating the GPL there.

Yeah, still it was not really in the kernel. It was firmware, which they were loading in another device. But it doesn't matter much. Are there more questions? Yes. What's the graphics driver situation? Luke, what's the graphics driver situation?

No, Luke? Ha, too bad. The problem is that there are two GPUs used. If I go back to the initial screen, you will see that there are two GPU used.

Yes, there we were. The Mali-400. The Mali-400 has been reverse engineered. And Luke Verhage has a Mesa driver for it. But he wants to not publish it until it's 110% ready. And code is never 110% ready.

So please ask Luke if he will be so kind to publish his code. So others could maybe integrate it further. Then the other part of it is that some of the newer ones have PowerVR graphics. And PowerVR graphics are basically never going to happen. It can be really simple there. They are never going to get supported in Linux.

Unless PowerVR itself changes its minds and starting doing an open driver itself. So the GPU situation is Mali-400 is possible. But either we need someone to redo Luke's work. I think he did publish his Lima work. So the initial instruction set reverse engineering is public. So you could start implementing a Mesa driver based on that work.

So then you have a lot of work to base on. Or someone needs to convince Luke to actually release his source and or integrate it with the existing upstream code, etc. Are there more questions? Okay. Oh, yes.

All the way in the back. Can you scream or can someone bring you a mic? Wouldn't it be better to get an old winner to do all this work themselves? Yes, definitely. If only they would hire competent engineers.

Let me summarize it with that. Pretty much. They are going for time to market. They are going for Android kernel, specific kernel patches and things like that. So they're not really interested in upstream kernel support, basically. That's the bottom line.

Thanks for your time, everyone.