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.