Paul, many good questions. The problem is I did all this over 2 years ago and the answers won't be as good. Vladimir and Peter will likely do better. And, to reiterate, the 'replay attack' code for Link is not a good example of how to start graphics. It Just Worked, but not well. The second iteration Furquan and I did on Falco and Pepper is really what we need to use.
So let's take it a bit at a time.
The GTT is a page table used by the graphics hardware to address memory. It translates graphics addresses to physical addresses.
Part of the hardcoding of size is because in some cases the chipset has a limited choice of sizes -- you set a bit, it takes a certain fixed size. 8 MiB is common to the older chipsets. At the same time, once the kernel starts, it's going to change the GTT anyway -- we're mainly doing GTT setup here to make it easy to paint the boot splash screens. That's it.
Note that GTT allows the graphics hardware to address anything in the low 4 GiB, and even more on some chipsets, where another set of address bits is stashed in the low 12 bits.
You can address the memory pointed to by the GTT. Use the address in one of the BARs -- IIRC, bar 0? I don't recall, maybe BAR2 -- as your address. Your references are then mapped back to physical memory addresses via the GTT mappings.
GSM is an odd duck. It's used on some chipsets for framebuffer compression IIRC -- corrections, anyone? So it's this weird piece of hidden away memory assigned to chipset for its own uses. It's not strongly tied to the GTT.
But framebuffer compression was full of bugs and was hard to get working and it's only recently been figured out, it seems. In older chipsets, e.g. 945, you set a bit and it takes a fixed size.
Note that GSM size is really unrelated except in the most gross sense to display resolution or depth, again, IIRC.
Also note that the GTT is just a way to map graphics chipset references to physical addresses, and again is not really related to resolution or depth, except in two ways: - if you don't create enough entries for the resolution, you have a problem - if you create too many, you might waste memory
The second problem is not as serious as the first. So we just grab a lot of memory and map it, because the coreboot mappings will be replaced anyway by the driver.
The GTT settings are fairly safe and I think you're on the wrong track in terms of your debugging, but I could be wrong.
You should not assume that it's NOT a Linux driver problem. The Linux drivers are not well tested against coreboot, and we know of cases where they worked against the BIOS, but only by mostly luck. Sound familiar :-) ? It's the problem we've always had.
I would question this change:
- PGETBL_CTL: 0x3ffc0001 + PGETBL_CTL: 0x3f800001
because it doesn't come with an explanation of what it's supposed to fix. I've found lots of incorrect BIOS settings that worked largely by accident with the Linux driver. I think you need to go a bit deeper. What did the one bit you changed do, and why?
But be careful about tying GSM and GTT together too much.
thanks
ron