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

Peter Stuge peter at stuge.se
Thu Sep 16 18:24:56 CEST 2010


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

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.

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.

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. :)


In any case, a write to physical f0000 should never affect physical
ffff0000.


//Peter



More information about the SeaBIOS mailing list