OSDev.org

Alright, this is something that has been on my mind for quite a bit of time now. Let's assume the case of 99% of desktop PCs today - with an Intel (or AMD) x86(-64) processor. The Intel manual says that on reset, the processor starts off at a specified reset vector (in unreal mode technically?). This reset vector should be a system physical address that would correspond to the BIOS flash chip (which is simply memory which contains BIOS code which is executed by the processor). The BIOS code (it should be simple x86 code right? After all, it is executed by the x86 processor) does a TON of magic now, including but not limited to copying the BIOS code into DRAM and remapping the physical addresses in the system agent (that is, the same physical address of BIOS would point to DRAM now).

Here is the issue, whatever is done at startup is just x86 instructions executed by the processor right? So if the BIOS code can remap the physical addresses to any place it wanted, why can't I? Or can I, but it is implementation-dependent? How does this remapping even occur? What sort of instructions would the BIOS use to achieve this? I/O read/writes? I'm not sure.

P.S. I've always used BIOS code instead of BIOS, because after all it is just code, and I don't want to portray the BIOS as some sort of entity/being who does something (The BIOS configures PCI? No. The BIOS code does)

There are a couple of reasons. For one, there may be trap door switches, that can only be switched one way and are then only reset after a hard reset. Second reason is that the BIOS is running from ROM, and is therefore free to remap RAM, since it will not be pulling out the rug from under itself. Your code, however, is running from RAM, so if you attempt stuff like that, you may quickly realize the limitations of that. Third reason is obviously that the BIOS knows the system better than you, and immediately knows how to talk to the hardware to achieve the desired effects.
Maybe you can. Ask the memory controller hub. Intel has data sheets on a lot of them, so look them up and try to make sense of them. They went a little over my head, but maybe you'll be luckier.
A distinction without a difference. Any program is just code. So is your operating system. And we still treat operating systems as entities (Windows finally let me log in; Linux couldn't find the file; etc. pp.). Indeed we do so for most programs.

Yes, I was wondering about what kind of 'one-way' actions x86 has (the jump to user mode is something of that sort, is the BIOS-bootloader jump something in the x86 manual? I don't think so). Moreover, it's not only BIOS shadowing that is 'magical'. MMIO configuration, etc. is also done by the BIOS (0xb8000 for VGA text?). If the BIOS can do that, theoretically can I remap VGA memory? This is the question.


Well, this is what is often taught isn't it - The way it is taught makes software look like a magical entity which you want to abstract out (and that's good most of the time). The reason that I wanted to emphasize calling it code is because I didn't want the BIOS to be treated as some sort of magical entity, because I want to understand how it works. I find the difference quite important .

No, not the processor. The external hardware! Some hardware exists that allows a register to be set one way once, but ignores further attempts to write it, and will only reset with a hard reset of the machine. In fact, I believe the whole "system management mode" setup works essentially in this way. Once locked in, nothing can change it. In this case, there is even some hardware that does allow changes, but only while the processor signals that it is in SMM. And since SMM is locked down so tightly, you cannot control it.

So there is a fourth thing the BIOS can do and you can't: SMM.
VGA memory snooping is very well defined, actually. What happens there is that a special VGA compatibility flag is set in every PCI bridge between the host and the graphics card. This tells the bridges to react to transactions in the VGA address range (don't remember if it was 0xB8000-0xBFFFF or 0xA0000-0xBFFFF, but it was fixed). Additionally, most graphics cards have to be told to also act on those transactions, and how exactly that is done is only for the option ROM to know.

The point is that you cannot remap VGA memory, since those PCI bridges only listen to one fixed address range. The only thing you can do is make them stop listening for those addresses. That allows you to free up that memory, but on the other hand, the times when 128kB of RAM were worth investing time and effort into are well and truly past now. I don't even know if there is any RAM backing those addresses. Would be a cruel turn of fate, wouldn't it? To invest all that effort only to find a memory hole underneath the VGA area.
There is nothing magical about being an entity. You and I manage it every day quite effortlessly. The BIOS is a program, just like the OS kernel is a program, and the keyboard driver is a program, and the Firefox I'm typing this into is a program. Each has their own responsibilities, and one of BIOS's responsibilities is to set up the PCI bus for MMIO. Nothing magical about it.

If you seriously want to take a deep dive into BIOS code, I suggest you read some of the Coreboot and SeaBIOS code. Truly enlightening about some things.

Of course, there's nothing stopping you writing your own code and updating the BIOS ROM. But you'd probably want to get it right first time.

According to one recent Intel CPU datasheet (and its corresponding PCH datasheet), it is not possible to remap the physical addresses used for the BIOS ROM to anything other than the BIOS ROM. The only remapping allowed is a simple swap between two blocks of the BIOS ROM to allow recovery from power failure during a BIOS flash.

I expect the same is true of all PCs, not just ones using that particular Intel CPU and PCH. Being able to remap the BIOS is a huge security risk, since the BIOS controls SMM.

You might be thinking of the legacy BIOS area (0xE0000-0xFFFFF) which is always RAM on modern PCs, but on very old PCs could be mapped to either RAM or the top 128KiB of the BIOS ROM.

There is actually a hobby BIOS dev scene (mostly Coreboot I guess) but AFAIK there are ways to do it safely (external SPI flash devices).