Thanks Gordon;
Wow! I am impressed. Right to the point.
On Sat, 2007-09-08 at 14:44 -0400, Gordon Dey wrote:
> As I understand it, the legacy x86 processor can only indicate IO accesses or
> MEMORY accesses. Of and by itself, it has no idea where, why, and how data goes
> during the access, just that the access completes. So, the power-on default
> programmed counter value loaded, is 0xffff00. Written as 16B page style:
> ffff:0000. Manufacturers make every x86 compatible chip power-on reset to the
> same location and in a known state.
>
> But the 'PC' architecture usually has a special chip, often known as the "north
> bridge" connected directly to the x86. "North" refers to how the north-up way
> most x86 pictures are drawn. The north bridge catches the x86's access, and
> then compares it's Address Registers for a matching address and type of access.
> A match turns into a bus cycle: commands, addresses, chip-selects, Read/Write
> strobes, whatever it takes, to complete the access. But at power-on reset time,
> none of this is enabled.
>
> Instead, the north bridge has a power-on default. One such default is a global
> match on every memory access to a specific chip-select ("boot select"), with
> defaulted access timing to match very slow a very simple memory part. The
> selected part, usually ROM, ignores all but the least significant part of the
> address that's presented to it, and responds with whatever was programmed into
> that location, 0x3ff00 or something like it.
>
> Why the leading '3'? In the PC world, often the ROM only uses the least 16 or
> so address bits, and often they even ignore the very least two address bits.
> Doing this, they always return 4 bytes (32b) per access, because the x86 cpu
> usually wants data in 32b chunks. Sometimes the bytes are in separate
> byte-lanes, sometimes aggregated into one big bus. But because of the upper
> addresses are ignored, the x86 can always get the ROM to respond, and the '3'
> in this example, is all of subset of the 0xffff00 that the ROM uses.
>
> Why ROM? All it requires is a chip-select, output-enable and address signals
> (and power) to produce data for the x86 to consume. Very simple. Almost every
> other memory type requires more signals, like a read/write signal, probably
> clocks, specific timeing, and some programming of the north bridge or more to
> make it work. That's the work of a BIOS--to do that programming, find and turn
> on all of the registers and other memory types.
>
> Why is the first thing usually a JUMP of some kind? First of all, with no
> writeable memory type configured yet, there is no place for the x86 to store
> information about where it is and what it is doing. The only way to get to the
> place where a code to configure memory, is to overwrite the program counter
> with that place's address. A JUMP instruction does this. Secondly, the
> FFFF:0000 address is only 256B from the end of memory. Too small a space to put
> kind of initialization program like the BIOS. So it makes sense to JUMP to
> someplace where there's space for more code.
>
> _______________________________________________
> Linux mailing list
> Linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca
> http://oclug.on.ca/mailman/listinfo/linux
--
Regards Bill