How exactly x86 processor fetches the first instruction from SPI flash memory

Question

On a x86 processor upon power ON of the system , the first instruction the processor usually execute is at 0xFFFFFFF0 which is called reset vector. Typically this address is in the BIOS or flash memory where BIOS is stored.

In a modern systems, we do see the flash is a SPI based which is in the south bridge of the CPU which is now replaced by PCH in the newer Intel systems.

When the CPU starts , it only know its initial address from where to start which is 0xFFFFFFF0 . when this address is floated on Address bus by fetch Engine , the address decoder re-direct this to flash since its mapped to Flash region in the address Map.

I assume at this stage , none of the memory like cache, DRAM , SSD etc. initialized, CPU does not even know the SPI protocol of the flash , SPI bus is also not initialized , Chip select also not enabled for flash, and processor also do not know what command to send to flash device to fetch the instructions.

In some of the wiki/Blogs , I read the BIOS code is direct memory addressable. Does it mean execute-in-place ? But still it has to obey the SPI protocol, how exactly the instructions are fetched from SPI flash device ?

I tried to read relevant x86 manuals , few reset x86 reset sequence blogs , But none of them would have exact details about this.

Answer 1

Right, DRAM controllers aren't initialized, but the flash is connected to the chipset southbridge.

Apparently the CPU does know how to talk to the southbridge in its power-on state¹. The same vendor that makes the CPU also makes the chipset, and the protocol timing for CPU<->chipset communication can be defined so there are values that work. Any initialization of the link is done by fixed-function hardware and/or power-on defaults for any relevant control registers.

The CPU power-on default state must include decoding that physical address 0xFFFFFFF0 as being a "device" address, not DRAM, so a request gets sent to the chipset.

The southbridge itself must also have a power-on state that includes a working SPI link to the flash. Again, any initialization that's necessary is done internally, not by the CPU running code to poke values into control registers.

Fetching bytes from flash via the southbridge is the minimal functionality necessary for the CPU to run firmware code that sets up anything else that doesn't necessary work in the initial power-on state. (And to be able to detect and test, and maybe signal an error code via LEDs on the mobo, which is the sort of thing that would take a lot of hardware if each separate piece of hardware functionality needed to do that on its own, vs. having one serial thread of execution on the CPU doing different devices in sequence, and having one subroutine to signal various errors.)

It's not hard to build logic gates or flip-flops that power on in a specific state. (Perhaps a weak resistor to bias something?). From that, you can build hardware that powers up in certain default states, like timing parameters for the link between CPU and chipset, if that's controllable at all.

---

Footnote 1: or at least after the chipset de-asserts the #RESET signal, which is probably only after an external processor built in to the chipset has done some init stuff.
On Intel the Management Engine exists and can do stuff while the CPU is off, but commenters on How does the CPU load the BIOS? say it isn't responsible for actually mapping the flash ROM. I don't know if mapping flash ROM is simply baked into power-on-default states for various components or whether that's something that a simpler management processor of some sort does, based on its own ROM with a more hard-wired memory map.

Answer 2

These details are part of the logic design they are not part of the bios code or anything. I think you are trying to over complicate this.

That address goes back to the beginning of the 8088 days if not further where there was a bus that the board vendor had to deal with. It is not necessarily true that today the processor itself initiates the first fetch at that address. Booting a processor can be solved multiple ways. Let's assume that the processor does come out of reset and it tries to fetch that address. Names of chips and logic modules is not important. Out of reset there will be a series of buses that begin within the processor core and based on decoding of this address and that it is a fetch/read will take you to the SPI flash controller or some logic in front of it. This logic knows how to communicate with the SPI flash. It is not a case of this being hard or magic, it is not a case that the chip has to figure out how to talk to this flash, but the other way around. The chip vendor dictates what flash you must buy, these parts are so compatible and widely available, that there are dozens of choices minimum, maybe hundreds.

The bios does not have to know any of this, it is all managed by logic and by the board vendor doing a proper board design, and the flash being programmed at least once (another long, but simple, story) so that it feeds the processor the instructions as dictated by the processors rules (the byte order of the information on the flash, which can be the wrong endian, etc, just has to conform to what the chip dictates, might be wrapped in protection or encryption or have headers, etc).

This class of processor is going to have some form of on chip ram, that may or may not have more use later in the boot/run process but can be used to make software folks lives easier on boot (a place for stack and ram).

The chip design may be such that each fetch goes out to the flash (slow and painful way to boot but some designs do this) or it may be that the chip powers up and non-processor logic, copies the flash to ram in some way, decoding or otherwise, and then the processor is released and that address space actually goes to the copied in ram version of the flash. Depends on the processor design, we may not have to know from a software perspective.

That initial code is going to start to bring up the chip. Quite likely that most of the chip is disabled on reset and just enough is enabled in order to get some software running and then that software can/will turn on the rest of the chip (turn on meaning enable clocks and take out of reset, not necessarily power, although that may or may not be part of a design, unlikely for an x86, but some of these comments are in general).

DRAM, PCIE, and a number of other things that need to be up before you try to start the main operating system, happen at this time. A good percentage of the elementary basics needed to move the boot forward would be from the code found on this flash. Often just called BIOS, even though that is not really the term, we just call it that. In the case of the PC world this gets you a long way as today the "bios" has a GUI interface that supports mouse, keyboard, etc and you can configure your boot media choices, boot from network,etc.

As with the motherboard having to conform to the requirements from the chip vendor, the operating systems have to conform to the rules of the bios, if they want to boot, from how the media is prepared, what lives where, with what headers or format, etc. Then the operating system can be launched or perhaps something like grub which is its own deal with rules that then later launches an OS.

I assume at this stage, none of the memory like cache, DRAM, SSD etc. initialized, CPU does not even know the SPI protocol of the flash, SPI bus is also not initialized , Chip select also not enabled for flash, and processor also do not know what command to send to flash device to fetch the instructions.

You start off correct, the INTERFACES to the dram, ssd, etc are not ready to go on reset. The SPI BUS is ready to go, and the logic does know exactly how to talk to that SPI flash, without any code having been run, it comes out of reset ready to talk to the flash and gather the first instructions.

Much later down the road, that SPI controller can likely be reconfigured or may already out of reset be ready to do writes in the rare event that you are doing a bios upgrade/update on that motherboard.

The upstream buses do not even have to know that this address, on reset, is aimed at a flash device, the processor core itself has know clue it is just sending out addresses that happen to take a long time to fetch.

The processor is not even at full speed, the processor is likely driven by a 100Mhz or slower reference clock and while possible to do in logic, and I don't know what intel does, but often one of the first things the bootloader (BIOS) does is make adjustments to the voltage as needed (no two chips are identical and some have tuning values to adjust the voltage for optimal performance and lifetime of the part) and then bring the core clocks up, and then start to bring up the rest of the chip and then start to initialize DDR and PCIE and such. What is or can be brought up before the OS (on an x86 pc) and what happens as part of the OS or can happen is a longer story.

---

The exact answer here is the logic, not the processor, DOES, know exactly how to talk to the flash, from reset. All the logic between the processor and the flash, come out of reset ready to perform the task of the first fetches of instructions from that flash. The processor would come out of reset hardcoded to fetch from that address. The rest of the chip from voltage regulators to clock PLLs, DRAM, PCIE, etc would tend to be under the control of that boot software and not necessarily come out of reset in a ready to use state. The chip designers, any chip, not just x86, have to design the initial boot including hardcoded logic that is ready to perform on reset so that those first instructions can get to the processor and from there everything else can be managed by software.