 And one day we hope to recognize a little pinging inside. Ladies and gentlemen, I present you Mr. Ron Minich. Now it's the microphone working. I wanted to thank Faust then for having me here and obviously that it talks about Linux BIOS. Now sometimes people ask you what you're going to talk about and then you send them a paragraph and the paragraph is in your program and I realize this talk bears some small resemblance to that paragraph but it's not actually the same thing. So I'm just going to talk about what it is, why we're doing it, give you some idea of how it works and then talk about what the Google supported work is all about and then where we're going to go with it. So what it is is really exactly what it says it is that the plan starting eight years ago was that Linux would be your BIOS. And we need it. So we're going to take Linux completely out of the flash, put Linux in the flash, throw the PC BIOS away. How many people here like the PC BIOS anyway? I hope no one's going to raise their hand. We all hate its guts. So the goal here is to get rid of the PC BIOS completely. It's a 1981 piece of technology who needs it. And in theory it should be easy as Jim mentioned this morning. These computers are actually fast. It's just so that our software makes it feel slow. So getting Linux running in a few seconds is really something that is pretty simple to do. Who uses it? Here's a couple of supercomputers that use it. There are about 8,000 various types of computers that ladle the run Linux BIOS. This is the Kray XD1. Kray has been using it for some time. This is of course the OLPC, the iRobot Packbot. That's kind of a neat application. That thing actually is kind of a mind detector. And the thing you know is every time one of them gets blown up it means some human being can get blown up. So that's kind of a nice application. This is kind of neat. This is an FPGA card that plugs into a hyper-transport socket. So there are several companies now that take a dual optoron motherboard, take one optoron out and put an FPGA in. Or they have a card like that. That card was designed at Mannheim. Well what happened when Extreme Data tried to do that? They got a Sun Ultra 40 dual optoron machine. They took one optoron out and the machine would not boot anymore. So the super different proprietary BIOS was too dumb to boot the machine with one processor removed. So I did a port last summer of Linux BIOS to that machine and it comes up just fine with Linux BIOS. But the other really neat thing is it turns out, according to A&D, that the code in Linux BIOS that turns on hyper-transport is better than any proprietary BIOS that exists. If you get the open source BIOS, you're not going to get the proprietary BIOS. That's kind of neat, right? So we're really at the point where we're doing a better job than the closed source junk. So how many people use it? So this is kind of funny. We bought a 1000 node cluster here and we thought we'd kind of hit the big time with Linux BIOS. But compared to where we're going, and I mean it literally is a growth of 10. So that year we had 1, then 10, well I'm sorry, 10 and 100 and 1000 and it's a 10x growth every year. And you don't really realize what that means until you get about the year. Then you realize a 10x growth a year kind of adds up after a while. But the funny thing is the point here where we thought we hit the big time isn't even visible in this graph. Why would you bother using Linux as a BIOS? So the motivation for me is this column right here, Drivers. So you can use something like EFI, which is proprietary as we all know. That's Intel's BIOS that you're trying to get everyone to use. Yes it's extensible, you can do it in C, but the way you extend it is you get the 1,500 page EFI spec. Attempt to understand it, which I can't yet. It's a totally new API, a new program environment, you need a special GCC. You've got a DOS-like file system, you've got to live in that weird environment with a DOS-like command prompt and do a full custom driver. Or you've got Open Firmware, which is a lot better, it was proprietary, it is no longer proprietary. It is extensible and you've got to figure out how to write these drivers in force. Some people can do that well, I can. There's the PC BIOS proprietary, but if you're good at assembly you've got it made. So all you good assembly language programmers out there are set. I don't really like writing an assembly. The big thing here is, Linux, if it's my BIOS, it's not proprietary, it is extensible and we all know how to do that stuff, right? It's a driver. And most of the time somebody else writes the driver for you, so you don't even have to think about it. So do you like writing non-Linux drivers when working Linux drivers exist? I think all of us would just as soon use someone else's driver. Or this is the fun one. You know, you have a piece of hardware that works fine in Linux and fails in the BIOS. That gets really old really fast. Or if you write a driver for one of the first three, guess who gets to maintain it forever? And this is a nice thing, you know, we've been working on getting some of our code into Linux kernel. The neat thing is you're on a mailing list and you start seeing patches come in from all over the world to fix bugs in your stuff that you submitted. So it's a lot simpler and a lot cheaper to have the same drivers in the BIOS and in the OS. And that's part of the argument for having Linux as your BIOS. I should mention the DRM BIOS issue. This is a funny phrase that was coined by a guy I know at Google. We were talking about Linux BIOS and he said, well you know Intel EFI is just a DRM BIOS. And we talked a little more about it and here's the thing. The newer BIOSes have unlimited control of your memory and IO cycles. What's that mean? What that means is that in the chip sets, the chip and all your machines out there nowadays, the BIOS can set a bit and set an address range and any IO you do in a certain address range will get trapped to a system memory management node handler. At that point the BIOS can decide to veto your IO. But what's really fun is they also implement a full network stack. So how paranoid do you want to get? It is actually in the range of possibility that the BIOS could look at the kinds of things you're writing to disk from the operating system using the IDE IO ports. And the BIOS might get upset about the kind of data you're writing to the disk and send network packets somewhere. It's all possible. It's all possible today. How do you know what it's doing? There's nothing you can't by design. So that's a little worrisome, right? I've noticed some people with some banks that are very upset about this because what they've realized is they may be running Linux, but they don't know what's happening underneath. We had a long telecom with Intel about this and they were explaining the really cool aspects of VFI, the fact that things could get intercepted and EFI could take action for us. In fact, EFI could go out, find a server, download a new version of EFI and burn it to flash all without us knowing or intervening. And panic ensued at the end of that conference call because we had just been told that the BIOS was kind of able to go off and do things without any direction from us. So what we've required for the last six years when we buy a supercomputer, it either run Linux BIOS or more recently, they have to give us full and buildable BIOS source because it turned out IBM didn't want to let us run Linux BIOS. So what IBM did on the most recent machine we bought, they shipped us buildable BIOS source for that machine, which I'm never going to look at because I don't want to get contaminated, but this is the way we work and we did it for security reasons. BIOSes that can take action on their own are really a bad deal. More people should be worried about them than are worried about them. Linux isn't a BIOS only though. It's a bootloader too, right? Since Linux can mount and use all the Linux file systems, it can do everything you need done. It can do the Kexac, it can mount things, it's got network protocol stacks, it's got all the drivers you need to get the things. So Linux is actually a great bootstrap loader. What if you need a new file system? Well, it's always there in Linux. Do you really want to write a whole new set of file systems in the EFI environment that are enforced? And again, I don't. Somebody already wrote them. I don't need to do that again. So if you remember all those custom entries for drivers, we've got the same entries for file systems, network file systems, network protocols, wireless, you know, the list goes on and on. It's a long list. So the way we use Linux is Linux as BIOS and Linux as bootloader. We've measured this. It's the most reliable and flexible and fastest way to boot your machine. This is interesting. Until about three or four years ago, Linux was always a really fast way to boot a machine. And if we put Linux in Flash and Etherboot in Flash, Etherboot was always a little bit faster than Linux. At some point when the CPUs hit about two gigahertz, we discovered that Linux was always faster than Etherboot. And it's not that intuitive. Etherboot is this sort of direct, small kernel, polling I.O., you sort of intuitively think, okay, Etherboot has less overhead than Linux, it'll be faster. But what in fact happens is Linux has so much internal concurrency and overlapping of operations, it's actually the fastest bootstrap we've used. And the other fun part is, of course, these non-Linux systems tend to fail in unforeseeable and unpleasant ways, okay? And I have a friend who has 4,000 node clustered. And they came in one day, and every single one of the 4,000 nodes was hung. So they went up to one node and found out that the node said no keyboard present, hit F1 to continue. It turns out you can fix the problem in parallel. The parallelism is limited by either the number of people you have or the number of keyboards you have, okay? So if you can imagine 20 people fanning out, walking up to machines, bam, F1, bam, F1, bam, F1. It only takes a couple hours. So I'm not allowed to name the lab or the company because they're so embarrassed about it, even though it's been almost a year since it happened. What do you want to see if things go wrong? A lot of biases will do something really friendly like this. This is my favorite, actually. Can't boot disk, okay. And my reaction is, what is okay about this? I've never known why it's telling me things are okay because they're really not okay. And in fact, this is even worse than hit F1 to continue because if I know about F1, I hit F1, what am I going to do here? I've got to interact with this thing. In a supercomputer cluster, this is about the worst possible thing you can ever have happened. There are a few things worse than the okay prompt in a cluster. What you really want the node to do is always go over the network and talk to you over the network about what's going on, right? A lot of companies, and actually, I'll just say the generic big search engine company don't even hook consoles up to their clusters. I don't either, right? It's been years since I hooked up the consoles on a cluster. That's what the network is for. But what do you want to see if things fail? Well, if I have to have something that's going to give me this awful prompt, it really should give it to me over the network. But I want a shell prompt. I want a Linux shell prompt. I don't want this. I really don't want that. I had it for years on Spark Stations. That was enough. What if you want to extend the BIOS? Do you need to extend the BIOS temporarily for debugging purposes? Really easy on Linux, right? Mount a disk or a network file system, change your path, insert a module, whatever you want to do. Knock yourself out. It's Linux, okay? So you can trivially extend your BIOS if Linux is your BIOS with new commands or whatever you want to do. That's just really not easy with a standard BIOS. Sometimes you don't have any other options. So anybody who's got the new Intel chipset will find there's a new feature on that chipset. It's on that laptop which Stefan loaned me. It's called the Regulatory Demon. Has anyone seen this thing? You cannot run that wireless card without the Regulatory Demon. You can only get it as a binary. Yeah. You can now. Thank God. Okay. So there is a way out of this hell. That's good to hear. Nevertheless, if you need a WPA supplicant or if you're running something really complicated like Infiniband, that gets a little messy, right? In something like EFI or open firmware. And at some point, should the BIOS or the bootloader have modules and processes? Some people say, yeah, but at some point you're just building a bad OS. Why have a bad OS as your BIOS when you can have Linux? There's no reason to recreate bad OSes at this point. We've got a good OS. We know it can fit in flash. Problem solved. So for the future and more complex BIOS I feel Linux wins again. The newer drivers are getting really complicated. It turns out we need one less binary component than I thought. But still, you know, what's happening is people try and stretch the BIOS to fit the hardware and the other things that are coming down the pipe. They're turning into bad OSes. And EFI is just a great example. If you got your wireless up, go to openefi.org, download the 5 megabytes of that spec, realize at some point that it looks like a 1960s operating system and just think, why the hell are we doing this? I actually don't know. So what we say is go with a simple BIOS idea. Linux is BIOS, Linux is bootloader. Okay, how does this work? And this is where the real fun begins. This is kind of a summary of some of what we've learned over eight years of trying to make this thing go. First step is you've got to enable and bug fix the CPUs. Now, if CPUs is floral, I'll get onto this, but you've got to enable and bug fix the CPUs and very quickly stop all but one. For hardware, you've got to discover, configure and enable it. Pre-PCI, you really couldn't do this stuff, right? You had things like ISA, you had funky, you know, little ROMs and stuff that had configuration information, but once we got PCI and we got self-configuring, self-defining hardware, life got less than possible, right? I won't claim that PCI is easy even now, but it's pretty straightforward. As an aside, I'd like to say, I think OS is our original thought and hope was that the OS, especially when 2.4 came along, the OS could configure all the hardware with no help from firmware. That has not actually proven to be true. I don't know if we're ever going to escape the need to have the firmware do a lot of pre-work for Linux before Linux and the other OS can figure out what has to happen. What's the boot software have to do? They've got to pick a device. That you can do in a Linux RC. You can do further configuration. Again, this is boot software running out of firmware, out of Flash ROM. If config, SF disk or whatever, can launch DHCP or mount an equivalent and get some more information on the disk, maybe do a mount, validate it, that's a file command, boot it, that's kexx. This is kind of the steps of a bootloader. Everything is there in Linux you need to do to do that. We actually demonstrated that on OLPC. Before OLPC went to open firmware, the way it actually worked is it came up. We had busybox and Flash, that was in the NIT RD, in some versions we had the kernel and Flash. It came up, it had a Linux RC, it had a timeout, it would look around and see what was there, optionally boot something over a network or from a local Flash. I actually, the system I delivered to Extreme Data, which again was a Sunnel for 40, that also did the same trick. It came up with an Ashtrump and you could run a script to tell it what to boot. If you know how to make Linux do things, you know how to make Linux as a BIOS do things. The initial key idea was we thought Linux could do everything save to the lowest level hardware. This is the first version of Linux BIOS. It's pretty simple, it's four lines of code. It works like this, I hope I'm not going to move too fast. Mem copy jump. That's Linux BIOS version 0. It didn't work at all. It didn't have a prayer working as it turned out. The first problem was what I called a DRAM problem. Here's a DRAM module So here's a DRAM module and I don't know how many people know this but of course the DRAM module has a DRAM but the thing that's on the DRAM module that's not always apparent is there's this serial EE problem. Why is there a serial EE problem on a DRAM module? Here's the pants they're used to. C-Pute at North Bridge to SDRAM bus to DRAM. That's pretty straightforward. Here's the pants that not a lot of people are used to. C-Pute at North Bridge to South Bridge to Super IO in some cases or over here to the SN bus to the serial EE problem. Why are we doing that? The reason you do that is that DRAM module is a synchronous clocked machine. So there's actually a state machine here that communicates with the state machine here for memory cycles while there's timing in these state machines and the serial EE problem defines the timing in the cases which are common that it's correct but it defines the timing for this module. And so what you've got to do is configure up that bus all the way down turn to Super IO on or South Bridge SN bus hardware on talk to this, read the values in compute from those values and your knowledge of the North Bridge timing how to set up the North Bridge. Well what's interesting is you've got to do that with no stack. So you have no C function calls until you have DRAM and you have no DRAM until you do all that work. So you've got to do all this stuff DO over the I2C you've got maybe 17 fairly complicated parameters all of them interact. It's like having 17 springs that you can stretch. And then you've got to match them to the North Bridge so some of the strings stretch them too far because then the timing won't match. Then you have to program the DRAM and program the North Bridge. So that code is the single hardest piece of Linux BIOS and to give you an idea how messy it can get we had a project to do ported this to the G5 and we never got it because there were some bugs in the G5 chipset that we weren't told about. So this code though is just about the hardest thing there is to do on any machine and it's actually getting harder as time goes by, if anybody knows about DRAM training and the new DRAMs you actually kind of sit there and you actually train it and it essentially tunes the delay lines. There's a delay line for every bit that goes out to DRAM and that all have to be tuned slightly differently. So then there's a little bit more we have to do so it ends up looking a lot like this and some of these are empty on some things you did the display you set the PCI method there's methods one and two so you really want serial output as soon as you can possibly get it because it just makes your life a lot easier when you're debugging then you enumerate PCI turn the frame buffer on but you can't really do this until you have some idea what the structure of PCI is then you enable PCI initialize PCI initialize the CPUs and then this is essentially that mem copy more or less that I showed you earlier so there's a fair amount of work to do here and in fact some of this PCI code was ripped right out of 240 that's where we got it modified it quite a bit but that's where that initially came from SNP support is part of the let linux do it philosophy we actually had a guy in who in 2000 wrote SNP startup code that ran in linux so the idea was your motherboard had come up and linux kind of thought it was on a single processor board but it would do a little looking around and figure out that it in fact was on a multi processor board and start up all the other attached processors with the standard IPI mechanism and all that what was kind of neat about this is that nobody had SNP startup code in C it was all hidden in the bios as an assembly so we finally were able to create this code and have a reference essentially for how to bring up an SNP which was really nice to have then we got to the K7 and here's my theory on Panium SNPs there's hardware voting that goes on so they all come up and there's some kind of hardware voting mechanism and they all stop except one so there's probably a patent on that speaking of patents and so on the K7 it turned out there was no hardware voting they all just came up and started running and actually had to put the voting in software in the bios because we didn't want them all running the bios at the same time and that meant that we had to take that code that we had started to put in the Linux kernel and make it descend down into very early code in Linux I mean in Linux bios in fact assembly code so there's sort of for K7 is the sort of initial early vote step for who gets to run the bios in that what that really means it's an SNP bios at the time I kind of thought well an SNP bios seems like a fairly useless piece of software but then the optorons came along every optoron has memory attached to every optoron CPU you can now do memory initialization in parallel on optorons so the memory in it in an optoron is SNP on Linux bios so that was all going really well we had gotten to the point things were okay we had a half a megabyte flash 2.2 just fit right in there no problem but this became a big problem and Jim alluded to this this morning why is OLPC running open firmware when our initial efforts were all Linux's bootloader Linux got too big and it continues to get too big and you know it's been a problem down the problem motherboards went to a new form factor they went from the nice big dip parts it seemed to have about a half meg easily available to these little small parts that at the time were just quarter meg parts they were limited by pins so at the same time this guy was getting a little big the flash parts were shrinking so we kind of had to change things a little so this is what we this was the vision in 99 right this little Linux loader and Linux kernel this is what it meant in 2002 well a simple payload loader is now called Linux Bios we're doing things like loading plan 9 kernels and plan 9 loaders and Filo which is grub without Bios calls Mentest, Linux kernels and etherboot right so this changed a lot you know I'm from New Mexico we've got this t-shirt the t-shirt says New Mexico it isn't new and it isn't Mexico so I told Stefan about that and he said huh well this isn't Linux and it isn't a Bios because we don't support callbacks but you know we've got the name Linux Bios and it's kind of stuck and it does incorporate chunks of Linux kernel codes so I guess we can stick with the name but in 2006 we're actually getting back to where we began so I mentioned that as little square flash parts that only hold a quarter meg because they're pin limited the newer parts are called LPC and what they do is they multiplex the address in chunks and they get a big memory address it just sends it a bit at a time and you know the 2 megabyte part is not a big deal 16 megabyte part is not a big deal I saw this headline in electronics newspaper recently Nan Flash is free so the parts are getting big again and we know we can easily fit a kernel in a busybox a lot of busybox in 2 megabytes that's not a big deal and what we found when I talk to vendors and say I can give you a couple of choices we can put a grub like thing in there we can put an open firmware thing in there we can put a Linux kernel in there with a shell prompt response is always the same we want Linux people want Linux in the BIOS it's just the easiest thing for them to deal with then the next question to ask is is it working so that's where the Google work comes in what Google has done to support us with some money which is always nice and so Steph and Ryan are our core systems decided one of the things we can do is build this quality assurance system why do we need it what happens with commercial BIOS is when they go to a new motherboard they essentially fork the BIOS so you've got this code base this is what I've been told and the commercial BIOS company will take their BIOS and send it off to someone at that point it's a fork we don't do that in Linux BIOS we maintain a common code repository but what that means is that as people do things and change things at any given time we may have a motherboard that's not working and we'd like to know that as soon as we can but we can't afford to keep every single motherboard that's supported in house so what we need it is a way to have sort of distributed systems that report to a central system that we can test out new versions of Linux BIOS on so I'm not going to really talk about this much this is kind of a rough view of the test cycle but a lot of times what kicks this thing off is a commit from someone and the first thing kicked off by the commit is a complete build of every single Linux BIOS target so that's part of what goes on if any build fails then email gets sent out to the Linux BIOS list saying this thing just broke the test setup so there's an automatic build system run by this test server the test server in turn can control motherboards up to 16 and basically the test server can reflash the flash on that motherboard and then run it and look at the serial output and test it and see if the thing came back up now the neat thing here is every once in a while you'll flash a BIOS and the potential is to turn the motherboard into a brick at that point you flash a BIOS and the motherboard's gone but the hardware that Stefan set up allows us to recover from that because there's actually two flash parts the flash part you can fall back to if you really mess things up and recover so we start with the Linux BIOS tree we do a full A build for the A builds to succeed we control those motherboards and then do the testing and see if it works on a given board so this is kind of neat this is called a BIOS savior to solve that problem this plugs in, there's a little tiny flash part here, this is the part you re-program and potentially program with a bad BIOS and over here is the one you recover from and this little USB module essentially electronically controls the switch that flips between the two so that's how you can take a chance where you might brick a board and still recover from totally trashing the flash part being able to get the board back so here would be the central repository at openbios.org these would be different vendors so here's a vendor, this guy runs two systems under test these are different guys running multiple systems under test and so on so the idea is that we can have MSI and tie-in and other vendors set up these things centralize the reports and make them accessible to everyone I don't think anything like this has existed before for BIOS because the vendors tend not to care about an older board or someone else's board fails but we have a lot of cases now where this vendor will find a problem in a chip and that will actually fix this vendor's problem and we're kind of hoping the vendors are going to pick up on the fact that they're really somewhat in the same boat here that they can actually benefit from each other's knowledge of say the NVIDIA CK804 the ins and outs of that chip and if you fix it for one it's all it is sort of happening MSI has a full-time Linux BIOS person now and so does AMD so people are kind of picking up that this is exactly the Linux dynamic here applied to the BIOS so these BIOS's image are built by the AutoBuild tool and then we've got these daily snapshots of the images this is kind of neat, I like this I'm terrible at this but stuff is very good at it there's a test name here it's very hard to read but this says banner, copy to RAM jumping to Linux BIOS Linux BIOS and RAM and so on and this is pass, pass, pass, pass failed, failed so you can see your SVN rev number the target board the failed and passed you get a really nice test summary and the idea here is say MSI might only have two or three of these pages they're monitoring and they will get an email kicked off to them when a commit happens and anything goes wrong so Stefan built this thing he's using deja vu this is kind of nice you can really test it all the way up to Linux Timer interrupts and do your IDE drives work and that kind of thing so it's a really good assurance that you've probably got things right it's kind of interesting but if you've messed up the interrupt tables the first thing you see it sort of says I always forget the message calculating Bogo MIPS or something and then it never comes back that means Timer interrupts is just gone so I don't know if this applies to anyone here but core systems is looking for people to join in with this thing so the future work what I've talked about here is version two what happened was everything was version one and the Opturon came in and the Opturon was so complex and so far beyond what we were used to because every Opturon essentially had three processor buses which we weren't prepared for a number of things came along and kicked off version two so version two ended up being very complex to deal with systems like the Opturon what we're doing with version three now that we kind of know how it's got to look is restructuring the code and it's for casual users but it doesn't really mean guys who just run AVI Word it's kind of casual BIOS users what we're really talking about is an engineer who might spend one day every two weeks working with the software doesn't have time to really learn it in depth but wants to use it so that's what version three is oriented to we've moved to Kconfig that we hope will make a more familiar environment for people we've greatly simplified the code pass because after a couple of years you may have a lot of flexibility in how you construct an assembly code file but if every component of that file is not changing more than about every three years there's no reason not to just put it all in line in one file we had complaints about the amount of usage of include people don't generally like include load scripts we had made use of load scripts but I think we were doing a little more with load scripts than people are used to so we kept tickling bugs in the Canoe Benutils it just seemed like we did that about once a year or twice a year you'd start building images and they wouldn't boot at all and you trace it all the way back and find out well Canoe LD GCC is generating new segment names or Canoe LD is somehow not doing the right thing so we're really minimizing our use of features in Canoe LD we actually had a C compiler in the tree and that was done to minimize the assembly code this was written by Eric Biederman ROMCC was quite a trick because what it actually did is it could compile an ANSI standard C program in a way that it used no memory so it's 25,000 lines in one file optimizing C compiler there are a couple bugs but it was really an incredible piece of work because it basically could tell it oh you're in a penny and whatever use MMX registers or you're on this use streaming CND registers or whatever and it would basically use the registers and nothing else and that's what you've got to do in that early step where RAM is not up so you could actually write C code and compile it and then you'd have this assembly that used no memory but the problem was that that's a big maintenance effort and we've just learned how to use a newer or better thing called caches RAM and basically on the paniums and power PCs just about everything nowadays you can pretty much play this little trick and all of a sudden the cache memory is kind of acting like RAM for some period of time so we're moving to all caches RAM and that means the only C compiler will be GCC and we'll still have very minimal amount of assembly code. There's about 100 lines of assembly code in a given Linux BIOS and politics so you can't escape politics when the opposition to what you're doing is non-technical you know I don't know we started this project and we thought that the benefits were so obvious that after a year we'd get companies in working with us but what actually tends to happen is you get a lot of opposition because you're pretty much selling the BIOS vendors they can all go out of business now and you're kind of telling Intel we'd really like you to continue to release documents about chipsets which they don't release anymore by the way so what's happened in the last 8 years when anyone knows about developer.intel.com I mean the 440LX chipset you pull the documents there's a tutorial in that document about how to program SD RAM okay 3 years later the newer chipsets there is nothing in those books about how to program SD RAM and in fact there are notes about there are certain registers we're just not going to tell you about unless you get an NDA so you know once we started using the information that was posted the information in the case of some vendors just vanished so we kind of have to deal with this political stuff the other thing is we're really trying to show vendors they can make money even if they let us do Linux BIOS the cool thing that just happened about 3 weeks ago is NVIDIA let AMD release all the programming information needed to do the Linux BIOS port for the NVIDIA chipsets that covered 4 vendors so there was an MSI, a Gigabyte a tie-in and a super micro motherboard using this particular chipset so about the same week probably the same hour for all I know that NVIDIA okayed the release Yengai Liu at AMD released Linux BIOS for all these boards it was a wonderful day the discussions with NVIDIA began from my end in 2002 and what they told us is tell us how many million chips you will increase our sales by in a year and we will release that information so if we can show vendors there's a business case and that's what happened with OLPC then they'll be on board so you can't really demonize them but they can be very frustrating people to deal with sometimes and of course continue to evangelize so a lot of people will maybe remember the IBM PC it came out and the BIOS listing was part of the package you got there was this sheet of paper that was the BIOS and what people didn't realize it was closed source that was copyrighted people had to do clean room re-engineering of the BIOS so what we've shown is the highest quality BIOS can be built using free software and it really is it is a good BIOS it was interesting to have AMD tell us in an open meeting that the hyper-transport software and Linux BIOS was better than their hyper-transport software and in addition better than anybody's hyper-transport software that was just a shock but we've seen other cases it's so hard to set up DRAM that a lot of times what the BIOS vendors do is they don't do a very good job so you get fast DRAM they run it just slow because we've found in a lot of cases we do a better job of programming DRAM than the proprietary BIOS we've had the millions mark about a year ago it's in a lot of systems you and we have never heard of I get a phone call once in a while and somebody says ah one of the ones I got was really funny there's a telegram that made a turkey and they make 15,000 of these things I forget if it's a month or whatever and it's digital and they found out that when they ran it with a PC and people turned it on they didn't like waiting 90 seconds for the image to come up so they put Linux BIOS in it and then the image came up in a couple of seconds and then people were no longer angry with them so it's just weird things come out from nowhere about usage of this stuff one of the great remaining things is to get it into your laptop and we don't know how to do that right now there was a DARPA project that was founded a couple of years ago DARPA gave IBM money to put Linux BIOS in a laptop we were working with them and the part of IBM that did laptops did not want to tell the part of IBM that got this money how to do it they told them to go pound sand so IBM isn't always very friendly to IBM of course the laptop part of IBM got sold so maybe there's some justice there but it wouldn't have been really cool so if anybody has clever ideas about who we can talk to or how we can get this in a laptop we're willing to listen and talk so let me just show you one more thing if I can this was pretty exciting first off we don't know the guy who posted this so this is just an announcement first desktop motherboard supported by Linux BIOS Gigabyte blah blah blah but what was really cool is AMD essentially said we're supporting this this is where we we've been trying to get for eight years now get to the point where someone at the level of AMD and Gigabyte would say we're supporting this now where we're not okay notice this is like a part number right but that part number means I don't know Phoenix or something what we wanted to have is M57SLI-S4-LB we wanted to be the case that you go to New Egg or something and you order this part and it comes and Linux BIOS is on it that's the next hurdle but actually getting AMD I mean AMD has just been great for two years now they've just been absolutely incredible but having AMD sort of say oh yeah we hired this guy he does nothing but Linux BIOS full time and by the way we're releasing support for four motherboards that was actually a really big deal and that was just February 22nd of this year so I guess that's it do we have time for questions or did I run over? Will it boot my operating system of choice CG OpenSolarOS sorry will it boot up other OSes like OpenSolarOS once it's done all the hardware initialization? What was the first part? Will it boot any OS I like? Oh okay so there are problems with different OSes so years ago I tried to do FreeBSD because I used to do FreeBSD a lot FreeBSD still wants to make BIOS calls if your OS makes BIOS calls you're out of luck your OS shouldn't make BIOS calls it's a bad idea but some of them do I'm sorry somebody told me they've done it okay the OpenSolarOS guys are here we could walk on down and say hey do you guys make BIOS calls or not if they say no and the other thing we can do I've got it running an emulation on QMU we could just do it just test it and see what happens so that would be kind of interesting what's this? Windows Windows we actually had Windows booting under Box BIOS years ago but it was pretty painful what we'd like to do is try to react to OS guy again and have him talk to us about freeloader so is that what you were asking? I'll just second everything but will this in theory do you need to do some hardware do you need to do some hardware changes to motherboards to be able to run Linux BIOS or any other software Flash ROM you just reflash the flash and you can do that in place you have a program called Flash ROM that lets you do it so from the web page you can see from long ago I used to add one address line for making the flash parts bigger but I haven't done that for years so yeah I'm using some clusters I like to the idea of the Linux BIOS project so getting started I can get for making my system compatible with your list today you have a list of hardware that is working with Linux BIOS I can help you to having some more system available meaning I can help you to make my system working with Linux BIOS what should I need to start you should send mail to me sorry you want to know how to make it work with your system I didn't quite understand I'm sorry I have to send you an email for starting so my main question is I have some bugs I want to be supported to Linux BIOS I have some basic knowledge of other hardware works so I can get started in making my system compatible with Linux BIOS what should I need maybe an EEPROM programmer actually the main thing you need is knowledge of the chipset so I haven't used an EEPROM programmer since about 2001 we do all our programming on the motherboards and a chipset guy pioneered this and told me it's safe we actually unplugged the flash part while the board is live plug and do one in and program it the main thing you need to do is get on a mailing list and send us an LSPCI that's always the first point LSPCI and then we can talk about whether it's possible so it would be great to have you involved install Linux BIOS okay so the question is how do you install Linux BIOS there's a couple ways you can go at this it depends on how daring you are I get on the mailing list to start and ask if anyone else has had experience with the motherboard you're using and sometimes I just send people an image Jordan Krasen AMD has built a utility build ROM and build ROM will allow you to basically lay out your motherboard and you say make it pulls down the kernel it needs it pulls down the Linux BIOS it builds the right version of Linux BIOS for that motherboard and when you're done you've got an image that has a kernel and an NRT and a Linux BIOS image which you can just flash but the mailing list is usually the best place to start to make sure you know what you're going to do not everybody wants Linux and flash some people just want the grub like loader so it would be good to talk to the mailing list and see what's possible alright thanks