[coreboot] [PATCH] i82801gx updates

Stefan Reinauer stepan at coresystems.de
Wed Mar 11 16:22:46 CET 2009


On 11.03.2009 16:02 Uhr, Myles Watson wrote:
> On Wed, Mar 11, 2009 at 8:55 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
>   
>> On 11.03.2009 15:24 Uhr, Myles Watson wrote:
>>     
>>> +     // NOTE this will break as soon as the Azalia get's a bar above
>>> +     // 4G. Is there anything we can do about it?
>>>       base = (u8 *) ((u32)res->base);
>>> -     printk_debug("base = %08x\n", base);
>>> +     printk_debug("Azalia: base = %08x\n", (u32)base);
>>>       codec_mask = codec_detect(base);
>>>
>>> Can't you add your own read_resources and set the limit for the BAR to
>>> 0xffffffff?  Then you know the BAR will never get allocated above that.
>>>
>>>       
>> Hm... That should work. Maybe we should consider this in the generic
>> code, though. When coreboot runs in 32bit and maps BARs above 4G it
>> can't easily access those bars anymore.
>>     
>
> What are the options?
> 1. Save scratch address space where you allocate BARs for playing
> with, then move them up when you're done.
> 2. Run coreboot in 64bit mode
> 3. Confine config space to 4G
> 4. ?
>   

Maybe PAE? I think we do this for memory scrubbing on K8. Does it also
work for MMIO?

I really like the coreboot in 64bit mode idea, but it's a big deal to
switch those cpus in 64bit mode. Can't be done before memory is there,
either.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090311/7683b957/attachment.html>


More information about the coreboot mailing list