On 11.03.2009 16:02 Uhr, Myles Watson wrote:
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?
- 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.