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.
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 state1. 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.