<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 27, 2015 at 10:52 AM Nicky Sielicki <<a href="mailto:sielicki@nicky.io">sielicki@nicky.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello list,<br>
<br>
I'm interested in cleaning up some of the VGA programming in coreboot.<br></blockquote><div><br></div><div>Good :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was trying to figure out why GM45 "native" textmode isn't working. I<br>
noticed the following bit of code<br>
<br>
> northbridge/intel/gm45/gma.c:144<br>
><br>
>       const u8 cr[] = { 0x5f, 0x4f, 0x50, 0x82, 0x55, 0x81, 0xbf, 0x1f,<br>
>                   0x00, 0x4f, 0x0d, 0x0e, 0x00, 0x00, 0x00, 0x00,<br>
>                   0x9c, 0x8e, 0x8f, 0x28, 0x1f, 0x96, 0xb9, 0xa3,<br>
>                   0xff<br>
>       };<br>
>       vga_cr_write(0x11, 0);<br>
>       for (i = 0; i <= 0x18; i++)<br>
>               vga_cr_write(i, cr[i]);<br>
><br>
>       <...><br>
>       vga_textmode_init();<br></blockquote><div><br></div><div>Next question: why isn't that 0x18 a sizeof(cr)? You might fix that too :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That for-loop generates the following statement:<br>
<br>
> 'vga_cr_write(0x11, 0x8e)'<br>
<br>
Looking at some VGA documentation, and noticing that 0x8e has a MSB of<br>
1, I realized that this statement just locked CRTC registers 00h-07h!<br>
(<a href="http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11" rel="noreferrer" target="_blank">http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11</a>)<br></blockquote><div><br></div><div>Here is something I don't know. Once locked, can they be unlocked, or is it a one way trip? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That's no good, because the subsequent call to vga_textmode_init() tries<br>
to write to some of those CRTC registers, and it's not checking if<br>
they're locked. It assumes that no one else is working with VGA<br>
registers.<br></blockquote><div><br></div><div>yikes. Would it be possible to split the cr[] into two pieces, one to be called once all vga setup is done, and lock it later?  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's worth noting that GM45 isn't the only platform where this CRTC<br>
locking is occuring. A couple others follow this same practice of<br>
loading the CR registers into an array, writing them, and then calling<br>
vga_textmode_init(). That's probably not what we want, and I'm looking<br>
for advice on cleaning this up.<br>
<br>
I think what we want to do is avoid having the VGA registers touched<br>
from outside drivers/pc80/vga/. That means that we need to add or extend<br>
functions to it in order to disincentivize writing them directly-- but<br>
is it possible to accomodate every use case? </blockquote><div><br></div><div>these are good ideas. One thing I've decided with graphics is that it's probably impossible to cover all use cases. The hardware guys are too creative. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On the other hand, an easier fix is to just have vga_textmode_init()<br>
check that the registers it writes to are unlocked.<br>
<br><br></blockquote><div><br></div><div><br></div><div>I wonder about just separating the locking from the setup bytes and making locking the last thing called. That way, if people need to add more functions at some point, they don't have to worry about locking at all.</div><div><br></div><div>thanks</div><div><br></div><div>ron </div></div></div>