[LinuxBIOS] Question about protect mode?

[Jeremy Jackson]

Juergen,

Can you please explain which chipset northbridge does this?  I've never
seen one that uses the PCI bus in this fashion, but I'd like to know if
there is one.

http://www.intel.com/design/chipsets/440/documentation.htm

Everyone, please look at Intel 440BX chipset docs for a clear
explanation.  It's an older chipset but that helps to explain the
history of some things.

Northbridge 440BX

http://www.intel.com/design/chipsets/datashts/290633.htm

Page 1-2 has an excellent system diagram.

The CPU reset vector is 0xFFFF_FFF0.  After reset the Intel i82443BX
northbridge decodes everything to PCI.  The southbridge will also
respond to aliases below 16M and 1M.  The usual sequence of the BIOS is
then to configure RAM and enable decoding.  At that point, the alias
below 1M disappears (going to RAM now), and possibly the one below 16M
depending on how much RAM there is.

After that, it is possible to copy BIOS to RAM, and write-protect it for
"shadowing" and legacy support of BIOS at 0xF0000.  

It is also possible to enable a memory "hole" from 15M to 16M and access
the BIOS from there.

Page 4-5 explains:

High BIOS Area (FFE0_0000h –FFFF_FFFFh)

The top 2 MB of the Extended Memory Region is reserved for System BIOS
(High BIOS),
extended BIOS for PCI devices, and the A20 alias of the system BIOS. CPU
begins execution from
the High BIOS after reset. This region is mapped to PCI so that...


Southbridge PIIX4E:

http://www.intel.com/design/intarch/datashts/290562.htm

Page 12 has another useful system diagram showing the BIOS.

The PIIX4E i82371EB claims the 0xFFFF_FFF0 cycle, and aliases to top of
X-bus (1M and 16M) which is where the BIOS rom is connected.  This is
done after reset, even without PCI configuration, as a special case to
allow booting.

Page 155 gives the details.

Regards,

Jeremy

On Sat, 2007-06-02 at 16:25 +0800, Yu-ning Feng wrote:
> 2007/5/31, Juergen Beisert <juergen127 at kreuzholzen.de>:
> >
> > > Maybe a silly question: Isn't it that PCI needs initialization before
> > > we could access it? How could we get there when the processor is
> > > fetching the 1st instruction?
> >
> > In this case the ROM device is connected to the PCI bus, but not connected
> > _as_ a PCI device!. It shares the PCI bus address/data lines only to save an
> > additional bus.
> > If you reuse (or misuse?) the AD[31...0] lines you can connect up to a 16MiB
> > ROM device with 8 bit data width (AD[31...8] as addressbus, AD[7..0] as data
> > bus). Add also three separate additional lines (read, write, chip select) and
> > you are done. Whenever the chipset generates a ROM device access cycle, it
> > does not generate a valid PCI cycle as it only uses the AD[31...0] lines! So
> > this does not hurt any other *real* PCI device on the same bus.
> > But this may work only at system start. Later on some PCI master devices could
> > inhibit this mode. But it doesn't matter: At this point of time the ROM
> > content runs from system RAM, so there is no more need to access the real ROM
> > device (maybe only to reprogramm it).
> >
> > Hope it helps.
> >
> > Juergen
> >
> 
> Please check whether I have understood correctly.
> 
> The processor lauches a cycle with address = 0xFFFF_FFF0. The north
> bridge chipset explains this address. In this case, it signals the
> read line and chip select line which connect the ROM device, and
> select an address of the ROM device through PCI bus AD[31..8]. To the
> north bridge, the ROM device is like a common BIOS ROM except that it
> uses PCI bus to exchange information. Then the ROM device uses
> AD[7..0] to send 1 byte of data back to the north bridge. That 1 byte
> of data is a portion of the 1st instruction.
> 
> Thanks.
> 
> Yu-ning
>