The AMD VSA - Virtual System Architecture

-
    What actually is the VSA?

    The VSA is the heart of any Geode CPU System. The Geode, rather than carrying lots of legacy hardware interfaces that are presumed to exist on x86 systems, that might be painful to implement on a highly integrated, low power processor, the Geode often emulates such interfaces by use of software that is invoked by special traps that take place when the processor accesses these devices.

    Virtual System Architecture (VSA) is a System Management Mode (SMM) software. VSA virtualizes PCI BARs (Base Allocation Registers) and headers for GeodeLink modules (IDE controller, AC97 codec, network, etc), it acts as an OS kernel interfacing the real hardware to the software hardware.

    This VSA ROM is composed by the VSAInit code (2096 bytes) and many VSMs (Virtual Support Modules). Every VSM has a dedicated scope. There is a VSM for Audio, a VSM for Video, etc.

Here is a list of possible VSMs that might get included in the VSA ROM:

VSM type list from vsa2.h

The included VSMs for any VSA ROM are added in the ROM after System Init code of the VSA. All VSMs start with "VSM " ascii code, they have a big header (about 580 bytes long) and they contain the code for the purpose they serve.

The VSM header contains:

VSM header from vsa2.h

Take note of the "Requirements Flag", "Descriptors" and the "System SysStuff", all of this are typedef structures that incorporate more than 1 byte variables. (read vsa2.h file for more details).

    The GeodeROM code programs the amount of system memory initially needed for VSA memory. VSA can adjust the descriptors once it is loaded.

    The GX processor does not incorporate a standard PCI bus controller. The GX processor and CS5536 devices do not have PCI headers. VSA emulates all the PCI headers and the GeodeLink is configured to route memory and I/O for those modules. This requires VSA to be initialized before PCI scan.

    The PCI controller configuration registers are accessed through PCI type 1 configuration access mechanism (using IO Ports CF8h and CFCh).
This mechanism is documented in here: https://wiki.osdev.org/PCI

***********************************

    This piece of software (VSA) was released by AMD as open source in 2006. Meantime nobody care about it and it was lost. There in no place where this software can be found anymore. The only piece of VSA 2 is here, and is incomplete.

***********************************

    Next, in this post I'll try to reverse engineer the VSA 2 software that I've found on my WYSE Sx0 machine, and, the reason for this is that my VSA ROM image from the BIOS is incomplete too. There was a VSM (Virtual Support Module - part of VSA) by the name of XpressAudio that was capable of emulating a Sound Blaster 16 card on the Geode machine. I don't have this and I'll try to manually build it from the scratch for the machine to be able to run DOS with SB16 sound.

    So... how this VSA is loaded into memory?

    The BIOS, after it finishes to extract all the compressed ROMs, is loading this VSA ROM to RAM at address: 6000:0000 physical address = 0006:0000 linear address, and is jumping at address 0006:0020.

In the first 2096 bytes there is this VSAInit that will handle all the VSA setup.

***********************************
   Setup for VSA installation:

     - Gets information about the system: CPU, Southbridge, memory, PCI

     - Sets ES to be 4 GB descriptor

     - Clears pending SMIs

***********************************

Here, the VSAInit is reading and saving some system variables:

  • CPU rev ID
  • CS5536 host bridge Product ID
  • PCI bus speed in MHz
  • CPU Speed in MHz
  • CPU multiplier
Then it reads the PCI ISA bridge and it saves next variables:
  • ISA bridge address on the PCI bus
  • ISA bridge Product ID
  • Chip Revision ID
Then it sets the "System Manager memory region" to be visible only by the VSA. This sets the base address and max address where the VSA will be resident: 4040:0000  + 256kb. No OS will be able to access this RAM memory. Operating System that will run on this machine will run like on a virtual machine provided by the VSA.

Then it is enabling System Management Interrupt (SMI) instructions: SMINT, RSM, SVDC, RSDC,
SVLDT, RSLDT, SVTS, RSTS. If not enabled, executing an SMI instruction causes an invalid operation fault.

***********************************
    VSA Image Copy
***********************************

Next, the VSAInit is copying the system variables to the header of the first VSM - "System Manager" (staring at 6000:0830) then it copies the entire System Manager VSM from 6000:0830 to the new RAM address defined by the "System Manager memory region": 4040:0000. This process is repeated for all the rest of the VSMs found in the VSA ROM.

AMD had provided a VSA utility program for debugging purposes. In the GX_VSA2 Programmers Guide.pdf is presented an example of this utility showing the memory allocation for all the VSMs loaded:


So, we have an idea about how this VSMs are loaded into memory. No need to reverse the process for everyone of them.

My VSA ROM contains 8 more VSMs besides the System Manager VSM. This VSMs are:
  • 03 - Legacy - Standard AT peripherals - offset C5E4 in the VSA ROM
  • 02 - SoftVG - Software VGA - offset E7F8 in the VSA ROM
  • 08 - ACPI - Virtual ACPI - offset 12BA8 in the VSA ROM
  • 04 - PM - Legacy Power Management - offset 15398 in the VSA ROM
  • 09 - APM - Advanced PM 1.2 - offset 1697E in the VSA ROM
  • 16 - USB - Universal Serial Bus - offset 184EE in the VSA ROM
  • 06 - 8042 - PS/2 Controller emulator - offset 224F3 in the VSA ROM
  • 20 - User - OEM custom VSM - offset 24069 in the VSA ROM
