Initially, our active focus will be on LinuxBIOS support for AMD Opteron processors. We are still discussing internally what we can do for other AMD product lines. Right now, we are taking it one step at a time. Got to start somewhere ...
Thanks!
-Rich Brunner, AMD Fellow
-----Original Message----- From: linuxbios-bounces@openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Richard Smith Sent: Wednesday, August 24, 2005 9:38 AM To: Lu, Yinghai Cc: linuxbios@openbios.org Subject: Re: [LinuxBIOS] Work at AMD to support LinuxBIOS
I have been hired by AMD to support LinuxBIOS development
as it pertains
to AMD's product offerings. Where appropriate I will also work on
We have been looking at replacing our STPC products with either a Geode GX or LX setup.
Poor LinuxBIOS support has held this up somewhat.
We curently are not paying a royality for our BIOS and we don't _ever_ want to do it again.
Whats the plan for "official" LinuxBIOS Geode GX and LX support?
-- Richard A. Smith
-- LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
On 8/24/05, Brunner, Richard richard.brunner@amd.com wrote:
Initially, our active focus will be on LinuxBIOS support for AMD Opteron processors. We are still
I'm sure Ron, Eric and rest of the cluster gang will be happy to hear that.
discussing internally what we can do for other AMD product lines.
IMHO the best thing you could possibly do for support of other AMD product lines is to provide people like Hamish and I access to the proper documentation for the chips, an agreement that allows the generated source to be released under LinuxBIOS and an open line of communication for some questions when we get stuck.
Do that and you will find your products will magically become supported by the community who will then speak very nicely about AMD _without_ a lot of additional effort on your part.
I do understand that may be a little easier said than done considering your existing partnership with Insyde and General Software.
Thank for the info. I'm really encouraged that AMD is looking at official LinuxBIOS support for its products.
Do that and you will find your products will magically become supported by the community who will then speak very nicely about AMD _without_ a lot of additional effort on your part.
In fact I'll actually put my money where my mouth is on this.
Send me a LX DB800 board and if there is enough info on the developer site. (which I'm already a member of) I'll make the port happen. If not I'll send it back.
Looks like there is a empty PLCC socket on the board. If that's where the BIOS goes then I won't need any special flashing tools.
Hamish you already have quite a bit of work done toward this don't you?
I have done a lot of work on the GX1 platform, I also have a kindly loaned GX2 platform from AMD here, but my GX1 work is for a paying customer :), so that is taking priority ATM - I am not sure what the situation is with the newer processors - it appears as though there is third-party chipset support (SiS, if I am correct), and their docs are not necessarily of the highest standard IMHO. </END RANT!>
If they are still using VSA or VSA2 on the newer chips, I can give you a heads-up - it can be a trite tricky.
Hamish
Richard Smith wrote:
Do that and you will find your products will magically become supported by the community who will then speak very nicely about AMD _without_ a lot of additional effort on your part.
In fact I'll actually put my money where my mouth is on this.
Send me a LX DB800 board and if there is enough info on the developer site. (which I'm already a member of) I'll make the port happen. If not I'll send it back.
Looks like there is a empty PLCC socket on the board. If that's where the BIOS goes then I won't need any special flashing tools.
Hamish you already have quite a bit of work done toward this don't you?
On 8/24/05, Hamish Guthrie hamish@hatecke.ch wrote:
I have done a lot of work on the GX1 platform, I also have a kindly loaned GX2 platform from AMD here, but my GX1 work is for a paying
Whats a GX2? I don't see any thing with GX2 on the website.
If they are still using VSA or VSA2 on the newer chips, I can give you a heads-up - it can be a trite tricky.
I thought that was whole point of the newer GX533 and the LX. The are using AMDs x86 stuff rather than the National Semi stuff. If they are still using VSA then I won't even bother. No point in doing anything with SiS either. You can't get an SiS chipset(s) unless you talk huge quantities.
It will only be useful to me if its the GX533 or the LX and a CS5536 companion device.
Guess I need to go look at what info is in the developer site.
Whats a GX2? I don't see any thing with GX2 on the website.
I thought that was whole point of the newer GX533 and the LX. The are using AMDs x86 stuff rather than the National Semi stuff. If they are still using VSA then I won't even bother. No point in doing anything with SiS either. You can't get an SiS chipset(s) unless you talk huge quantities.
It will only be useful to me if its the GX533 or the LX and a CS5536 companion device.
Guess I need to go look at what info is in the developer site.
The VSA/VSA2 enables more true VGA compatibility and enables the audio, among a few other things. For any device where there is a NSC/AMD 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.
The difference between what AMD/NSC call the GX1 and GX2 is simply the companion chip - CS5530=GX1 platform, CS5536=GX2
Hamish
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.
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.
-
Brunner, Richard -
Hamish Guthrie -
Hamish Guthrie -
Richard Smith