On Tue, Aug 13, 2013 at 08:49:21AM +0200, Gerd Hoffmann wrote:
On Mo, 2013-08-12 at 18:42 -0400, Kevin O'Connor
On Mon, Aug 12, 2013 at 08:05:08AM +0200, Gerd
We'll need some way to make sure the pmbase
(also mmconf xbar) set by
the firmware matches the pmbase address filled into the acpi tables by
So the options we have are:
(1) Hardcode the address everywhere. This is pretty close to the
current state, 0xb000 is hard-coded pretty much everywhere,
basically because older qemu versions had the pmbase register
readonly with 0xb000. I'd like to move the pmbase somewhere else
long-term, to free the 0xb000-0xbfff window, so I'd like to avoid
(2) Have qemu pick pmbase/xbar addr. Doesn't work due to
initialization order issues (especially xbar for coreboot).
(3) Have firmware pick pmbase/xbar, have fixup instructions for the
addresses in in the loader script, simliar to the fixup
instructions for table-to-table pointers.
(4) [ new idea by mst ] Have firmware pick pmbase/xbar, then have
qemu look at the hardware registers programmed by the firmware,
use pmbase/xbar addresses found there there when generating the
I don't much like option 3 or 4.
Although hardcoding (option 1) is ugly, I think that ugliness does not
justify the complexity of run-time patching (3/4).
Maybe this wasn't clear, but in (4) the table is generated by *qemu*
with the values programmed by the firmware.
Yes. I still don't much like it. I'd think it would be much simpler
for qemu to generate the tables once at startup and not have to patch
them at runtime. It also introduces an obscure dependency on the
ordering of the firmware.
As for option
2 - I don't see why coreboot couldn't read the values
out of fw_cfg early on for the handful of cases like this.
Because both mmconf xbar and pmbase are special:
The mmconf xbar is setup as one of the first things coreboot does, even
before romstage, then coreboot does the complete pci initialization
It's not hard to read a value from fw_cfg early on (even in
u8 myval = inb(PORT_QEMU_CFG_DATA);
Also, if this needs to be determined before the ram controller is
initialized, then I think it's fine to hard code the value (real
machines will almost assuredly hardcode as well).