On Sa, 2015-05-30 at 07:57 -0300, Paulo Alcantara
On Thu, 28 May 2015 09:13:35 +0200
Gerd Hoffmann <kraxel(a)redhat.com> wrote:
+ OperationRegion (RCRB, SystemMemory, 0xfed1c000, 0x4000)
Where does this address come from?
This address is reserved in an ACPI DSDT table for Intel Haswell in
Coreboot project, Vlv2DeviceRefCodePkg package in EDK II as well as my
Haswell laptop on which I can see it through `dmesg` :-)
So it seems to be kind of standard.
Same address on my laptop btw.
Is this a
standard location suggested by intel specs?
I haven't found any Intel spec or any other document that suggests such
address, but from "9.4 Memory Map" section in ICH9 spec, it seems safe
to use that MMIO region for the 16KiB of chipset configuration
Or is the firmware free to choose it?
Given that, I would say so.
There are a few more cases where addresses programmed by the firmware
and addresses in the acpi tables must match: acpi registers, pci
mmconfig space for example. They are handles this way:
(1) firmware programs the hardware registers as it pleases.
(2) when the firmware fetches the acpi tables from qemu (via fw_cfg)
qemu will update the tables according to the hardware programming.
So the question is whenever we better do that here too, or whenever it
is fine to simply hardcore this to 0xfed1c000 everywhere ...
I tend to think hardcoding is fine in that case. coreboot, edk2 &
seabios all place it at the same location, and it is highly unlikely we
ever want move this to another place some day for some reason.
Thanks for the explanation. So, handling it the same way as we do for acpi
regs and pci mmconfig space seems to be the proper solution, however I
think it's OK to hard-code that address for now since it's being used in
many places already.
Paulo Alcantara, C.E.S.A.R
Speaking for myself only.