[coreboot] Integrated graphics controller on second bus?

Rudolf Marek r.marek at assembler.cz
Sun Jan 3 23:55:36 CET 2010

Hash: SHA1

>> +/*
>>  	pci_write_config8(dev, 0x04, 0x07);
>>  	pci_write_config8(dev, 0x0d, 0x20);
>>  	pci_write_config32(dev,0x10,0xd8000008);
>>  	pci_write_config32(dev,0x14,0xdc000000);
>> -
>> +*/
> History.

Aha and in raminit.c it looks like some hardcoded bars too :/

>>  	// set up performnce counters for debugging vga init sequence
>>  	//setup.lo = 0x1c0; // count instructions
>>  	//wrmsr(0x187,setup);
>> @@ -254,6 +258,7 @@
>>  					ramregs[i]);
>>  		}
>>  		printk_debug("I would set ram size to 0x%x Kbytes\n", (rambits)*16*1024);
>> +//it looks like one set 32MB of VGA?
>>  		tomk = rambits*16*1024 - 32768;
>>  		/* Compute the top of Low memory */
>>  		tolmk = pci_tolm >> 10;
> Anything else than 32mb and it dies a horrible death later on when linux 
> tries to use the disks.

Hm looks familiar to me. Maybe it dies when the DMA is done to the buffer which
is located in low mem in the 0xA0000 - 0xF0000 region? Maybe the framebuffer
will just change where the DMA buffers gets allocated... Or it is some other bug
;) Does your linux use 640-1MB region as normal RAM?

> Direct fb access allows any access to the framebuffer on the unichrome 
> to be intercepted by the memory controller. Unichrome and memory 
> controller are on the same die here, and since the unichrome uses part 
> of main ram for its memory, any access to the unichrome memory would 
> mean requests being made from the unichrome to the memory controller. 
> Without direct fb access, a lot of on chip bandwidth is effectively 
> thrown away sending fb accesses back and forth.

Ok, so we can live without it for now and then re-enable it later maybe with
some intelligent resource handling.

Thank you,
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the coreboot mailing list