[SeaBIOS] [PATCH 00/11] Relocate init code to high memory

Gleb Natapov gleb at redhat.com
Thu Sep 16 18:45:27 CEST 2010

On Thu, Sep 16, 2010 at 06:24:56PM +0200, Peter Stuge wrote:
> Gleb Natapov wrote:
> > > It looks like kvm is updating the ram at 0xffff0000 when writes
> > > are done to 0xf0000.  It's not ideal.
> > 
> > AFAIK immediately after reset memory accesses to 0xffff0000 and
> > 0xf0000 are directed to exactly same ROM chip.
> No. I'll try to explain. It is messy, because of all the legacy..
> After reset and until CS is reloaded, it looks a lot like the CPU is
> running in real mode from CS:IP f000:fff0. In practise, CS is set up
> (since 386) so that this actually fetches from fffffff0. Again, it
> goes away as soon as CS is reloaded, e.g. after a far jmp or call.
> (The details are similar to the flat real AKA unreal mode trick IIRC.)
OK until now.

> The *only* place that the ROM chip is ever accessible is at top of 4GB.
> How much of the ROM that is actually set up to be decoded on reset is
> quite chipset specific.
First thing that BIOS does is long jump into 0xf000, so who puts BIOS
there if ROM is only accessible at the top of 4GB?

> Physical address 0xf00000 is RAM. It's true that most firmware copies
> at least parts of itself to top 64kb of 1MB (after RAM init of
> course) but this has absolutely nothing to do with the ROM chip.
AFAIK the process is called shadowing. Has chipset support and done long
after BIOS runs from 0xf000 segment.

> It's only done to provide the 1980 BIOS interface that the entire PC
> industry insists on depending on for eternity.
> > Are you saying that after shadowing BIOS at location 0xf0000 and
> > modifying it in memory BIOS copy as seeing at 0xffff0000 changes
> > too?
> I hope Kevin can say more about the circumstances to pin this down.
> The shadowing that you mention is precisely the copying of ROM
> contents into RAM, and possibly modifying it along the way or after.
> Shadowing may not really be an accurate name for the base BIOS since
> they tend to be self modifying, in order to work around all legacy
> limitations. The term is maybe mostly suitable for option ROMs, but I
> understand you. :)
My PIIX4 spec call this BIOS shadowing. Actually same spec has this:

"The 128-Kbyte BIOS memory space is located at 000E0000–000FFFFFh (top of
1 Mbyte) and is aliased at FFFE0000h (top of 4 Gbytes)"

> In any case, a write to physical f0000 should never affect physical
> ffff0000.
> //Peter
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS at seabios.org
> http://www.seabios.org/mailman/listinfo/seabios


More information about the SeaBIOS mailing list