On Wed, Jun 01, 2011 at 11:20:29PM +0900, Isaku Yamahata wrote:
On Wed, Jun 01, 2011 at 09:30:12AM +0200, Gerd Hoffmann wrote:
Hi,
0xE0000000 is hard-coded in the DSDT for both piix and q35 as below. If the range is determined dynamically, the area also needs to be updated somehow dynamically.
... Name (_CRS, ResourceTemplate () ... DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Address Space Granularity 0xE0000000, // Address Range Minimum 0xFEBFFFFF, // Address Range Maximum 0x00000000, // Address Translation Offset 0x1EC00000, // Address Length ,, , AddressRangeMemory, TypeStatic)
Uhm, indeed. I know next to nothing about ACPI though. Ideas anyone how this could be done?
Right now what I can think of is. It would be possible to know the offset in AmlCode[] by compiling dsl with -l option. The we can get the mix of source and resulted hex with offset like
It's easier then this - as Avi indicated, one can turn _CRS into a method which returns the current info with the PCI size filled in at runtime. Something like:
Method (_CRS, 0, NotSerialized) { Name (TMP, ResourceTemplate () { ... }) CreateDWordField (TMPM, 0x123, TMP) Store (TMPM, PCIM) Return (TMP) }
This is already done for other devices - see \SB.LNKS._CRS. For this to work, the new variable PCIM needs to be set to the size of the PCI region, which can be populated in the SSDT when it is built by SeaBIOS.
As Jan points out though, is a dynamic PCI region really needed? Those that need a large PCI region are also likely to need a large amount of memory. Maybe the space for PCI should just be increased.
-Kevin