On Mon, June 1, 2015 4:16 am, Gerd Hoffmann wrote:
On Sa, 2015-05-30 at 07:57 -0300, Paulo Alcantara wrote:
Hi Gerd,
On Thu, 28 May 2015 09:13:35 +0200 Gerd Hoffmann kraxel@redhat.com wrote:
+Scope(_SB) {
- 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 registers.
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