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

[Paul Menzel]

Dear Ron,


thanks a lot for taking the time to write such a detailed answer!


Am Sonntag, den 08.06.2014, 16:07 -0700 schrieb ron minnich:
> 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.

I am aware of that. The replay code also works on the Lenovo X60, but
since Linux 3.12+ 3D is broken, which we try to fix. Also the GTT code
is more or less identical in master and in Vladimir’s patch set [1].

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.

> 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?

        $ git grep MAINBOARD_DO_NATIVE src/mainboard/google/
        src/mainboard/google/link/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += i915.c
        src/mainboard/google/link/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += i915io.c
        src/mainboard/google/link/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += intel_dp.c
        src/mainboard/google/pit/Kconfig:       select MAINBOARD_DO_NATIVE_VGA_INIT
        src/mainboard/google/slippy/Kconfig:    select MAINBOARD_DO_NATIVE_VGA_INIT
        src/mainboard/google/slippy/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += gma.c i915io.c
        src/mainboard/google/snow/Kconfig:      select MAINBOARD_DO_NATIVE_VGA_INIT
        $ git grep i915lightup src/northbridge/intel/haswell/ src/mainboard/google/{falco,peppy}
        src/northbridge/intel/haswell/gma.c:    int i915lightup(u32 physbase, u32 iobase, u32 mmiobase, u32 gfx);
        src/northbridge/intel/haswell/gma.c:    lightup_ok = i915lightup(physbase, iobase, mmiobase, graphics_base);

> 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.

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

           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);
                   }
           }

> GSM is an odd duck. […]

Where does GSM come into plays I think, I meant BSM and not GSM. ;-)

> 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.

> 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.

That is indeed still a possibility.

> 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.

[…]


Thanks,

Paul


[1] https://bugs.freedesktop.org/show_bug.cgi?id=79038
[2] http://review.coreboot.org/5927
[3] http://review.coreboot.org/#/c/5320/9/src/northbridge/intel/i945/gma.c
[4] http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobile-945-express-chipset-datasheet.pdf
[5] https://01.org/linuxgraphics/sites/default/files/documentation/965_g35_vol_1_graphics_core_0.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140609/f98f1d53/attachment.asc>