On Mon, Aug 12, 2013 at 08:05:08AM +0200, Gerd Hoffmann wrote: > 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 > qemu ... > > 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 > that. > > (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 > tables.
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). 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. -Kevin
