[coreboot] Intel native graphics init: Questions about GTT setup

ron minnich rminnich at gmail.com
Mon Jun 9 01:07:54 CEST 2014

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

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140608/14b84949/attachment.html>

More information about the coreboot mailing list