OSDev.org

Good day ,

I hope I can make sense of what I want.

I am wanting to write my own UEFI (The one that actually replaces the BIOS). I Now I have looked online and perhaps there is some confusion on keyword definitions but I am finding what I think are tutorials on aspects of UEFI development.

I found this but it appears to be for developing a UEFI filesystem on disk where UEFI applications would be stored. Are these one and the same? Because I thought this to be different because it's stored on disk .

http://wiki.osdev.org/UEFI

I am thinking on grabbing the UEFI bios that comes with VMware and stripping all of it out and adding my own parts , but I think it would be good to understand what I am doing in more detail.


Where can I read or find a tutorial on replacing a BIOS with UEFI?

Does my question make sense?

I've got to say that if you had the ability to do this you wouldn't need to ask the question.

Why do you want to write your own UEFI?

iansjack wrote:I've got to say that if you had the ability to do this you wouldn't need to ask the question.

Why do you want to write your own UEFI?

We wouldn't need to ask questions if we had all the answers

This for me is understanding and learning. I can program in assembly and C but I want to roll a custom UEFI. I will eventually find an answer and have a solution, but I thought it might be worth asking here. I mean , this is a OS dev wiki.

Firmware (i.e. UEFI or legacy BIOS) contains mainboard-specific code (e.g. for initializing DRAM controllers before you can use the RAM). Furthermore, it is almost always undocumented. Take a look at coreboot. Good luck.

Hi,

Krash wrote:I am thinking on grabbing the UEFI bios that comes with VMware and stripping all of it out and adding my own parts , but I think it would be good to understand what I am doing in more detail.

If I can make a suggestion; port the Open Virtual Machine Firmware to Bochs.

This is probably the easiest way to get started (e.g. Bochs requires almost no chipset/motherboard initialisation at all, and everything is open source and nothing is undocumented, and there'd be experienced developers for both projects that are probably willing to help you if you get stuck); and it'd also be something that would be very useful for everyone using Bochs.


Cheers,

Brendan

Let me be blunt: you can't do it. No one here can, unless they happen to have proprietary, hardware-specific details of the exact motherboard model they are using directly from the mobo vendor (which usually means signing an NDA, if it is possible at all)

And even if you could, it would only work on that exact, specific model of the motherboard. Even other motherboards which are nominally 'the same model' may have sufficient differences in (for example) the USB host controller or the audio subsystem, that the support for those parts wouldn't work on different variant models - motherboard vendors have a nasty habit of not telling you when they are second-sourcing things like audio synthesis chips or USB host controllers, meaning that the 'same model' may have different actual (for example) USB host ASICs. This is a headache for OS development, but for developing a BIOS (legacy or otherwise) it is a showstopper unless you have the proprietary details.

The mobo vendors, who know these details, get around it by putting the code for all of the different models into a single firmware blob, and let it figure out at startup which specific one it is. They don't tend to share the information needed for this with anyone.

Basically, if you want to write firmware, you need to either get a job with a mobo vendor and ask them to train you, or break out your soldering iron and EEPROM burner, fire up some PCB deisign software, buy the chemicals and/or equipment to make your own printed circuit boards (there are a few different ways to prepare a one-off PCB, and some 3D printer setups can handle it for you rather than you messing with toxic chemicals in your kitchen sink), an off-the-shelf CPU (stick to something simple like 6502 or AVR, don't bother with a x86 or even ARM as those will be too complicated to work with on your own unless you're already experienced with this stuff), and make your own computer by hand.

That could be an interesting project, and no as hard as a it might sound, but it isn't a small task. It would still be easier than trying to write firmware for someone else's motherboard, though.

Hmm I understand.

@Brenen, I like the idea. maybe I can do something like this.

@Schol-R-LEA , Thanks for the strait answer; Saved me a lot of time.

Hah! I'm writing my own UEFI. Why? Because I don't want my OS to depent on such a thing as uboot. More seriously, I thought it would be helping in learning how to do an OS. And it is! Now I am writing Memory Boot Services, it's a lot easier than that of OS's (mostly, if to not count very dumb requirements. UEFI did for Memory Services).

But. I don't know how it's possible on x86 boards, because yeah, DDR (DDRC and DDR PHY) init is kind of not exactly documented. I even don't know how it is with Intel and AMD.

Ironically, initializing SDRAM is one of the few things I've done with my first target Mips Creator CI20 board. But the manual only had DDRC registers description and nothing else. No explanation how it works, no DDR PHY at all. I actually just rewrote in mips assembly the code from uboot, making some differences where I understood and wished. uboot, in turn, got it from Ingenic's BSP code, that they gratefully had opened.
For the next targets, having Allwinner's SoCs, I've got SDRAM init code "secretely". Thanks to one good person. But the manuals here don't have DDR related things at all. This is how it is.

So, I decided to write it on only a few of boards (6 maximum, 1 mips32r2, 3 arm32v7, 2 arm64v8).
3 of them come from the same SoC vendor, and it's hopefully will be helping with getting the needed info (they even follow me on twitter! xD), 1 is well documented, 1 is moderately well documented and 1 is android set top box where the SoC vendor is good at emailing but I am waiting on their "help" with NDA signing for like 3 months. Of course noone wants to mess around with an enthusiast with his/her napoleonic plans.)))

But as I am getting experience, I am more and more into jumping in OS developing.

Actually I was thinking on this - I have code in C, implementing Boot Services, so it is "already" done for x86 too, what if I tried to replace this BIOS thing. But then I thought - probably Intel doesn't release even a tiny bit of information on their chipsets. even compared to these ARM SoC vendors, that at least try to release something loosely looking as a documentation. I hate to admit it, but these vendors mostly are forced to do so due to GPL. Just because there is nothing except linux and uboot on these boards, they use them and they have to open something. Not everything of course. SDRAM init code might be separated even from uboot.

If you have all the documentation for hardware, then writing UEFI is like writing DOS. Easier than multithreading preemptive SMP OS. Good luck!

How to replace BIOS with UEFI? Reflash SPI NOR flash with it and you are done! It again boils down to the availability of the documenation from HW vendor.

In my case "feeding" my FW to the CPU ROM code is the matter of jumper/button/SD card manipulations. For example on CI20, there is a jumper. If pins 1-2 are shorted it boots from NAND flash where uboot resides. If pins 2-3 are shorted, ROM code happily boots from an SD card, where I put my SEC phase into sector 1. Thanks God, FAT partition is at 2MB farther so the entire UEFI could fit in this gap. For these boards, it's specified - the boot sequence, boot selection etc. On CI20, FW can sense boot selection pins and know where it has been loaded from, so that it can proceed there. I take advantage of this, because I don't need to initialize SD controller again, I just start to read it. How it is for PC? First, there probably is no such a rich set of boot selection possibilities, so you need to replace BIOS from the start. Apparently you need to get an info on how to flash NOR and know what the CPU expects there. And of course - know what to do next. Your SEC or PEI phase will init and test SDRAM from there, then load there DXE and transfer control at it, and that is the full UEFI environment, supporting everything what is needed for BDS, and this is not something NSFW, it is the Boot Device Selection phase, Boot Manager, dealing with what OS loader (or utility) to boot.