On Wed, Mar 11, 2009 at 8:55 AM, Stefan Reinauer stepan@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. ?
Right now, the BAR will never be allocated above 4G because the chipset can't really cope with it anyways. Future ICHx chips might have the problem (in case we decide to really put BARs above 4G, which we don't do per default). It's not a real issue yet, just thought I leave the comment in so if people copy it around, and some day run into trouble, they don't have to do the same thinking.
Good idea.
Thanks, Myles