Timothy Normand Miller wrote:
During POST, the PC is supposed to assign addresses to OGD1's various
memory regions. It works fine for BAR0 and BAR1, but for some reason,
we end up with a zero in the EPROM BAR. In simulation, if we write an
address to the EPROM BAR, it works fine, so we need some ideas as to
why the host might be rejecting our EPROM. There are two things that
come to mind, but we don't see why they should matter. One is that we
show up as a VGA-compatible non-graphics device. This is probably a
mistake somewhere that we just haven't gotten around to fixing. The
second thing is that our EPROM contents do not start with AA55 (or
55AA or whatever the signature is). Any other ideas? At some point,
we'll have to hook up a PCI bus analyzer and watch the boot process to
try to get some insight into this. Another idea is that since the
EPROM is blank, it's probably reading back all FF, which the host
might be interpreting as not being claimed by any device. One thing
that might help is if we had a dummy BIOS image (that it should think
of as valid but which doesn't DO anything) to program in there.
Any ideas?
Hi.
(Sorry, I'm still struggling with the difference between e-mail and
newsgroups. ;-)
This is covered in the PCI spec, but it's moved between versions 2.1 and
3.0.
Basically what you are seeing is expected behaviour. The BIOS enables
the EEPROM BAR for the the device and checks to see if there is the
correct signature (0xAA55). It then copies the correct amount into the
RAM area somewhere between 0xC0000 and 0xF0000 (for a VGA we are
guaranteed to start at the 0xC0000 address).
The init routine of the option ROM is then called while the RAM area is
still writeable! The init routine can modify it's code and store data
in its image area. It can also reduce it's resident size (by modifying
the length field that is just after the header). When the init routine
returns the BIOS makes the RAM read-only.
This is something that I think all PC emulators fail to emulate properly
at the moment - certainly bochs treats the option ROMS like they are in
a ISA only PC. This is something I'm in the process of fixing.
In the PCI spec (version 2.1) this is in section 6.3 (do you have that
spec. It's findable on the internet).
In the version 3.0 spec it's in a separate section (PCI FIRMWARE
SPECIFICATION, REV. 3.0 pcifw_r3_0_updated.pdf) that I've only found in
the official place. I have a log-in, but I'd feel bad giving it to you
(I think it might be bound to IP address anyway).
A PC-Compatible expansion header should look like this:
Offset Length Value Description
0h 1 55h ROM Signature byte 1
1h 1 AAh ROM Signature byte 2
2h 1 xx Initialization Size - size of the code in units of 512 bytes.
3h 3 xx Entry point for INIT function.
POST does a FAR CALL to this location.
6h-17h 12h xx Reserved (application unique data)
18h-19h 2 xx Pointer to PCI Data Structure
If I quote the spec here:
> 6.3.3.1.1. POST Code Extensions
> POST code in these systems copies the number of bytes specified by
the Initialization
> Size field into RAM, and then calls the INIT function whose entry
point is at offset 03h.
> POST code is required to leave the RAM area where the expansion ROM
code was
> copied to as writable until after the INIT function has returned.
This allows the INIT
> code to store some static data in the RAM area, and to adjust the
runtime size of the code
> so that it consumes less space while the system is running.
> The PC-compatible specific set of steps for the system POST code when
handling each
> expansion ROM are:
> 1. Map and enable the expansion ROM to an unoccupied area of the
memory address
> space.
> 2. Find the proper image in the ROM and copy it from ROM into the
compatibility area
> of RAM (typically 0C0000h to 0E0000h) using the number of bytes
specified by
> Initialization Size.
> 3. Disable the Expansion ROM Base Address register.
> 4. Leave the RAM area writable and call the INIT function.
> 5. Use the byte at offset 02h (which may have been modified) to
determine how much
> memory is used at runtime.
> Before system boot, the POST code must make the RAM area containing
expansion
> ROM code read-only.
> POST code must handle VGA devices with expansion ROMs in a special
way. The
> VGA device’s expansion BIOS must be copied to 0C0000h. VGA devices can be
> identified by examining the Class Code field in the device’s
Configuration Space.
I have made a dummy expansion ROM for you. If you checkout the latest
drivers/bios you should be able to type "make dummy" and get a new file
called dummy.bin.
This does nothing much. It contains the correct headers so that it
should be found by your motherboard and mapped in. It tries to save
some info when the init function is called, so if this works you should
see some data in the ROM (that isn't there now?).
Before you build it you will ahve to edit ogd_defines.inc. We need to
have the correct VID and PID in the option ROM that matches the PCI
device. You need to make sure that the ones in that file match your
hardware.
The code is all in dummy_bios.asm. I would be extremely interested in a
dump of the resultant image from your test PC's memory. I save the
registers AX, BX, CX & DX when the init function was called and the
entire config space. It would be really good to know if this worked?
The EEPROM BAR should contain 0 once the POST has finished and the OS
has started.
What OS are you using by the way? DOS or something else?
MM
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
