 Are you ready? Yes, I'm ready. Simon Hormann? My name's Simon Hormann. I work for myself in Tokyo. And I'm going to be talking about a little bit of work I've been doing with a customer on this guy, which is an embedded board. It's not actually a mobile device, but all of the little IP blocks on this device will eventually go into a mobile phone of some sort. So the company that I'm working with is called Rineses. They're one of the largest microprocessor manufacturers in Japan. The target of this work is this little guy I've got down here, the macro board. The predecessor is the APV, AP4 EB. The macro board will be available for purchase next month or the month after that. The AP4 is never going to see the light of day. I'm in possession of one of the few that exist. The default boot loader on these devices is Uboot. And we'd like not to use Uboot anymore for various reasons. We'd like to boot directly into Linux or to use Linux as the boot loader. So why is it that we don't want to use Uboot? There are a few reasons. One of which is it's essentially re-implementing a bunch of stuff that's in Linux anyway. So that seems unnecessary. There are some advantages to Uboot. For instance, it's smaller, but these days with the amount of flash we have available to us, that's not important at all. It's a different tree and it's not maintained perhaps as particularly well, at least in the opinions of myself and my fellow developers. And just fundamentally, we like to give people different options. So the role of the group that I'm involved in, firstly, we prove hardware. Andrew Trigel's quite well known for saying untested code is broken code. Well, it turns out that untested hardware is broken hardware as well. So one of my jobs in this project, which I'm talking about today, is I'm essentially the first person who's actually got Linux to boot off, or not Linux at such, but anything at all to boot off the MMC block and not so much the SD block. If someone doesn't prove that that works, it's quite likely it doesn't work. And we found some problems on the way which I'll talk about. We wanna provide options for our customers. Fundamentally, our customers wanna take hardware and software and sell it. It turns out they're not particularly proficient at developing either hardware or software. So we like to help them as much as we can. And one of the nice things about Renes is it's a very large organization. There's lots of red tape. It's hard to get anything done. I'm currently reverse engineering their own hardware. But the group I work in, we have upstream first policy. So any code that I produce, as long as it doesn't contain secrets, we can just upstream it. And anything, I'm not exposed to any secrets. So anything that I can write, I can upstream. So that's kind of nice. So this presentation is fundamentally about booting. So let's take a look at what booting often looks like. You have a little bit of code that's loaded off Nor Flash, which is typically burnt. You can't modify this. Then this loads some code off Nan Flash, which you can update if you have a JTAG available. And then you're off to the racer. So you usually have a ROM and then a bootloader and then a kernel image. This is pretty standard. This board does that kind of thing by default. So the first goal I have is to boot the image, the Z image, to boot Linux straight from the Nan Flash. And this goal has been successful. It will be in the next release kernel. So this is essentially the boot flow. It becomes slightly shorter, although that wasn't really the aim of the project. We go straight from the mask ROM to a Z image. So I'll go into a little bit more detail about how this works. I'm assuming most of you aren't intimately familiar with bootloaders. I certainly wasn't when I started this project. So Z image looks a little bit like this. It has a loader right at the top and then it has a compressed kernel image. And it's pretty straightforward. So the process of Z booting from Nan, what does it look like? Essentially, we have on the RAM, we have the image. It's been burnt there somehow. And then the mask ROM actually knows how to copy the image over into Nan Flash and to move the execution state over to here. That's pretty simple. Once we get to here, the kernel hits the loader code. It uncompresses itself. It relocates itself. No problem. So we've basically just eliminated Uboot. It's not very complicated. The code, the patch to change this was, there's some assembly root code to set up some registers so you have some memory. Then you basically set up the A tag so when the kernel gets a bit further in the boot it knows what type of board it's running on and you're off to the races. It's maybe 100 lines, probably less. So that was pretty straightforward. That works, that's nice. So we can now boot this guy without using Uboot. But, oh, sorry, I skipped it. So this is the next slide where the kernel is now uncompressed and it's jumped. So what's called two? Booting off Nan is nice, but you need specialized equipment to be able to write to the Nan Flash. I actually didn't have the equipment so I would modify the code and then go down to the lab which is like several suburbs away and then they would burn it to flash and it worked so I only did that once. But it's not very practical because most people don't have this equipment available to them. So it would be much more convenient if you could just get an MMC card which is, it looks like this, it looks a lot like an SD card. It's strongly related to SD cards. It would be useful if you could just burn an image to this guy, which is trivial, my laptop has a hardware that's capable of doing it. You can buy a USB to MMC converter for a handful of dollars. Finding MMC cards is a bit more tricky but we have, I mean, I got this from Amazon, I had to wait for a week for it to arrive but it maybe costs $10, I don't know, something like this. It's more accessible. So we'd like to be able to boot directly from that. So the boot process is going to look a bit like this. We start off with the mass Chrome again. The mass Chrome's kind of clever. It has various functions and using some of the dip switches on this board, I can switch it so instead of jumping to NAND, it tries to load a bit of code off the MMC card and boot that. This loading that the mass Chrome does is limited in some ways. It can only load a limited amount of data. So basically what we're going to do is get the mass Chrome to just suck off the top part of the Z image which contains the loader code and then that loader code itself is going to reload the entire image. So this is, so we've added an extra stage basically. So the first stage is fairly straightforward. We have the entire, this is our MMC card, the little thing I held up just before. We have the loader and the compressed image sitting there in the Z image. There's actually a header that goes on top of that. It's not very exciting. The header just has a little bit of information telling the mass Chrome how much data to suck off and where the data is on the card. And then it just copies it over here to the SD RAM and importantly it sets execution over here. So now we're in the loader code. So the mass Chrome is essentially not modifiable. I know the people who wrote it but it's burnt onto the CPU. Even they can't modify it now. But this guy is just some C code that I wrote on my PC and copied onto an MMC card. So that's cool, I have control over this. And inside here I have code to load all of this guy somewhere else into memory, like so. So there's a little bit of overhead because actually I've copied the entire loader again even though I'm actually part way through executing it but that's okay, it's just a few extra blocks. So then we jump to it again. We're actually part way through the loader at this point. So there's this magical thing where we have two copies of the same code in memory and we just jump to the next instruction in a completely different part of SD RAM but that's fine, that's okay, we can do that. And then after that the loader does its normal thing of uncompressing the kernel and then jumping to it. Okay, so that's pretty straightforward. I mentioned at the beginning of the talk that untested hardware is broken hardware. I actually had to get the guys in the lab to do a hardware hack on the board and they wouldn't disclose to me exactly what that was but essentially this feature did not work. And so this is a problem because we wanna ship this and yes, it works for me, it works on this one, this one's been hacked. I was, unfortunately the USB cable that I borrowed just now is the wrong size but maybe if you're interested, or maybe I can just hold it up, it should boot. So I have to turn it on and then I have to hit the reset switch which activates the hardware hack and if I'm lucky it will work. Yes, it's working, so I can see some LEDs which give me some status here. You may be able to see that the display came on, probably not because it's black. You have to trust me, you can come down and see it a bit later. Anyway, the first time I saw that was a very exciting moment for me because it meant essentially my project was successful. So there we are, we can do that, we can boot. Of course you don't know if it's really booting off that, you have to trust me but I can assure you it is. So that's nice. Now it turns out that this board actually has two related IP blocks. This is the MMCIF hardware block which is capable of reading MMC cards. It's produced by Renesis. There's another hardware block over on this side which takes both SD and MMC cards. They look quite similar, they're not similar but they look similar, physically they're similar. So the next goal was to try and get to boot off this guy because as I mentioned, MMC cards are actually a little tricky to get your hands on. You probably can't go down to your local electronic store and pick one up. You probably have to order one. SD cards on the other hand, you probably have some in your house anyway and if you don't, you're probably the local convenience store sells them and they're very easy to obtain. So it'd be nice to be able to boot off that. This turns out to be a slightly more challenging project. And I won't describe the boot process because it's basically the same except different jumper settings but unfortunately it's not working yet because so we have SD and MMC but we also have E variants where E means embedded so E SD and E MMC and the manual that I have specifies that this guy needs E MMC but as you have just witnessed that's actually not true. So that's fortunate because you can't buy an E MMC card because inherently E means embedded which means sort of soldered on and I'm not very good at soldering and I imagine you have to buy these things in fairly large quantities. Okay, so back to why SDHI isn't working yet. Essentially the specification that I have says E SD, not SD and the guys in the lab told me that in fact that is true this time. Last time they said the EMC was false. They're very nice at pointing things out. So we're having to borrow one from someone in some other part of Japan and hopefully we'll be there when I get back next week. But now we're in the awkward situation so this is all been very nice. From a software point of view I've been fairly successful. I mean, it boots, that's good. But from approving the hardware point of view this has been not particularly successful because we're in a situation where we know that this one doesn't work without a hardware hack so that's bad and we're now in this situation where we strongly suspect that this guy requires a specialized card that essentially you can't buy. So we may, or not me personally, but the people who sell this may well be in the situation of having to ship special cards with it which will probably be in the form of a PCB that pokes out with something sold on to the end of it. I've seen such things in the lab. So that is the end of what I wanted to talk about today and thank you for your time and if you have any questions, feel free or I'll be around all week. Just come up and ask me. Right, so the question is whether or not other vendors perhaps Google might pick this up. So the bit of code that has to go in, it's actually board specific so you'll need one of these bits of code for every single device. But that's not so bad. That code has to exist somewhere because the code, if the device boots. Yeah, so certainly from the Rinesse side, the SH mobile platform, this is what we'd like to do going forward and it's been done in such a way that people could basically copy our template and do add the same 50 lines of code, slightly different 50 lines of code for every board and I think that would be quite nice. So there are some people who are fundamentally opposed to the idea of using Linux as a boot loader. If you wanna do the single stage boot, which is what I just demonstrated where you go straight into Linux, that's okay but it's not really upgradable. It's okay for developers. So you might wanna do a chained boot and in that case Linux is a bit slower because it's bigger. Okay, so I guess if you wanted to use a generic kernel, then you probably would be in the two stage boot process where you'd use Linux as the boot loader and then you'd skip on. So for our passing command line parameters, you can, I mean they're compiled into the kernel. It's a config option but fundamentally on ARM at the moment there's a problem. You can't make an ARM distro kernel because it's impossible to make an ARM kernel that will boot on more than, certainly more than a handful of very related boards but essentially every board needs its own kernel compiled. This is one of the things that Linaro guys are working on. So once that has gone in and you can now make a distro ARM kernel, I would expect that those kind of questions will be addressed. Yes. So this guy is just a development board. People like me use it to develop code. So what Rinesa stars is they make hardware IP. So the different chips on this essentially, well not even the chips, just the IP. And the idea is that they eventually go into embedded devices, a lot of mobile phones, a lot of vending machines. So Japan's known to have a lot of vending machines and almost all of them have predecessors of the hardware that's on this board. It's, I mean, this is basically a hobbyist device as it stands, but the technology moves on and it finds its way. I mean it's a bit small, bit big to go in my pocket and actually one of the boards we have in the office is sort of this big, so I mean it doesn't fit in my pocket. But it's just development work. Any more? Ah, yes. Yeah, like about, nope, here. Right, so the question is do I have to do any MMU tricks or any tricks at all to achieve this? And the answer is it's way too early. There's no tricks at all. There's nothing too trick. This is only like sort of a couple of hundred instructions away from ground zero. Jump's work, yes. That was a question we were wondering during the development process, but which is why it was a particularly happy moment when it worked. Another interesting thing is essentially we don't really have interrupts. So typically your SD driver code is interrupt based. You send a request and then that interrupt comes back, we can't do that. That's okay, but except I don't really, the thing that makes this guy's okay, I have specs. This guy sort of, I got home and I was on the email. I was like, oh, so can you send me the documents through? And they're like, no chance. So basically this is, I have actually read, well reverse engineers perhaps too strong a term, but the way I got this loaded, the way I got this portion working over here as much as it does work at the moment is by examining the Linux driver, which of course uses interrupts. So it does things slightly different, but that's okay. I got it working. But this is really, really early on. There's nothing, there's no, this is why I use the LEDs for debugging. I can't print stuff to the console even. So life's simple, but it also life's difficult. Yes. Okay, so perhaps I should have spoken about the header which I didn't even draw on this diagram. It's a couple of hundred bytes which describes basically where this is, where it's gonna go. And we just write that raw to a location of the MMC which is determined in the manual. In this case it's at offset of one block, which is 512 bytes. Yes, we just, I used DD. The EESD stuff on that side is more interesting because one of the features of EESD is it has a boot petition. Not in the sense of petitions that we configure using FDisk, like actually in hardware. And it will go in there. And that's why I can't use a normal SD card because I don't have it. But yes, did that answer your question? There's a special header and we dump it to the device. That's right. The cards are reusable, but yes, yes. No, you can't have two images. I mean, you could, there is space for two cards, I guess. So maybe that might work, but. Okay, thank you very much for your time. And yes, sorry, one last question. Right, so the question is, couldn't we just, well, are there plans to use standard SD cards? I will certainly be encouraging that line of thought. Like I said, part of the job is to prove stuff. And even if it's not software, it's like to point out things that are obviously inconvenient. So what we want, or what the people who pay me to be interested in this one is for people to be able to buy this and to be able to do some kind of development on it. And using a JTAG is overhead. So this card thing is kind of worthwhile, but if it has to be an SD card, then it's, you've got to buy special equipment anyway. So the answer is, yes, I think that's a very good idea and I will try and promote it internally. Thank you very much.