I Just Ruined My SATA Card!!!

[dougg3]

Correction: there doesn't *have* to be the initialization data at the end of the chip, it's only needed if settings other than the defaults need to be used.

I have one more idea for you to try. The original FirmTek flasher actually includes an OS 9 version of the firmware update too. It's inside the .app folder. Have you tried booting into OS 9 and running that firmware updater program? It might identify the card using a different method.

 

[CC_333]

Yes, I discovered the Classic version of the flasher while looking for the firmware file.

Unfortunately, it seems to behave identically to the Mac OS X version: it doesn't detect the card.

Also, I looked at your post on the other thread, and you're right; please let me know what you come up with and we'll go from there.

This card was excellent when it worked.

Sheesh! This was all my fault, too! I knew better :I .

...reminds self to never again attempt a firmware update while booted from the card whose firmware I'm updating...

c

 

[techknight]

just pull the darn MXIC chip and reflash it with a programmer, maybe a willem? or something of the line. That should take care of the issue.

If the ROM was internal to the main IC, i would worry. but in this case it isnt, so its easy as pie.

Which one does it have, the TSSOP, or the PLCC type?

 

[techknight]

also keep in mind that differnet manufacturers of Flash ICs have different procedures and processes to initialize/erase and reflash the memory area. So the flash erasure and reprogramming for one chip manuf wont exactly work on the other.

I had to deal with this with other hardware that used this technology.

You need an MXIC flash driver to reprog.

I dont know anything about the chipset that card has, but most chips require at least a preliminary bootloader on the flash that is written to allow the CPU to go into debug mode or programming mode. if that flash is blank, and the chipset has no debug or recovery ROM your kinda screwed... Only way around this, is if the chip has a backdoor style init process that can be activated to enter into prog and reflash the memory without the memory being present or programmed, such as JTAG.

or if the chip supports being directly manipulated by the PCI bus to get it into programming. But if any of this requires at least a low-level bootloader to be present in flash, your done...

 

[dougg3]

Yeah, if all else fails that's exactly what I'm going to do with CC_333's card--pull the chip and reflash it in a programmer. But we have to be sure of what actually needs to be flashed to it first -- the firmware image included with the updater looks kind of weird, so I want to make sure it's an exact copy of what's actually on the chip first.

I don't think blank flash actually prevents you from accessing this particular type of chip from the computer. We'll know more as soon as the card I ordered arrives and I can do a raw dump of its flash chip. I'd rather do some research first so the community gets more useful future information about these cards in the process.

It's somewhat surprising to me that the different chips don't all work using the same flashing routines. For the most part these chips all claim to support the JEDEC specification and listen to the same command set for erase/program operations. I've checked the datasheets of several flash chip variants and they all adhere to the exact same command set for erasing the entire chip and programming bytes. I've had no trouble in my SIMM programmer flashing multiple brands of chips using the exact same generic JEDEC-compatible flashing routine (the exception being the 16 megabit chips I use which are slightly different because they can talk in 16-bit data mode).

It does seem that these firmware update programs have multiple routines for different chip brands. Other than maybe if they're protecting the chip or erasing individual sectors (the sector layouts and protection mechanism can vary a bit between chips), I don't fully understand why they have multiple flash routines. The MXIC chip listens to the same command set for erase and program commands as the SST chips I use, which also match the AMD chips I've used. I dunno.

 

[techknight]

when programming differnet flash ICs through JTAG I had issues between ST, Intel, and MXIC. Alot of them were the same yes, but ST and intel didnt like each other when being programmed outside of thier specified programming commands.

 

[max1zzz]

Out of interest, do you think the descrambled firmware would work on a normal PC sil3112 card?

Just wondering as i did try to get one working, but after flashing it (using the webitech flasher, and the firmware extracted from the seritek updater) it still wouldn't work, and unfortunately it didn't get recognized by the seritek updater.

