Part three - SST49LF020A BIOS chip Memory Map

-

Now I will present the BIOS chip memory map. The hex values represent the offset address in the chip. All ROM images are compressed with "CALG1 Compression Library" and all have a header of 32 bytes where is described the location where every ROM needs to be extracted, the size of the ROM before was compressed, the size after compression + some checksum that is not used.

The data in this table is for the original BIOS. Patched ones are different.

Header + Padding - all zeroes

0

ROM header

9CC0

Compressed VSA Init ROM

9CE0

ROM header

1:D170

Compressed JVGA BIOS

1:D190

ROM header

2:1110

Compressed PXE ROM

2:1130

ROM header

2:6F50

Compressed UHCI ROM

2:6F70

ROM header

2:70D0

Compressed GUI ROM

2:70F0

ROM header

2:A410

Compressed Bitmap image

2:A430

ROM header

2:B570

Compressed Xpress ROM

2:B590

ROM header

2:C250

Compressed HID ROM

2:C270

ROM header

2:CE40

Compressed Disk  ROM

2:CE60

ROM header

2:E540

Compressed XPACPI ROM

2:E560

ROM header

2:EA20

Compressed some text ROM

2:EA40

ROM header

2:FBE0

$PAL image video palettes

2:FC00

ROM header

3:0000

Boot Block

3:0020

End of memory chip

3:FFFF

In the Boot Block there is a function for searching all of this ROMs and expanding them into the RAM. This function is using the ROMs headers to compute the next ROM address. The way the original function it was made was hard to trace. 

So I have patched the code for the ‘ROM searching function’ in the Boot block and all the ROMs headers because the BIOS procedure to find the ROMs was obfuscated and it was hard to swap ROMs in this way. Some strange computations have been used just to get the compressed ROM size + header. I just patched the ROMs headers with exact data and this function with a lot of NOPs for me to easily swap ROMs like the GUI ROM.

Patched bytes in BIOS Boot Block






    More info about the BIOS structure can be found in the “Info.xlsx”. I have written there the most important BIOS steps from the moment of the system power up to the moment of MS-DOS boot.

    All of this reverse took me about 4 months and now when I’m writing this I might forgot to mention some things, but many details can be found in the IDA disassemble files. Just browse the folders. I have also made some small “info.txt” files to keep track of all the progress.

Previous part                                                                       Next part

Comments

Post a Comment

Popular posts from this blog

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 docu...
Read more

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 Reside...
Read more