[coreboot] Integrated graphics controller on second bus?
r.marek at assembler.cz
Sun Jan 3 23:55:36 CET 2010
-----BEGIN PGP SIGNED MESSAGE-----
>> pci_write_config8(dev, 0x04, 0x07);
>> pci_write_config8(dev, 0x0d, 0x20);
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
>> @@ -254,6 +258,7 @@
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the coreboot