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.
That graphics code is not upstream yet, is it?
> The second iteration Furquan and I did on Falco and Pepper is really
> what we need to use.
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. ;-)
Yes, that second problem has to be solved generically, when writing
> 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.
native graphics code, that is generic for all mainboards with that
chipset.
As far as I understand it, it points to the GTT, which sits directly
> 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.
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.