<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 9, 2014 at 6:00 AM, Paul Menzel <span dir="ltr"><<a href="mailto:paulepanter@users.sourceforge.net" target="_blank">paulepanter@users.sourceforge.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Ron,<br>
<br>
<br><br>
<br>
Please also note, that at least since Linux 3.11, Linux is not able<br>
anymore to set up graphics without the Video ROM or native graphics<br>
init. Unfortunately, nobody bisected this yet or notified the Linux<br>
folks of this regression. As I do not have the hardware, I won’t report<br>
that as it takes too much time to relay information.<br></blockquote><div><br></div><div>I've pinged someone I know about it.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
> The second iteration Furquan and I did on Falco and Pepper is really<br>
> what we need to use.<br>
<br>
</div>That graphics code is not upstream yet, is it?<br></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
<br>
</div>And does `setgtt()` reserves that memory? I am still missing, why<br>
`setgtt()` is needed and why we write stuff in there.<br></blockquote><div><br></div><div>setgtt does not reserve that memory, and it should not. But something has to set that gtt up, and setgtt does the job.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
           static void<br>
<div class="">           setgtt(int start, int end, unsigned long base, int inc)<br>
</div>           {<br>
                   int i;<br>
<div class=""><br>
                   for(i = start; i < end; i++){<br>
</div><div class="">                           u32 word = base + i*inc;<br>
</div>                           WRITE32(word|1,(i*4)|1);<br>
                   }<br>
           }<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>But if you want a splash screen, you're going to need setgtt.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> GSM is an odd duck. […]<br>
<br>
Where does GSM come into plays I think, I meant BSM and not GSM. ;-)<br></blockquote><div><br></div><div><br></div><div>just making sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
> Also note that the GTT is just a way to map graphics chipset references to<br>
> physical addresses, and again is not really related to resolution or depth,<br>
> except in two ways:<br>
> - if you don't create enough entries for the resolution, you have a problem<br>
> - if you create too many, you might waste memory<br>
><br>
> The second problem is not as serious as the first. So we just grab a lot of<br>
> memory and map it, because the coreboot mappings will be replaced anyway by<br>
> the driver.<br>
<br>
</div>Yes, that second problem has to be solved generically, when writing<br>
native graphics code, that is generic for all mainboards with that<br>
chipset.<br></blockquote><div><br></div><div><br></div><div>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. </div>
<div><br></div><div>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.</div><div><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> I would question this change:<br>
><br>
> -          PGETBL_CTL: 0x3ffc0001<br>
> +          PGETBL_CTL: 0x3f800001<br>
><br>
><br>
> because it doesn't come with an explanation of what it's supposed to<br>
> fix.<br>
<br>
</div>As far as I understand it, it points to the GTT, which sits directly<br>
below TOLUD. And with that change 3D at least works under Linux 3.12+. I<br>
have no idea, if since some versions the Linux Intel graphics driver<br>
dependents more on firmware initialization and does not replace the GTT<br>
setup anymore.<br></blockquote><div><br></div><div>Again, somebody has to dig deeper and explain what that bit is doing. What does it do and why does it help?</div><div><br></div><div> Good luck!</div><div><br></div><div>
ron</div></div></div></div>