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

ron minnich rminnich at gmail.com
Mon Jun 9 16:14:12 CEST 2014

On Mon, Jun 9, 2014 at 6:00 AM, Paul Menzel <
paulepanter at users.sourceforge.net> wrote:

> Dear Ron,
> Please also note, that at least since Linux 3.11, Linux is not able
> anymore to set up graphics without the Video ROM or native graphics
> init. Unfortunately, nobody bisected this yet or notified the Linux
> folks of this regression. As I do not have the hardware, I won’t report
> that as it takes too much time to relay information.

I've pinged someone I know about it.

> > The second iteration Furquan and I did on Falco and Pepper is really
> > what we need to use.
> That graphics code is not upstream yet, is it?

I guess not, I no longer do coreboot full time, so can't say when it will
go in. But it's visible in the chromium repo and IMHO it's pretty good
code, worth taking.

Really, those CLs are available for anyone to grab and test and push
upstream. It doesn't have to just be Google people who do the job.

> And does `setgtt()` reserves that memory? I am still missing, why
> `setgtt()` is needed and why we write stuff in there.

setgtt does not reserve that memory, and it should not. But something has
to set that gtt up, and setgtt does the job.

>            static void
>            setgtt(int start, int end, unsigned long base, int inc)
>            {
>                    int i;
>                    for(i = start; i < end; i++){
>                            u32 word = base + i*inc;
>                            WRITE32(word|1,(i*4)|1);
>                    }
>            }

And note a trick here: if you set 'inc' to zero, you can have setgtt point
all gtts at one page, load that page with a color, and get a splash screen
up *very* quickly. It saves well over 100 ms.

But if you want a splash screen, you're going to need setgtt.

> > GSM is an odd duck. […]
> Where does GSM come into plays I think, I meant BSM and not GSM. ;-)

just making sure.

> > 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.
> Yes, that second problem has to be solved generically, when writing
> native graphics code, that is generic for all mainboards with that
> chipset.

It does not have to be solved exactly becase the kernel drivers will not
use whatever you do. So it's easiest just to grab a big chunk of RAM, point
the gtt at as much of it as you need, and not worry. Again, the RAM you
allocate and the GTT entries you create are ignored once the kernel starts
the driver.

Or, if it's a quick boot and you don't want splash, fill one page with a
nice color, and point all gtt at that one page. The speed difference is
quite noticeable.

> > 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.
> As far as I understand it, it points to the GTT, which sits directly
> below TOLUD. And with that change 3D at least works under Linux 3.12+. I
> have no idea, if since some versions the Linux Intel graphics driver
> dependents more on firmware initialization and does not replace the GTT
> setup anymore.

Again, somebody has to dig deeper and explain what that bit is doing. What
does it do and why does it help?

 Good luck!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140609/8089a9be/attachment-0001.html>

More information about the coreboot mailing list