On 06/10/08 16:24 +0100, Stephen Crocker wrote:
Jordan Crouse wrote:
On 06/10/08 15:31 +0100, Stephen Crocker wrote:
Carl-Daniel Hailfinger wrote:
On 03.10.2008 12:29, Stephen Crocker wrote:
Is there a way of getting VGA support with SeaBIOS on the AMD Geode LX framebuffer? I have successfully built and tested a BIOS image that appears to boot into DOS but the lack of display means that it is of little use. Is there a VGA ROM image that I can include?
You'd need a VGA emulation VSA and AFAIK that piece of software is not available as open source due to an interesting rights situation.
How much of this is handled in AMD's binary VSA module? I have been looking through both the AMD and OpenVSA source and it looks as if the lxvg module is supposed to handle VGA SMIs but I cannot find where this is actually done.
None of it - the VGA is actually a seperate component under difference licensing. Thats why you don't see it in the VSA code.
This is quite an important point, as a lot of programs access the I/O ports and framebuffer directly. A VGA BIOS would be able to handle the functions provided by INT 10 but in my experience, that would not be enough.
Not sure what you are trying to say here - beyond the PCI emulation, the VSA neither grants nor restricts access to the graphics hardware. This is why we have been able to get away without VGA up to this point - both the libpayload driver and the kernel framebuffer drivers are perfectly good replacements for standard int 10 behavior.
Incidentally, I have noticed that the AMD VSA source available from dev.laptop.org cannot be used to build an image with CS5536 support. Is this an old version and, if so, is newer source available?
Umm...
http://dev.laptop.org/git?p=geode-vsa;a=blob;f=sysmgr/cs5536.c;h=422922cab80...
Please note lines 139-143: http://dev.laptop.org/git?p=geode-vsa;a=blob;f=sysmgr/sysmgr.asm;h=ecb351fdd...
When I attempted to build an image, it defaulted to the CS5530. I did wonder about fudging the header to use the CS5536 device ID but I also noticed that the size of my image came to 60,466 bytes whereas the standard binary image is 57,504 bytes. This would imply a significant difference in either the source tree, my build environment or both.
I am using the tools supplied with version 3790.1830 of the Windows Driver Development Kit apart from MASM, which is version 6.14.8444.
Hmmm - interesting. I know nothing about actually trying to build the VSA code (they haven't gotten around to getting a MASM license for Linux systems yet :D). I'll have to leave this to Marc to answer.
Jordan