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?
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.
Regards, Carl-Daniel
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.
Alternatively you could build a VGA option rom that initializes VGA on the Geode. The hardware dependent code is in libpayload already. It just needs to be integrated in something like "vgabios"
http://www.nongnu.org/vgabios/
It's quite a trivial task, but it needs someone to do it.
Stefan
On Fri, Oct 03, 2008 at 02:16:27PM +0200, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
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.
Alternatively you could build a VGA option rom that initializes VGA on the Geode. The hardware dependent code is in libpayload already. It just needs to be integrated in something like "vgabios"
Just a random note - I think it should be possible to port the above "vgabios" project from bcc to gcc - similar to how SeaBIOS was ported. The gcc compiler produces much better code than bcc (even after all the 32bit prefixes are added), and a port to gcc should make adding chip specific functions much easier.
I'm not an expert on VGA, but I think it may be possible to implement a bare bones vgabios with only a couple of chip specific functions (eg, initialization and mode switching). Given the recent availability of specs from AMD and Via, there is a possibility that on board VGA could be completely handled with open source code.
Any interest? -Kevin
On 04/10/08 21:59 -0400, Kevin O'Connor wrote:
On Fri, Oct 03, 2008 at 02:16:27PM +0200, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
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.
Alternatively you could build a VGA option rom that initializes VGA on the Geode. The hardware dependent code is in libpayload already. It just needs to be integrated in something like "vgabios"
Just a random note - I think it should be possible to port the above "vgabios" project from bcc to gcc - similar to how SeaBIOS was ported. The gcc compiler produces much better code than bcc (even after all the 32bit prefixes are added), and a port to gcc should make adding chip specific functions much easier.
I'm not an expert on VGA, but I think it may be possible to implement a bare bones vgabios with only a couple of chip specific functions (eg, initialization and mode switching). Given the recent availability of specs from AMD and Via, there is a possibility that on board VGA could be completely handled with open source code.
Not just a possibility - but a certainty. Geode could be ported in a matter of hours.
Jordan
On Mon, Oct 06, 2008 at 08:32:15AM -0600, Jordan Crouse wrote:
On 04/10/08 21:59 -0400, Kevin O'Connor wrote:
I'm not an expert on VGA, but I think it may be possible to implement a bare bones vgabios with only a couple of chip specific functions
[...]
Not just a possibility - but a certainty. Geode could be ported in a matter of hours.
Hi Jordan,
I've spent some time taking a closer look at this. The bochs vgabios has a large number of in/out calls. If the geode vga doesn't natively emulate the legacy in/out ports then I think there is a fair amount of work to port bochs vgabios to geode.
Also, I have a couple of questions that I'm hoping you might know the answers to. Do you know if the geode vga can map its control registers and part of its framebuffer into the space between 0xa0000 - 0xc0000? A 16bit vga bios can't reliably access high memory, so key registers need to be mapped below 1Meg. Also, do you know if the geode vga can support CGA text mode natively? That is, can it be configured in a mode where if one writes an 'X' character to 0xb8000 it will automatically display the 'X' font on the screen?
-Kevin
Kevin O'Connor wrote:
On Mon, Oct 06, 2008 at 08:32:15AM -0600, Jordan Crouse wrote:
On 04/10/08 21:59 -0400, Kevin O'Connor wrote:
I'm not an expert on VGA, but I think it may be possible to implement a bare bones vgabios with only a couple of chip specific functions
[...]
Not just a possibility - but a certainty. Geode could be ported in a matter of hours.
Hi Jordan,
I've spent some time taking a closer look at this. The bochs vgabios has a large number of in/out calls. If the geode vga doesn't natively emulate the legacy in/out ports then I think there is a fair amount of work to port bochs vgabios to geode.
I have been looking at the Geode LX databook and on page 303, it lists the standard VGA I/O ports (3CC, 3C2, 3BA/3DA etc.) which I had previously assumed were emulated in the VSA. If they are indeed implemented in hardware, it should be able to act as a standard VGA device. However, this would make me wonder what the VGA emulation VSA is for.
If they are software I/O ports implemented in the VSA, an alternative would be to make an open-source VGA emulation module for OpenVSA. Unfortunately, my resources are too limited to attempt this task.
Just as a matter of curiosity, what is the licensing issue surrounding the VGA emulation code? I understand that it is not open-source but is it available as a binary?
On 09/10/08 11:19 +0100, Stephen Crocker wrote:
Kevin O'Connor wrote:
On Mon, Oct 06, 2008 at 08:32:15AM -0600, Jordan Crouse wrote:
On 04/10/08 21:59 -0400, Kevin O'Connor wrote:
I'm not an expert on VGA, but I think it may be possible to implement a bare bones vgabios with only a couple of chip specific functions
[...]
Not just a possibility - but a certainty. Geode could be ported in a matter of hours.
Hi Jordan,
I've spent some time taking a closer look at this. The bochs vgabios has a large number of in/out calls. If the geode vga doesn't natively emulate the legacy in/out ports then I think there is a fair amount of work to port bochs vgabios to geode.
I apologize - I spend a lot of my time hacking on the graphics engine, but I forgot all the other baggage that VGA brings with.
I have been looking at the Geode LX databook and on page 303, it lists the standard VGA I/O ports (3CC, 3C2, 3BA/3DA etc.) which I had previously assumed were emulated in the VSA. If they are indeed implemented in hardware, it should be able to act as a standard VGA device. However, this would make me wonder what the VGA emulation VSA is for.
The VSA is there primarily to trap 0x3c2 and to implement a few other extended functions. There is a document on our developer-only website that describes this, I have asked that we release it to the public.
If they are software I/O ports implemented in the VSA, an alternative would be to make an open-source VGA emulation module for OpenVSA. Unfortunately, my resources are too limited to attempt this task.
Especially considering that OpenVSA itself needs a lot of work.
Just as a matter of curiosity, what is the licensing issue surrounding the VGA emulation code? I understand that it is not open-source but is it available as a binary?
The VGA BIOS itself has licencing restrictions on it. The VSA emulation doesn't, but since we never planned on supporting VGA in the first place, it was a non-starter. The infrastructure is in place in the VSA code, but the actual mode switching isn't.
Jordan
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.
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?
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.
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...
Jordan
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.
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.
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
Jordan Crouse wrote:
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.
I was under the impression that the Geode display hardware does not provide the standard I/O ports and memory areas exposed by standard VGA hardware (eg. ports 3d4/3d5 and segment A000) and that this was all emulated in the VSA using SMIs. Am I incorrect about this?
On 06/10/08 16:55 +0100, Stephen Crocker wrote:
Jordan Crouse wrote:
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.
I was under the impression that the Geode display hardware does not provide the standard I/O ports and memory areas exposed by standard VGA hardware (eg. ports 3d4/3d5 and segment A000) and that this was all emulated in the VSA using SMIs. Am I incorrect about this?
Oh, I see what you mean - I thought you meant you have no access to the GPU outside of VSA/VGA. Yes, I believe that is correct for VGA users.
Jordan
Jordan Crouse wrote:
On 06/10/08 16:55 +0100, Stephen Crocker wrote:
I was under the impression that the Geode display hardware does not provide the standard I/O ports and memory areas exposed by standard VGA hardware (eg. ports 3d4/3d5 and segment A000) and that this was all emulated in the VSA using SMIs. Am I incorrect about this?
Oh, I see what you mean - I thought you meant you have no access to the GPU outside of VSA/VGA. Yes, I believe that is correct for VGA users.
The released VSA source only supports the PCI header emulation. A native driver is expected to do all the graphics work.
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 don't understand that it defaulted to 5530. In sysmgr\sysmgr.h SUPPORT_CS5536 is the targeted chipset. It has been a long time, but SUPPORT_CS5535 should also work. I don't know if SUPPORT_CS5530 would work.
Marc
Marc Jones wrote:
I don't understand that it defaulted to 5530. In sysmgr\sysmgr.h SUPPORT_CS5536 is the targeted chipset. It has been a long time, but SUPPORT_CS5535 should also work. I don't know if SUPPORT_CS5530 would work.
If you look at the link that I posted, you will see why. Here is the section of sysmgr.asm in question:
Start: ; NOTE: The VSA II installer patches a "JMP SysMgr_Entry" over the signature field dd VSM_SIGNATURE ; VSM signature db VSM_SYS_MGR ; VSM type db 0FFh ; Any CPU if SUPPORT_CS5535 dw DEVICE_ID_5535 ; VSA for CS5535 else dw DEVICE_ID_5530 ; VSA for CS5530 endif dw VSA_VERSION ; System Manager version dd OFFSET edata ; Size of System Manager dw OFFSET SysMgr_Entry ; EntryPoint dd OFFSET _end ; DS Limit dw 0007h ; Requirements: 4096-byte boundary dw VSA_VERSION ; VSA version
As you can see, if SUPPORT_CS5535 is not defined, it will use DEVICE_ID_5530. Furthermore, it would appear that there is no way for the field to be DEVICE_ID_5536 without modifying the source code. Admittedly, this is a trivial patch but it strikes me as odd that such an action is required. That is why I was wondering whether a newer version of the source was available.
Stephen Crocker wrote:
Marc Jones wrote:
I don't understand that it defaulted to 5530. In sysmgr\sysmgr.h SUPPORT_CS5536 is the targeted chipset. It has been a long time, but SUPPORT_CS5535 should also work. I don't know if SUPPORT_CS5530 would work.
If you look at the link that I posted, you will see why. Here is the section of sysmgr.asm in question:
Start: ; NOTE: The VSA II installer patches a "JMP SysMgr_Entry" over the signature field dd VSM_SIGNATURE ; VSM signature db VSM_SYS_MGR ; VSM type db 0FFh ; Any CPU if SUPPORT_CS5535 dw DEVICE_ID_5535 ; VSA for CS5535 else dw DEVICE_ID_5530 ; VSA for CS5530 endif dw VSA_VERSION ; System Manager version dd OFFSET edata ; Size of System Manager dw OFFSET SysMgr_Entry ; EntryPoint dd OFFSET _end ; DS Limit dw 0007h ; Requirements: 4096-byte boundary dw VSA_VERSION ; VSA version
As you can see, if SUPPORT_CS5535 is not defined, it will use DEVICE_ID_5530. Furthermore, it would appear that there is no way for the field to be DEVICE_ID_5536 without modifying the source code. Admittedly, this is a trivial patch but it strikes me as odd that such an action is required. That is why I was wondering whether a newer version of the source was available.
Ah, This is an oversite on our part. I don't think that anyone uses that field in the signature.
Marc
Stephen,
I apologize. The code on the loptop.org git was out of date. The last set of changes had not been posted. I am sorry I didn't realize this sooner. Please get the latest code.
http://dev.laptop.org/git?p=geode-vsa;a=summary
Marc
On 03/10/08 11:29 +0100, 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?
Not right now, but we desperately need one.
Jordan
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Kevin O'Connor -
Marc Jones -
Stefan Reinauer -
Stephen Crocker