-----BEGIN PGP SIGNED MESSAGE----- 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, Rudolf