On Mon, Jun 9, 2014 at 6:00 AM, Paul Menzel < paulepanter@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: 0x3f800001because 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!
ron