[LinuxBIOS] Work at AMD to support LinuxBIOS

[Hamish Guthrie]

Richard,

The VSA stuff actually works fine, but there are some technical issues 
(from a LinuxBIOS standpoint) which make it tricky. These issues I am 
sure are surmountable, and if AMD are really wanting to help LinuxBIOS, 
they may take note of this!!!!

I stand under correction as to the exact details of this, as I have seen 
no source for the VSA code, but, with a lot of analysis, the main VSA 
code gets executed under SMM, but that is not a detail we really need to 
be concered with, the issue is getting the VSA code loaded in the first 
place.

There is init code provided within the VSA code binary, which is easy to 
vector to, however, this is real-mode code, so I have looked at various 
ways of doing this - I have followed the x86emu route, but there are 
instructions used in this VSA code which are not supported by x86emu, 
and I have just not had the time to be able to look into this properly. 
Another suggestion (I believe from Stephan) is to look at executing this 
code in vm86 mode, but I have not tried that yet. The third alternative 
is to ping-pong back into real-mode after we have enough of the chipset 
initialised, but that looks like bad news.

I have an interim solution for situations where I want to use the VSA 
code, and that is to use unreal mode (yea, I am in assembler the whole 
way here), to initialise enough of the chipset and RAM in order to get 
to the point where I can vector to the VSA init code, shortly after 
returning from the VSA init code, I then jump to the real-mode LinuxBIOS 
entry-point, and just strip out the code from my LinuxBIOS version of 
the early init code and let LinuxBIOS do the rest.

What would be REALLY NICE - (hint - hint AMD, are you listening!), is if 
we could maybe get the source for the VSA init code, in which case, we 
*SHOULD* be able to write our own protected-mode init code to load the 
actual VSA code into RAM and do the initialisation correctly from within PM.

I can really only speak about the VSA code from a VGA point of view, and 
from that point of view it is actually quite elegant (although a proper 
silicon solution would have been much easier!). The VSA code for the VGA 
subsystem essentially simulates all of the legacy VGA hardware ports in 
software. These are generally used to set VGA modes and things, and are 
useful when initialising the VGA itself. Well, especially useful for 
using 'traditional' techniques (i.e. VGA BIOS calls, and the ELPIN VGA 
BIOS requires the VSA stuff to be loaded) when setting modes under X and 
for the framebuffer device. Once the VGA chipset is set-up, the VSA 
falls out of the picture completely, as the X and FB drivers from that 
point on ONLY ever access the hardware directly.

I believe the situation may be a little different with the VSA code for 
Audio, but I have not yet had to play with that too hard, so I cannot 
really comment, other than, yes, with LinuxBIOS, and my unreal-mode 
loader fudge, I have managed to get audio to work! How good it is, I 
have no idea - it is not part of my current bread winning project - I 
heard some sound, and that was it!

Hamish

Richard Smith wrote:
>>companion chip (CS5530/CS5536), as far as my understanging goes,
>>includes VSA, the SC1200 and a few of those other integrated devices
>>also have the VSA.
> 
> 
> Ok.  I'll try to read some of the docs this weekend.  But if it does
> use VSA for all the stuff  we will be much less interested.  I've read
> nothing but bad things about VSA.
>