<div dir="ltr"><div class="gmail_extra">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. The second iteration Furquan and I did on Falco and Pepper is really what we need to use.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">So let's take it a bit at a time. </div><div class="gmail_extra"><br></div><div class="gmail_extra">The GTT is a page table used by the graphics hardware to address memory. It translates graphics addresses to physical addresses. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">GSM is an odd duck. It's used on some chipsets for framebuffer compression IIRC -- corrections, anyone? So it's this weird piece of hidden away memory assigned to chipset for its own uses. It's not strongly tied to the GTT. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But framebuffer compression was full of bugs and was hard to get working and it's only recently been figured out, it seems. In older chipsets, e.g. 945, you set a bit and it takes a fixed size.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Note that GSM size is really unrelated except in the most gross sense to display resolution or depth, again, IIRC. </div><div class="gmail_extra"><br></div><div class="gmail_extra">
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:</div><div class="gmail_extra">- if you don't create enough entries for the resolution, you have a problem</div>
<div class="gmail_extra">- if you create too many, you might waste memory</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div>
<div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I would question this change:</div><div class="gmail_extra"><pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)">-          PGETBL_CTL: 0x3ffc0001<br>
+          PGETBL_CTL: 0x3f800001</pre><pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)"><br></pre><pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)">
because it doesn't come with an explanation of what it's supposed to fix. I've found lots of incorrect BIOS settings that worked largely by accident with the Linux driver. I think you need to go a bit deeper. What did the one bit you changed do, and why? </pre>
<pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)"><br></pre><pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)">But be careful about tying GSM and GTT together too much. </pre>
<pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)"><br></pre><pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)">thanks</pre><pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)">
<br></pre><pre class="" style="font-size:9pt;margin-top:0px;margin-bottom:0px;color:rgb(53,53,53)">ron</pre></div></div>