 Hello everybody, I'm here to talk to you about Open Source BIOS at SCALE, so who we are. We are basically an online scaleway, it's an hosting company from the French Telecom Group ILLYAD, ILLYAD is better known for free telecom. What we do is we build our own data centers in France, and in our data centers we build our own some of course. Yeah, I try. So we are hosting company, online the debuxes to the brand we have for server hosting. And SCALE way is the brand of our cloud service. And to provide the service we have data centers that we manage ourselves, we build ourselves. And in those data centers we put servers from there and we put servers that we built. And in those servers there is an ARM32 offer that's called C1 on our cloud service. It's basically, I think we were the first to do a cloud on ARM32. And then we want to more x86 kind of server with Intel Avoton. And the new ones, the one I will talk, the rest of the talk is the Denverton chip. And SCALE way is hiring, so if you're interested in those kind of jobs, come with us. So what we did is we developed an open source BIOS. What was your requirements? Basically bring up the board, do pixie booting, so boot from the network. Have the OS ready, so we need ACPI tables and stuff like that so that the OS knows how much CPU you have and how to change the speed, et cetera. We need some interface with our BMC so we can do a remote console and configure the system from the administration network. We need a secure dead process. We need to be able as a hosting company to update the BIOS and not our clients to flash their BIOS if they wish. It's our job, not theirs. And I think I did everything. And why open source for that task? Retried BIOS vendors. Basically they sell you something that almost works but does not really do what you want. They give you some sources, they give you some binaries. Whenever you have a question, you have to ask the person and they're not quick to answer you and you pay extra for that. So it's not really a good solution. And basically what they're selling to you is the initialization of the chips that's from Intel. They are giving you an UFI stack that's basically from Chernocore. And they are legacy BIOS and a very nice menu with the mouse clicking to configure your system, which we don't need. Another solution was to use Intel's reference BIOS but you're not allowed to do that. They give it to you just for testing but you can't go in production with that. And none of those solutions did cover the interface with our BMC. So we needed to develop something so we went for open source to do that. So mainly there's three components. Coreboot, which is open source, community-driven effort. FSP, which is the black box from Intel. And Chernocore, which is the UFI stack. So Coreboot does the early init. The first step that's run is from Coreboot. Then it passes to the FSP to do the memory training. Gets back to Coreboot. We do the multiprocessor init. We prepare the CPI table and stuff like that. And we need to call the silicon init from Intel. It's doing more fuel stuff like locking some registers so it cannot be changed afterwards. And then we run Chernocore. Basically it could be unchanged using the Coreboot payload from Chernocore project. We did a few changes in there also for the BMC support. So basically we took all that and it worked. It almost worked. First, I was still learning the Coreboot cost base, et cetera. And your system boot, you're happy. And you're on Linux. And you have high-end CPU and it's running at 800 megahertz. Wow. So you start searching on ACPI how to configure those speed step features so that the Linux knows how to change the frequency, et cetera. It still doesn't work. And then you go somewhere, you read the Intel documentation and you have to configure some stuff. So you look into the Coreboot how it's done for that chip, et cetera. You mostly find stuff that looks like, but it's not the same chip so it won't work. And at some point, what was in my documentation and what was on Coreboot upstream, Apollo Lake support was like, this will do the initialization, but it's not really documented. Okay, should I use that? I asked Intel support. They said, yeah, yeah, it's that code. So I integrated it and that was it. It was booting and running at 2Gerts. There's some other stuff. That one is found with the NVME drives. That one from Samsung is working fine and the one from Intel was not working. So we had several changes with the Intel support and they finally found out why. So it was some configuration failure, but we couldn't find it easily because we don't have debug tool for PCI Express. So what's good, pros and cons? I start with the cons. It's a little longer to develop than using BIOS vendors. We don't have the nice graphical menu. Yeah. We don't have legacy BIOS support. We could have used CBS for that if we really wanted, but we didn't. Intel's bug were for us, not for the vendors. So we had to talk with them. We don't have BIOS vendors support, but we had Intel support. And that one is important for the community. Early contribution is hard. Basically, the first version of Coreboot that we had was before the chip was even released. So it was under NDA and we didn't have the right to talk about it. Then nobody knew about it before it was out. So we couldn't contribute at that time. And when Intel contributed something to Coreboot, it was a totally different code base. So basically what I have to do now is rebase everything and redevelop some of the features to contribute. And then in the process of doing it. The good thing is most of the code is already there. Even more now on Coreboot. Basically it works. It's as fine as the Intel reference BIOS. Performance as air, disk architecture, everything. We have some more features related to LBMC. We can configure the UART for the console to display information about BIOS or not, stuff like that. Which are really useful for debugging, but we disabled them in production. So it's easier to have configuration there. And about the flash. Basically, the system LBMC locks the flash. And the Intel FSP is configuring the flash controller to protect also the access to the flash from the host. Basically in a regular system only the ME component has access to the flash once it's booted. And when we want to update, we want to use flash from Linux. So we have a special mode where we go around the protection setup by FSP so that we can write to the flash. And one good point too is when discussing with Intel on the memory reference code, this code has a lot of information about the training of the DDR. And we wanted to get those information for our inventory. So we wanted those information to be displayed on boot. And basically Intel planned to release the version that's released on GitHub of the FSP without those features. And I told them, yeah, but we need it. So at first they said, okay, we'll give you a special version on the NDA. And finally they said, oh, we did put the version with the MRC code on GitHub. So thanks to us, everybody has access to that. So it was indeed investment. Yeah, scale we had to hire me. But it was useful. And we're really happy to have the control on our birth stack. So that was just a few toe-toe type. And it's going fine. Yeah, by the way, we are producing lots of those. The next scale we run on those. Any questions? Yes? We are talking about training the DDR. What do you mean by training? Yeah, basically when DDR3... The question is for... Yeah, okay. The question was what training the DDR means. But if you are on DDR3 and 4, the link between the CPU and the DDR, it's like a small network on board that runs really, really fast. And it's not like you put one, you get the one at the other end. It needs to fine-tune the way it controls that. And the specific code to do that, we don't have it. It's anti-appropriatory. We don't even have the data sheet of that part. Yes? In your case... Yeah, what about the maintenance engine? In your case, we are a direct Intel customer. And we are using it. The maintenance engine has the role to bring up part of the platform. Yes, we know that at WAT, we don't have those features in the version we have. We know it. But, yeah, it's part of... The stuff we have under NDA are the same as the other manufacturer. We are like... Yes? Okay. What's running on the BMC? Basically, our BMC is a small microchip. And we implemented the APMI. Basically, we have a UART forward to TCP port. Well, UDP port. So it's not a full standard APMI. It's really just the feature we need. And then, we have applications that run on other computers in our network to handle the tasks. It's not a standard APMI. Yes? First, a second question. One people, me. And how long I started... I think it's about six months... A little more than six months' work. It's been more than a year. But during that time, there was BIOS development, BMC and stuff. And when you're waiting for the support and you have no clue about the specific bug, you switch to something else. So it's more than a year. But it's probably six months. Learning core boots, learning EFI. And that one is a pain. And tweaking those stuff, et cetera. Yes? Are we planning to train learning boot? Yes. As I said earlier for contributing, I'm still in the process of streaming our changes. And I see it as a requirement before training boot because it's integrated in latest core boot. And then, we'll see... As a developer, I will try it and we'll see how to deploy it and whether it has benefits or not, et cetera. I think that. If there's no more questions, then I'd say I thank you everyone for being there and probably see you next year.