All this VSMs are hardware independent, the System Manager handles the housekeeping functions, serves as the VSM scheduler and dispatcher, and provides the API for the VSMs. The System Manager creates a hardware abstraction layer for all of the VSMs, so it will be possible to easily port them from one VSA ROM to another.

I've got an Award BIOS source code project that includes this VSA2. All the VSMs are provided as separate binary code files.

The command in addrom.bat for building the VSA ROM is:
copy /B VSAINIT.BIN + SYSMGR.VSM + LEGACY.VSM + SOFTVG.VSM + OHCI.VSM + KBD.VSM + ACPI0V.VSM + PMCORE.VSM + APM.VSM + NS41x.VSM + STR.VSM + FLASH.VSM    VSA2.BIN

So, there is no other configuration done at the VSA ROM building time, it just sticks this VSMs one after another in a big ROM file. This way it will be possible to attach more VSMs to the VSA ROM like the XpressAudio VSM that I'm looking for.

"Each major functional component is implemented via a separately compiled VSM. This design allows the ROM builders to concatenate modules with the desired functionality into a customized VSA image. For example, to add APM functionality, the ROM builder simply includes the APM VSM into the VSA2 image." - It will be that simple, only if I'll have this XpressAudio VSM.

***********************************
    SMI Setup
***********************************

    After all VSMs have been configured and copied to the new RAM addresses, the SMI (System Management Interrupt) has to be activated.
    This SMI is the hardware part of the VSA. Inside the CS5536 there is hardware that can trap any access to the resources defined by the VSA and this hardware will generate a System Management Interrupt. 
    The SMI will freeze the OS and will run the System Manager VSM. System Manager VSM will check for the source that triggered the SMI and will run other VSM that will take care of the virtualized resource that have been accessed. After all of this is finished, the OS will continue from where it was frozen like nothing happened.

    So now, for the SMI hardware to be active, the VSAInit code will activate this SMI by setting the "I/O Generated SMI" and "External SMI Pin" to 1 in the "SMI Control Register MSR" - address 00001301h

    Then the VSAInit will initialize the SMI hardware by running an OEM Geode CPU instruction that my IDA Pro7.3 can't disassemble. The opcode is: 0F 38 and is documented in the AMD Geode GX Processors Data Book as "SMINT Software SMM Entry" opcode. This instruction takes 58 CPU clocks, so.. some black magic might be happening :)
    Then the VSAInit it saves some timing  statistics somewhere in the Extra Segment, then it returns to BIOS.

So this is all  with the VSAInit. Now I need to reverse the System Manager and the other VSMs to learn how the VSA is working.

.... to be continued









Comments

Post a Comment

Popular posts from this blog

Part Two - BIOS ROMs of the WYSE Sx0 - S50

-
Image
  The ROMs:      VSA Init ROM:  (Virtual Systems Architecture)  is a piece of software that is hiding the real hardware from the OS and is emulating standard hardware like keyboard controller, IDE controller, CMOS and other legacy hardware.       The Geode, rather than carrying lots of legacy hardware interfaces that are presumed to exist on x86 systems that might be painful to implement on a highly integrated, low power processor, the Geode often emulates such interfaces by use of software that is invoked by special traps that take place when the processor accesses these devices.     This emulation is made at the hardware level by setting some Model Specific Registers (MSRs) that control the GeodeLink Interface Units (GLIUs). This GLIUs can trap CPU access to some defined memory regions and run some ISRs from VSA software instead, or route the access to some other devices. VSA system is a TSR software(Terminate and Stay Resident).     In the image above you can see the real hardware a
Read more

Adventures of reverse engineering the WYSE Sx0 – S50

-
Image
     A few months ago I've bought this WYSE thin client model Sx0 - S50. I wanted to make a retro game machine from it but soon I've realized that I can't make it boot from the DOM with MS-DOS 6.22.      This was interesting because the system was able to boot MS-DOS 6.22 from a USB memory stick. So I've started to investigate the cause for this.      On the first hardware inspection I’ve found a small memory chip on the back of the PCB, an 8 pin SOIC EEPROM “ 93C46A ” that is not bigger than 128 bytes. I’ve dumped the content of this chip using the CH341A (mod-ed to read 93C chips) and all I’ve found was the serial number of the machine: 6IFDGB03427.  You can find the contents of this chip in  here .      Then I’ve start to read more, searched all the internet for documents that might help me understand this machine, and I’ve found some that I’ve put in here .         There you can find documents  about the CPU , the CS5536 Companion that is actually a Platform Contr
Read more

Sound Blaster 16 emulation for DOS 6.22

-
Image
       Reversing this WYSE machine BIOS I have learned that this CS5536 chipset together with the VSA software can emulate a Sound Blaster 16. By default the BIOS exposes the audio AC97 device directly to the OS on the PCI bus. But there are settings to be made for the BIOS to hide this AC97 and emulate a Sound Blaster 16.       This will be great, because all the DOS games and software are compatible to SB16 by default, and there are already made drivers for SB16 for the MS-DOS. This way it might be possible to have real sound on the DOS.     At some time there was an XpressAUDIO ROM, provided by the AMD, that had made this emulation possible. XpressAudio is actually a VSM (Virtual Support Module) that was not included in this VSA ROM of this WYSE BIOS.     For short, the VSA ROM is loaded by the BIOS at system power up. The VSA is searching for all included VSMs and is copying them to separate segments in higher memory (CPU is in real mode and this memory is hidden from the OS).  The
Read more