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.
--
LinuxBIOS mailing list
LinuxBIOS@openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