It did interestingly change what the card was recognized as (can't rember off the top of my head what it is seen as now...)

sorry for slightly hijacking the thread, just wondering if you guys think it would work

 

[dougg3]

We will try to find out sooner or later if it will enable anything like that The PC version of the card would definitely need to have a large enough flash chip.

The card just arrived. I plugged it into my G3 and System Profiler says it's running firmware version 5.3.1b1 (NEWER than the latest that their updater provides?). I'll dump the chip's contents and go from there...

 

[CC_333]

Excellent!

I look forward to hearing all about it!

c

 

[max1zzz]

i'll be very intrested to see what can be done with the dumped firmware, and hope it enables you to fix your card CC

putting a bigger flash chip on the card is trivial, just a little blast of hot air, i already swapped the orig chip for a 2mbit one so the firmware from the updater would fit

 

[dougg3]

OK, I did a raw dump of the chip. There doesn't appear to be anything fishy going on or anything. The dump looks A LOT like ROMFILE.1S2's contents, but slightly different because it's a newer firmware version. I don't think ROMFILE.1S2 is encrypted in any way, shape, or form. I don't want to mess with the contents of the original chip just to be safe, so I'll see if I can restore the capability given a new chip I ordered -- SST39VF040. I'll put a blank SST39VF040 into a socket I'm about to solder to the card, then I'll see if I can get the OS X flasher and/or the Windows flasher to do anything.

 

[techknight]

Well is it 2 different firmwares run into each other I assume? so the card is crashing/locking on boot.

 

[dougg3]

Whew! Been running tests for the last couple of hours in an attempt to figure this out. Not done yet, but getting there.

First of all, after I put a blank chip into the card, OS X was showing a black rectangle in the middle of the screen shortly after trying to boot. Fixed that by booting with the shift key held down and running the FSCAPP program. Then the Mac would boot, but it didn't see the card in System Profiler at all, not even as a PCI device. So what I'm seeing with blank/corrupted firmware is a different problem than what you're seeing.

I ran UPDFLASH.EXE to flash the card with the contents of ROMFILE.1S2, but it work--still no PCI device. I then read back the chip and it looks like the DOS flasher didn't do a complete flash job -- it left off some of the end of the file. So then I put the whole file into a 256 KB file padded with 0xFF at the end (which is what it should be). Still no dice. At this point, OS X *still* didn't see the card as a PCI device!

Next, I used UPDFLASH.EXE to flash the card with my raw dumped contents of the original chip. This resulted in UPDFLASH claiming that it had an error flashing the chip. Caused a black rectangle on my screen during boot when I stuck the card in my G3. Shift key or not, same result. FSCAPP doesn't fix it.

Finally, I flashed the new chip manually with my programmer to contain the raw dumped contents of the original chip. Still black rectangle on screen during boot. Can't seem to get past that problem now...no idea what to try at this point. Something is causing OS X to crash, I think. Maybe it's a kernel panic, not sure.

Edit: Yeah, booted in single user mode and it is a kernel panic, the firmtek driver is causing it. Hmmm...

 

[dougg3]

OK, I'm completely and utterly puzzled...

I grabbed the chip (Pm39LV040) that came on the card. Dumped the contents of it to a file. Read it multiple times to make sure I got a good dump. Took that dump and flashed it to an SST39VF040. Read it back multiple times to ensure it was a good flash. They are both the 70 ns versions of the chips, both take 2.7V-3.6V supply voltage, both use the exact same pinout.

The SST39VF040 causes a kernel panic, the Pm39LV040 doesn't. What gives?

My chip programmer is giving me a consistent bad readback from the original chip? Maybe the card's firmware checks the ID of the chip? Bizarre. I'm too afraid to do anything to the original chip at this point until I figure out what the heck is going on.

 

[CC_333]

Hmm, that is quite puzzling.

Keep trying though. I'm sure you'll figure it out (you grappled with the ROM SIMM for quite some time before you came up with a workable solution, and I'm sure this time is no different).

Good luck!

c

 

[dougg3]

Thanks for the encouragement, but I'm totally lost.

1) UPDFLASH.EXE in DOS seems to be notoriously unreliable. It always fails at flashing my SST chip in random places, even though I'm trying to flash a file that's 512 KB in size, the exact size of the chip. Haven't tried the original chip because I don't want to change it. I did use it to get a readback of the original chip, and the original chip is definitely reading back correctly in my programmer.

2) No matter what I do, the SST chip when stuck into the card either causes a kernel panic, or it doesn't appear at all in the system profiler, but my chip programmer reads it back as a perfect copy of what's on the original chip.

