On Wed, Mar 11, 2009 at 8:55 AM, Stefan Reinauer <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
