Re: First instruction executed after RESET and A20 cache consistency


Zdenek Sojka wrote:
> > A system not constrained by PC compatibility could execute a few dozen
> > instructions in the high-address real mode and then switch into a
> > protected mode "BIOS," and never look back to real mode.
>
> Well, if the first instruction was a near jump, the CS.base would stay
> loaded with 0xffff0000, wouldn't it?


Exactly. But in the case where a system did not care about real mode,
it would quickly switch into protected mode, and (presumably) never
reload CS until the switch, so that bit of real mode code can live
anywhere in the 0xffff0000 segment, and you wouldn't have to mess up
your system's address space by mapping a ROM into the 0xf0000 range.


> >
> >
> > > Also, there is third possibility - when A20 is turned off, the first
> > > physical address of instruction is 0xffeffff0.
> >
> >
> > It's possible some motherboards shadow the BIOS into that range as
> > well, but typically A20M will not be enabled after a reset, an so it is
> > not necessary.
>
> Does the MB know that CPU got a reset? (eg. triple-faulting CPU or some
> other conditions make CPU reset itself)
> And anyway - if it knew, would it turn on A20 before the CPU starts
> executing instructions?
>
> As I were steeping thru BIOS loader, it first turned A20 on - so it were off
> when resetting (AFAIR)


The CPU does not reset itself. If it triple faults, it enters a
specific shutdown/halt state, and then the motherboard (chipset) resets
it.

In any event this is an interesting question - while the CPU is reset
after a triple fault (or the explicit CPU reset request), the
motherboard is not, and by extension the A20 signal from the keyboard
controller will not be either. This implies that the A20 gated reset
will either generate addresses in 0xffef0000 range, which would require
that third mapping for the BIOS ROM, or that the A20 gate is ignored
for those high addresses generated in the reset sequence before the
first CS reload. The later would be my guess.


> So there is not any A20 emulation done in CPU?
> eg. is this still handled by KB controller (or chipset etc.), not at CPU?
> (CPUs are not dedicated to be run at IBM-PC architecture, so it would be
> useless for other architectures... but it could make some things easier -
> with exception that some devices might use adress bus too, and there could
> be conflict, if the "MB's A20" is everytime on, but that in CPU is off...
> ok, nevermind)


All of the A20 gate handling is done in the CPU. The A20 gate
circuitry is buried someplace between the final stages of the CPUs
address generation logic and the L1 cache. It's just that the
processing is controlled by the A20M signal, which traditionally comes
from the keyboard controller. Note that many chipsets have alternative
ways to drive the A20M signal, which are much faster than using the
keyboard controller.


> > Yes, the A20M pin is an input - on PC's it's the keyboard controller
> > chip that drives it. A20M (on at least 486 and later processors) only
> > applies to addresses generated in real mode anyway, and modifies the
> > addresses before they hit cache (this is why A20M is an input on all
> > processors that actually have cache), so no cache consistency issues
> > can occur.
>
> I dont think so... maybe I misunderstood you, but when the CPU switches to
> PM, it is up to programmer to turn on A20. Or is there some pin which in PM
> is activated and chipset turns A20 on then automatically?


That was certainly true on 286 and 386 systems. On 486 and later
systems, A20M is ignored in protected mode. Of course turning the A20
gate off before switching into protected mode certainly wont hurt
anything. OTOH, I have never seen any code that switches into
protected mode *without* ensuring the A20 gate is off (after all,
it's only a few lines of code).

.

Relevant Pages