Sil3112 flashing (SATA)

[dougg3]

I inserted the padding before the last line. I'm not exactly sure what that string at the end is for but all the SATA roms have the same value, regardless of the version. The RAID one I checked has two bytes changed so perhaps it's related to the device ID.

The last 16 bytes of the flash chip contain some configuration values for the Sil3112 according to the Sil3112 datasheet. It sets stuff like the PCI ID and some register options in the chip. It reads backwards from the end of the chip looking for these bytes (very last byte first, then second to last byte, and so on...):

0xAA (data signature)
0x55 (data signature)
flash speed (0xAA = 120 ns, otherwise 240 ns)
0x55 (data signature)
PCI device ID bits 23:16
PCI device ID bits 31:24
PCI class code bits 15:8
PCI class code bits 23:16
PCI sub-system vendor ID bits 7:0
PCI sub-system vendor ID bits 15:8
PCI sub-system ID bits 23:16
PCI sub-system ID bits 31:24
SATA PHY config bits 7:0 (default: 0xF1)
SATA PHY config bits 15:8 (default: 0x80)
SATA PHY config bits 23:16 (default: 0x00)
SATA PHY config bits 31:24 (default: 0x00)

It's probably a good idea to ensure that string is at the end of the chip. Good call on doing that!

 

[protocol7]

The last 16 bytes of the flash chip contain some configuration values for the Sil3112 according to the Sil3112 datasheet. It sets stuff like the PCI ID and some register options in the chip. It reads backwards from the end of the chip looking for these bytes (very last byte first, then second to last byte, and so on...)

Aha! Mystery solved. Thanks for filling me in on that.

 

[DarthNvader]

Most importantly: the FirmTek firmware checks the ID of the flash chip on the card. It has a whitelist of allowed flash chips. If it's not a PMC Pm39LV040 or a Macronix MX29LV040, it won't load. There may be other possible chips, but I found the IDs of those two for sure, and I know the SST39VF040 is not supported.

P.S. in case anyone is interested it looks like the Am29LV040B is also supported by the firmware.

Would you go into some detail about where in the ROM you found the EEPROM ID's in the Whitelist?

Likely we can detok the FCODE and remove these checks.

Also, what @JoeVT and I found with the UltraTec ATA cards and FCODE ROM's is they use FCODE compression, but the Firmtech firmware for the Sil3112 does not. Likely we could use FCode compression to reduce the size to fit 66k EEPROM while maintaining the ability to boot both Mac OS/Mac OS X from connected drives.

Tho Joe found years ago that have two PCI cards that both use FCode compression maybe problematic in some Old World machines.

 

[dougg3]

Would you go into some detail about where in the ROM you found the EEPROM ID's in the Whitelist?

Whew...it's been 8-9 years since I was looking into this, but I believe I found the check in the code of one of the kexts that gets automatically installed from the card's firmware at bootup. I disassembled the kext, and it had specific checks for various chip device IDs. I can't remember if it was anything more complicated than just "only allow these 3 device IDs" or if the different IDs had any device-specific code associated with them. It was probably PowerPC code which I don't really know much about, so I probably just left my analysis at "these are the valid chips".

Here's a quote from one of my earlier messages in this thread that confirms where I found it:

The firmware extracts a couple of kexts into OS X, and one of the kexts checks for supported flash chips during the OS X boot process and fails to load if the board doesn't have a supported flash chip. (In fact, on a newer revision of the firmware that they don't have available on the website for download, it causes a kernel panic...)

 

[DarthNvader]

Whew...it's been 8-9 years since I was looking into this, but I believe I found the check in the code of one of the kexts that gets automatically installed from the card's firmware at bootup. I disassembled the kext, and it had specific checks for various chip device IDs. I can't remember if it was anything more complicated than just "only allow these 3 device IDs" or if the different IDs had any device-specific code associated with them. It was probably PowerPC code which I don't really know much about, so I probably just left my analysis at "these are the valid chips".

Here's a quote from one of my earlier messages in this thread that confirms where I found it:

Well that is problematic, I was hoping the ID check was in the FCODE part of the ROM, thus it would be human readable in 4th once we detok the ROM.

I wonder if the check also exists in the OS 9 style 'ndrv'.

I'll do some tests when I get a new PC 3112 that doesn't have one of the supported EEPROMs.

Do you remember the hex for the supported EEPROM ID's, so that I can search the .kext files and see if maybe we can do a binary patch to replace supported EEPROM ID's with those more common that are not supported?

 

[dougg3]

That's a good question, I'm not sure if the OS 9 driver has the same limitation. I never looked into it, only the OS X kext.

I went back on my notes and found the following IDs were definitely allowed:

• Am29LV040B = Manufacturer 0x01, Device 0x4F
• MX29LV040 = Manufacturer 0xC2, Device 0x4F
• PM39LV040 = Manufacturer 0x9D, Device 0x3E