[coreboot] [PATCH] Istanbul support

[Arne Georg Gleditsch]

Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> writes:
> On 13.04.2010 09:28, Arne Georg Gleditsch wrote:
>> Stefan Reinauer <stepan at coresystems.de> writes:
>>   
>>> Nice... !
>>>
>>> I've been wondering before... why this odd approach with read8x and
>>> gs:... instead of just doing normal read8/16/32 ?
>>>     
>>
>> Primarily to enable mapping in 64-bit space, I suppose.  I guess we
>> could map AMD fam10 mmio config space into 32 bit-space as well, the
>> main reason not to is that it consumes quite a lot of space.
>>   
>
> Mh. This also means that any OS using MMCONFIG (either directly or
> through ACPI) has to be 64 bit. Among others, this will break some Linux
> Live CDs (which are 32bit, although there are 64bit variants out there
> for some of them). Oh, and Windows might be affected, too.

This is true.  We could map the MMCONFIG area into 32-bit address space,
if we wanted.  That would remote quite a bit of complexity.  Addressing
all 256 PCI buses requires 256M, and I see there are vendors who are
using 0xe0000000 - 0xf0000000 for this.  We can configure the window to
be smaller according to the actual number of buses present, but I'm not
sure it's worth it.

I'm not exacly sure where to hook into the resource allocation framework
to register such a range, but the actual changes ought to be fairly
small.

As far as I know, we're not communicating any information about the the
MMCONFIG area we've set up to the OS at present, so it's not really a
pressing issue.  (I suppose we do want to do so, however.)

-- 
							Arne.