I guess maybe I should try a new SST chip, or try to find another Pm39LV040 chip (or an MX29LV040QC) instead. All I can possibly imagine is that maybe the chip I'm using is bad or something.

Edit: Oh, btw, the WiebeTech flasher works and successfully flashes the card. It works because my new chip is SST which it supports. But then I still get the black screen kernel panic after a reboot. That's true with both the WiebeTech and the FirmTek firmware.

 

[techknight]

do you have a known good copy of the chip dump? a copy that known works and boots a card? if not then of course it wont work.

Also, as far as the chip ID, its VERY VERY VERY possible. I know this because some bootloader blocks do check the presence of the correct chip before the card will boot. This is bootloader related, not firmware related (unless the bootloader is in the firwmare binary)

As far as anything else, I have no idea. Only thing you can do at this point is get another card identical, dump it, and then move the chip over and see if it will boot the card.

its also possible that the main IC has internal memory as well....

also dont rule out the fact that the card could have suffered a general failure in the main IC, and when CC was flashing it, that IC failure could have been coincidental to the flashing of the IC.

 

[dougg3]

The chip dump has to be good. I've read the original (working) chip using my chip programmer and in-system from the DOS flasher utility and the dumps match. No matter how much I screw around with the card in the DOS utility, if I put that original chip back in, it works fine in OS X.

I'm really almost starting to wonder if there's something that's checking the chip ID. I'm pretty sure the SST chip I'm using is used on cards that have this SATA chip, because it's explicitly listed as one of the supported chips in the DOS flasher utility. But I wonder if it could be a copy protection thing where FirmTek only supports the chips that it has used in manufacturing or something. I dunno...maybe I'm talking crazy.

You're right, I need another known working chip to confirm for sure.

(I'm not sure if you're following, but I don't have CC's card yet...I bought another one on eBay that is known to work)

Edit: Actually, you know what? The WiebeTech firmware appears to work with the new SST chip after I flushed the kext cache (SeriTek likes to leave stuff behind and that has to be flushed from time to time). At this point I'm really starting to think that the SeriTek firmware is panicing because it doesn't like the chip ID...

 

[techknight]

ooohh.. ok. I see.

Well when I used to do R&D with broadcomm based STBs, the way they worked was the main chip actually had its own internal ROM, and an OTP ROM. Small, about 128K. The way it was setup is the broadcomm ROM basically checked the flash memory bootloader section for a valid chip ID and signature before handing control over to the IC, and this key was stored in the OTP, well the public key anyway. The chip ID function and even the signature function was settable via the OTP block. Once programmed, that was it. it was set. no changing it.

This basically insured that only the authorized firmware provider could ever put firmware on it, otherwise the CPU would never boot unsigned code. However there was a flaw that you could drop the multiplier and clock glitch the CPU to screw with that, but thats another topic entirely.

once this check passed, the control was handed over to the flash bootloader and that was responsible for checking and decompressing the firmware, and the rest is gravy. the STBs I worked with usually had the bootloader section of the flash, actually locked. so you couldnt ever re-write that sector of the flash without replacing the IC. yea, it was insane.

Not sure how that one is designed though.

 

[dougg3]

Interesting about the internal ROM vs. OTP ROM. I don't think it's anything in the chip itself because after running the FSCAPP utility (which basically just clears the kext cache), the WiebeTech firmware boots perfectly. I don't have a spare SATA drive handy to test with, but it seems to be appearing in System Profiler correctly.

Hmm!