I had a question about some of these passages, as they appear contradictory and or incorrect.
>"Most registers of the x86 CPU have well defined values after power-on. The Instruction Pointer (EIP) register holds the memory address for the instruction being executed by the processor. EIP is hardcoded to the value 0xFFFFFFF0. Thus, the x86 CPU is hardwired to begin execution at the physical address 0xFFFFFFF0. It is in fact, the last 16 bytes of the 32-bit address space. This memory address is called reset vector.
This says that the EIP is doing a JMP to an address in RAM not a memory-mapped IO address which points to ROM where the BIOS is stored.
>"Now, the chipset’s memory map makes sure that 0xFFFFFFF0 is mapped to a certain part of the BIOS, not to the RAM. Meanwhile, the BIOS copies itself to the RAM for faster access. This is called shadowing. The address 0xFFFFFFF0 will contain just a jump instruction to the address in memory where BIOS has copied itself."
The second says that the CPU is doing a JMP to an IO mapped-memory address which points to ROM.
So the first passage says that CPU is just doing a JMP to 0xFFFFFFF0 in RAM. The second passage say that the CPU is doing a JMP to memory-mapped IO address which points to ROM.
Are these not completely contradictory or am I reading this wrong?
It's always been my understanding that that reset vector always pointed to a memory-mapped address which was located in ROM. Since the BIOS' POST routines contain code to initialiZe and test memory(the BIOs will actually emit beep codes if no memory is present or memory is faulty.), this would be a chicken and egg problem.
Also the post mentions the chipset loads the BIOS into RAM as a process called "Shadowing" which was done because ROM used to be slow. But since BIOS ROM these days in generally NAND flash I don't believe this is the case any longer.
Also these two statements appear to contradict each other:
>"All x86 processors begin in a simplistic 16-bit mode called real mode. The GRUB bootloader makes the switch to 32-bit protected mode by setting the lowest bit of CR0 register to 1. Thus the kernel loads in 32-bit protected mode."
>"Do note that in case of linux kernel, GRUB detects linux boot protocol and loads linux kernel in real mode. Linux kernel itself makes the switch to protected mode."
The first states that the kernel loads in protected mode and then the following states that kernel loads in real mode.
Grub itself is mostly written as a 32 bit program (almost it's own OS by now, actually). The x86 Linux kernel does expect to perform the protected mode switch on its own in the early assembly code right before the zImage decompression starts. So Grub has to switch back to real mode in order to jump into this part of the Linux kernel.
Grub has other ways to boot kernels. I once used a method that looks for a specific signature inside the kernel blob that would tell Grub to stay in 32 bit mode, put the blob at a certain memory address and jump into it. This was a feature of Grub 1 back in the day. I do not know if it was removed in Grub 2.
Thanks, yeah I guess I hadn't really thought about who flipped the protected mode bit Grub or the kernel before. It's documented here in the section "3.2 Machine state"
>"When the boot loader invokes the 32-bit operating system, the machine must have the following state
...
‘CR0’
Bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits are all undefined."[1]
However it sounds like Grub also understand the Multiboot Specification so can keep protected mode set if it's booting a kernel that expects it to already be set. It's not clear to me how Grub would determine that.
The reset vector must be a mapped ROM address otherwise how will the jmp instruction be loaded. But I also seen in some places where they say it can be configured to DRAM as well [0]. I am not sure how it will work then.
Right, and also since that IO memory-mapped address points to ROM whose backing store is likely NAND flash these days there should also be no reason to shadow the BIOS in RAM as the article state it does no?
>"Most registers of the x86 CPU have well defined values after power-on. The Instruction Pointer (EIP) register holds the memory address for the instruction being executed by the processor. EIP is hardcoded to the value 0xFFFFFFF0. Thus, the x86 CPU is hardwired to begin execution at the physical address 0xFFFFFFF0. It is in fact, the last 16 bytes of the 32-bit address space. This memory address is called reset vector.
This says that the EIP is doing a JMP to an address in RAM not a memory-mapped IO address which points to ROM where the BIOS is stored.
>"Now, the chipset’s memory map makes sure that 0xFFFFFFF0 is mapped to a certain part of the BIOS, not to the RAM. Meanwhile, the BIOS copies itself to the RAM for faster access. This is called shadowing. The address 0xFFFFFFF0 will contain just a jump instruction to the address in memory where BIOS has copied itself."
The second says that the CPU is doing a JMP to an IO mapped-memory address which points to ROM.
So the first passage says that CPU is just doing a JMP to 0xFFFFFFF0 in RAM. The second passage say that the CPU is doing a JMP to memory-mapped IO address which points to ROM.
Are these not completely contradictory or am I reading this wrong?
It's always been my understanding that that reset vector always pointed to a memory-mapped address which was located in ROM. Since the BIOS' POST routines contain code to initialiZe and test memory(the BIOs will actually emit beep codes if no memory is present or memory is faulty.), this would be a chicken and egg problem.
Also the post mentions the chipset loads the BIOS into RAM as a process called "Shadowing" which was done because ROM used to be slow. But since BIOS ROM these days in generally NAND flash I don't believe this is the case any longer.
Also these two statements appear to contradict each other:
>"All x86 processors begin in a simplistic 16-bit mode called real mode. The GRUB bootloader makes the switch to 32-bit protected mode by setting the lowest bit of CR0 register to 1. Thus the kernel loads in 32-bit protected mode."
>"Do note that in case of linux kernel, GRUB detects linux boot protocol and loads linux kernel in real mode. Linux kernel itself makes the switch to protected mode."
The first states that the kernel loads in protected mode and then the following states that kernel loads in real mode.