I Just Ruined My SATA Card!!!

inb4 it is the drive that failed and the card is fine.

Either way, what card is it?

Can you dump it into a PC and use a DOS based flasher to clean up any potential mess?

Also, I think it is generally recommended to not use whatever card you are flashing as the boot device. I have never personally tested that but in the future I would suggest to go as barebones as possible for any flashing operations and that may even include a fresh OS install on a spare drive&built-in header or in a firewire enclosure or something.

Anyway, better luck next time.

If it is a Sonnet TSATA, check System Profiler for the card and try to reflash it with no drives connected to it. If it is unflashable in the Mac, you are going to need a PC and a copy of the firmware read from someone else's card... unless you want to try your hand at extracting it from the firmware update but there is something funky done to it and the operation is not as simple as it ideally could be.

Wait, so the drive running the OS was connected to the card you were flashing? What made you think that would work? That's like trying to put a new engine in your car while you're still driving it.

Is this an ebay card or was it new from OWC?

You might be able to call sonnet and just politely tell them what happened,

they might just swap it out for you?

Wait, so the drive running the OS was connected to the card you were flashing? What made you think that would work? That's like trying to put a new engine in your car while you're still driving it.

Click to expand...

Yeah... I should've known. I wasn't awake and I momentarily lost my mind :

Is this an ebay card or was it new from OWC?

Click to expand...

Neither. It was used off of Amazon, so I doubt I'll be able to get a replacement. And it's too late for a refund.
I think I'll try the put-in-PC-and-flash-there thing, if only I knew how.

Anyone care to lend a hand?

c

assuming it is a sil3112 or sil 3512 based card, you could try flasing it using the wibietech flasher, but replacing the included firmware with the on for your card

As long as the card can be seen by the system (but it dosen't have to work) it will flash the card, i used this to flash the sonnet firmware to a 3112 card with a larger flash chip installed (pulled of a pc mb, so it would have a seemingly junk firmware to the card)

It however, dose flash compleatley blindly, doing no checks to the firmware, so make sure you have the right one!

is it a sonnet? sonnet has great customer service if it is.

Have you tried running the firmware updater again?

Yes, it is a Sonnet. A Tempo PCI I believe.

I checked System Profiler, and it still recognizes the card as a Sonnet something or other, but there aren't any drivers installed (presumably, that's because of the corrupted firmware).

If someone wants to help me out with the wibietech flasher, that would be excellent. I have the firmware flasher that I used (SeriTek1S2_513), I just need a way to extract the firmware.

c

If the card is still listed in system profiler as a Sonnet then you may want to try running the flasher recommended by Sonnet again, just make sure there are no drives connected to it.

If the flasher does not like the card, it will tell you. If it likes the card but fails at the same point as before you might consider safe mode or a fresh OS or something.

System Profiler (and presumably the system at large) sees the card, but the flasher utility doesn't. When I try launching it, it says "There is no card for this utility to update." Given this, I must assume that the utility somehow determines if there's a card it can flash by looking for something in the now non-existent firmware.

I'd be willing to send this card off to someone who knows what they're doing, if I fail all attempts at fixing it myself.

But keep the advice coming in! I might yet learn for myself how to fix it!

c

p.s. Is it possible to do a raw firmware write on the Mac by using the Terminal? Or perhaps Linux?

EDIT: I think I found the bare firmware file. It is 136 KB in size. Does this sound right?

Hi,

Well, I finally figured out the WiebeTech flasher- I need to use it in single user mode in order for it to properly detect the card. However, it doesn't appear to support it . It says there's unsupported ROM.

Is there a way to modify it to support my ROM?

If not, are there similar programs which would run on a Mac? S flasher from another vender, perhaps?

So close, yet so far...

c

Looks like the firmware is indeed a 138,752-byte file in the firmware updater program:

SeriTek1S2Flasher.app/Contents/Resources/ROMFILE.1S2

I'd try to help patch the flasher, but my PowerPC assembly skills are very, very limited. I wonder if it's possible to use a PC-based flasher to flash that file to the card? What does the ROM chip look like on the board? Is it socketed, or (more likely) a chip soldered to the board?

I have the same findings.

It should theoretically be possible to flash it to the card using a PC flasher, but it doesn't take for some reason.

The ROM chip is soldered to the board. I can take a picture of it for you if you like.

I think the file might be encoded somehow, because it seems a wee bit too big (I think it's supposed to be 128K, yet the file is actually 136K).

Yay! Progress!!

c

Yeah, you'd probably think it would be a power of 2 in size. But then again, Mac firmwares have been known to be bigger than their PC counterparts. I'd be curious to know the size of the flash chip on the card. Can you take a picture of it and/or type the markings on it into here? If it's 128KB in size, then we'd know for sure

When I run the "file" command on the firmware file, it tells me:

ROMFILE.1S2: BIOS (ia32) ROM Ext. (64*512)

What does the PC flasher do when you try to flash it? Also which PC flasher did you try? I've found UpdFlash and SiFlashTool on the Silicon Image website. SiFlashTool seems simple enough to figure out because it's a command line utility. I have to be honest -- I'd have more luck figuring out how to patch the WIndows flasher to force it to work than the OS X flasher, simply due to my lack of experience disassembling PowerPC assembly, and I have access to some nicer disassembly tools that don't work with PowerPC.

But then again, Mac firmwares have been known to be bigger than their PC counterparts.

Click to expand...

Part of the size of the Sonnet firmware, I suspect, is that it has to include SCSI Toolbox emulation in order to allow booting of pre-OS X systems. By comparison, the smaller WiebeTech firmware just has to set up the OpenFirmware correctly in order to pass control to the OS X driver.

My limited experience with the DOS flasher was that it may require padding the image out to a size which is a power of two (or possibly a multiple of 128kb). That's what ahppended for me when I used it to flash the Wiebe firmware on a cantankerous card.

The codes on the chip are:

MX 6041850

29LV0400C-70

2E957500

TAIWAN

I hope this helps.

I used SI's UPDFLASH.EXE to flash the card, by the way. It seems to be working with the card, but the program doesn't like the Mac firmware I'm trying to give it (even though it doesn't complain, it seems to write it wrong, resulting in a corrupt ROM on the chip).

I don't care how we get it done, I just want it done!

c

29LV040 is a 4 megabit (512 KB) chip, so it's definitely conceivable that the ROM is actually bigger than 128 KB. (Does it really say 29LV0400? I can't find many references to that, but plenty to 29LV040)

In particular, this is probably the datasheet for the chip you have:

http://www.100y.com.tw/pdf_file/MX29LV040QC-70.pdf

or this:

http://www.zlgmcu.com/mxic/pdf/NOR_Flash_b/MX29LV040C_DS_EN.pdf

Weird that the Windows flasher is acting like it succeeds, not much I can really do in that case then. The only other thing I can think of is maybe we could patch the WeibeTech flasher to recognize that particular flash chip...flash chips generally always talk using the same JEDEC protocol, so it's kind of interesting that they limit it to only work with certain chips. You can read a manufacturer and a chip ID from most flash chips, so that might be what it's restricting itself based on.

In particular this chip identifies itself as manufacturer 0xC2 and device 0x4F.

Well, I tried to figure it out, but my PowerPC assembly skills just aren't good enough to know for sure, and I don't have the fancier tools that I have available for x86 and 68k (instead, I'm stuck using otool for disassembly, which is icky).

As far as I can tell, there's something in the WiebeTech kext that reads the manufacturer ID of the chip and doesn't accept it as a valid chip to flash if it's not SST, Winbond, Atmel, or a couple of others. Yours is Macronix. It might be possible to replace SST's ID (0xBF) with Macronix's ID (0xC2) where it checks for the ID to fool it into thinking it's an SST chip, which is at offset 0xAB3 into the kext's binary file (WiebeSATA3112Flash.kext/Contents/MacOS/WiebeSATA3112Flash)

You could definitely try making that change with a hex editor if you want. I don't know for sure if it checks the device ID as well, so it might still fail the check (in which case someone will have to take a deeper look at the disassembly). I also take no responsibility if this bricks something, because it's essentially a shot in the dark But Macronix's chip should definitely support the same JEDEC protocol that would be used when talking to the SST chip.

I'll be happy to take credit if it somehow works though! ;-)

Well, I think I may have a lead on another one of these cards!

I'm obviously going to keep trying to get this one fixed, though.

Are there any other DOS flashers that I should try? Are there any which are known to successfully put a working Mac ROM on there?

c

I don't know of any, but did you try patching the WiebeTech flasher like I described? That's the only idea that comes to mind from me anyway...

did you try patching the WiebeTech flasher like I described?

Click to expand...

I would If I knew how.
Perhaps I should learn!

But that could take time, so would anybody who knows how be willing to do that for me?

I'll keep trying...

c

Assuming you're using the WiebeTech 3112 flasher, try this kext in place of the bundled one. I did the patch I described. No guarantees, but it should get further than it currently does...

I'm assuming you will put the firmware you're trying to flash in place of the WiebeSATA3112.bin file...no idea if the stock WiebeTech firmware will work by itself.

WiebeSATA3112Flash.kext.zip

Thank you!

I'll give it a try. Is it going to pop up with some sort of message, or is it silent?

c

I have no idea what it will do just follow the directions supplied with the WiebeTech firmware...

OK, I'll do it once I get the G4 set up again.

c

p.s. New Page!

Well, it works, yet it doesn't.

It no longer complains about not supporting the EEPROM, but now it just sits there, and the firmware that was there has been erased. I let it sit for like 10 minutes, and nothing happened. It's like it crashed or something.

Why?

c

Hmm, not sure. I guess maybe the code that handles the SST programming doesn't work correctly with the flash chip on your card :-( I don't understand why though, because they all should talk using the same standard.

I could try patching it to use the same code as Atmel or Winbond instead maybe...

It will still recognize the card if it has an empty firmware, right?

It will still recognize the card if it has an empty firmware, right?

Click to expand...

It appears to, fortunately.
If you wouldn't mind re patching it, that would be excellent.

This research might prove useful for re flashing generic PC cards for Mac.

c

OK, took me a bit of time. I think I got it. Here are different kexts for you to try. I patched all the places it looks for Atmel's manufacturer ID, PMC's ID, and Winbond's ID in the three kexts in this zip file. Hopefully one of them will do the trick.

I thought about it some more and although writing to the chips is generally exactly the same, the problem may also be that the sectors are write protected and it's trying to unprotect them (I believe the exact procedure for enabling/disabling write protection can also be a manufacturer-specific thing). If I can take some time to better understand what the assembly code is doing, I might be able to help further with figuring out what the code is actually telling the chip to do.

If you try a kext and it doesn't work, I'd probably recommend rebooting just to make sure the remnants of the previous try aren't hanging around...

PatchedKexts.zip

Just curious, did you get a chance to try any of these other kexts? I sure hope one of them does the trick...

I've tried some of them.

Two failed so far .

Atmel and PMC were the ones that failed. I'll try Winbond next.

If that doesn't work, what do we do?

c

EDIT: Winbond failed. What now?

Ah, rats. At this point I'm completely out of ideas :-( no idea why the WiebeTech flasher won't work after my patches. I really truly do believe the PC flasher should be working. Only thing I can think of is like jruschme said, maybe the firmware needs to be padded to be a 256 KB file in order to flash correctly in UPDFLASH.exe...

I thought about this some more. Maybe we should look into patching the original Sonnet firmware updater to bypass whatever check is making it not recognize the card. Couple of questions: which Sonnet TSATA do you have? 2 port? 4 port? 8 port? And what is the Sonnet firmware updater you originally used? The version 2.2.4 update?

It's a 2 port, and I used the FirmTek SeriTek/1S2 5.1.3 Firmware and Driver (this Sonnet card is a re-branded FirmTek card).

c

I think the mystery is going to be why the FirmTek flasher doesn't recognize the card. I see the screen you mentioned that says "There is no card for this utility to update". There has to be a way to get it to skip whatever check it's failing...but first I have to figure out what the check is that fails.

I think that's the key, because only the updater seems to know how to put the firmware on there.

c

There's a function called LookupIDECards() that gets called as soon as you click the Accept button in the license agreement window. I think that's the function, we just need to figure out what it's doing to detect the cards installed in the system.

I did some tracing with gdb, and here's what it does:

• It calls IOMasterPort(MACH_PORT_NULL, &masterPort) to get a port to communicate with IOKit
  
• It calls IORegistryCreateIterator(masterPort, kIOServicePlane, kIORegistryIterateRecursively, &iterator) to get an iterator to iterate over everything.
  
• Then it goes into a loop calling object = IOIteratorNext(iterator)...
  
• On every iteration it calls IOObjectConformsTo(object, "FT_ATA_Sil3112") (which is returning false because I don't have any of those cards)
  
• For some reason if IOObjectConformsTo() returns false, it keeps trying a few more times with the exact same call before finally doing IOIteratorNext() to move onto the next item. No idea why.

It looks like maybe without the correct firmware, your card is not getting added to the FT_ATA_Sil3112 class in the IO Registry so the flasher can't find it. I'm not sure how to force it to find the correct device...maybe we could find what class name the device is currently being given (using the developer tool called IORegistryExplorer) and patch the binary to use that string instead? I'm not totally sure because I don't know a ton about IOKit and how its classes work.

One thing I noticed in the datasheet of the Sil3112 is that the very end of the flash chip is supposed to contain some initialization values that the Sil3112 will read.

The ROMFILE.1S2 file doesn't contain this info. I find this suspicious. Maybe the updater program puts it in and that's the missing piece of the puzzle. The WiebeTech firmware file has it, but it wouldn't actually be at the end of the chip on your card because you have a 512 KB chip and the WiebeTech firmware is only 64 KB in size. We could try making a 512 KB ROM file with the correct info at the end, but I don't know what that info is supposed to be on your card.

It's also possible that your card has a serial EEPROM that it gets that info from instead...but I don't see it in pictures unless it's on the side of the PCB opposite the Sil3112 and flash chip.

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.

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

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?

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...

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.

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.

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

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...

Excellent!

I look forward to hearing all about it!

c

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

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.

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

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...

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.

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

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.

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.

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...

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.

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!

Who knows, but something is checking the chip iD!

the PPC processor in the xbox had whats called "eFuses" which is basically a glorified marketing hooblah of just OTP ROM. If you can get the firmware to boot so the system recognizes the card, what it is, and loads a driver, then its booted way past all the sig checks, sanity checks, etc..

I definitely think you're right That is pretty crazy protection you were talking about there! Wow.

I think the next step is to find a spare Pm39LV040 or MX29LV040QC (both of which are known to actually be used on this card) and see if it works with that. I'm still hesitant to mess with the original known-working chip, I'm not touching it with a 10 foot pole until I have another chip that I can make work.

Well you had to have that sort of protection in "piracy" ridden devices such as gaming consoles and STBs. CableCard, Ugh I dont even wanna get into that. RSA/3DES/IDEA. One time a TV programming service used to run ECC post-processing on 56-bit DES odd/even control words, AFTER using a RSA/IDEA/RSA MECM decryption mechanism, ECC = Elliptic Curve Cryptography.

Oh, those control-words would rotate every 8 to 15 seconds with a brand new algorithm with each MECM transmission. This still happens today. Except now, the whole process is wrapped in an MDC2 signature checking to verify MECM authenticity prior to decryption, the unwrapped result contains the keyselect to know which IDEA key to pull. Once its pulled, it undergoes an expansion process that gives you P and Q to build the 1024bit RSA keys. and on and on and on and on... ill stop here. lol.

And the most amazing part about all of this, This all happens on an 8-bit 6805 based core!

But I digress.....

Hehe, pretty crazy how much they can do with a tiny core like that! I always knew CableCARD was pretty crazy. I have a few of those in some TiVos.

Looks like Digi-Key has the MX29LV040 chip. It has a C suffix that CC's card didn't have, but it returns the same chip ID. I'll give the Macronix chip a try, and I'll also grab a few more SST39VF040 chips to make sure I don't just have a weird dud.

http://www.digikey.com/product-detail/en/MX29LV040CQI-70G/1092-1126-ND/2744809

Yup. All you can do. I know flash ICs have unique serial numbers too, but thats only on ICs that have heightened security. Most CableCARDs used SLE88 infineon 8051 based microcontrollers, which house the keys to decrypt the MECM. They are VCC and Clock glitch protected, VCC uses a switched capacitor core voltage regulator, prevents VCC sagging. Clock is protected by an isolated oscillator. uses an internal RC oscillator to develop the core clock, the external clock is hooked only to the USART.

The older CableCARDs used the SLE66, which is vulnerable to a clock glitch from initial powerup before the RC Osc kicks in, it will run off the external clock early in the boot process. Proper timing is required, you can get past the transport key check and get into the siemens CardOS backdoor which is accessable only by holding the I/O line at a certain state during power up for around 200mSec.

TWC and im sure other cable companies started swapping thier cablecards and harware to the new powerkey multistream ones which contained the SLE88, and thus better security. and not the single stream cards which were SLE66 based. (vulnerable/hackable).

the non-cablecard digi boxes were running ST16/ST19 which is 68HC05 based and contain NO protections, only protection is the box authorization from the head end. But nothing stops you from using a modified non-provisioned digital cable reciever (like ones used in Tvs to get cable based HD locals), and having the keys. whoops.

nowadays though, cable has become more and more streaming based. the new cable boxes use the cablecard for the VA decoding like before, but the actual video is transported via media stream on request, and not global transmission that anyone can recieve thats connected on the network looking for it. (like sat, or older cable days). Basically a DOCSIS modem on the box, and a "glorified encrypted netflix". So you still have to have a provisioned unit (like a un/pw) to request access to the stream, plus the cablecard has to have the auth key for that particular stream. Double wammy.

Maybe it's not the flash chip at all? Perhaps there's something else wrong with the card (ESD perhaps)?

I think ESD is doubtful if the problem happened right after a failed firmware update...I'm pretty sure I'll be able to fix CC's card one way or another. Here's something interesting. I checked my system.log and on successful boots with the chip that works, this message appears:

"FT_ATA_Sil3112::InitialState: integrity check: FlashMemoryVenId = 9D, FlashMemoryDevId = 3E"

(that's the vendor and device ID that the Pm39LV040 chip returns)

There is not a similar message for the crashed boots with the SST39VF040. I think this is just more evidence that the driver is probably checking the chip ID. I looked at the flash dump and some of those strings above appear, but they are compressed with weird characters in between like trag noticed in the other thread. I think the OS X driver is stored inside the flash chip and it's compressed with LZSS or something.

Perhaps the failed update caused something to burn out on the card, particularly since it was in use at the time (e.g. an input was reconfigured as an output during a reset procedure, which meant that the input from the hard drive in use caused the pin to burn out or something).

That may be true, but I think it's more likely that the chip just needs re-flashing.

OK, so I made some more progress. Despite UPDFLASH.EXE's instructions claiming that you can run it from Windows 98 when restarted into DOS mode, I don't think it works reliably from there. So I used their other instructions and made a FreeDOS floppy and copied everything to it. With that change, UPDFLASH.EXE was able to perfectly flash the SST chip and verify its contents on the first try.

Then I booted into OS X in verbose mode (holding down command-V) and took a video so I could see the kernel panic scrollback. Here's what I saw as I stepped frame-by-frame in my video DIRECTLY before the kernel panic:

FT_ATA_Sil3112::InitialState: integrity check: FlashMemoryVenId = BF, FlashMemoryDevId = D7

FirmtekCtrllr::start: InitialState() failure

BF and D7 are the manufacturer/device IDs of the SST39VF040 from its datasheet. I'm almost 100% certain now that the driver is crashing on purpose because it's finding a chip they didn't use. Basically they're trying to prevent you from flashing their firmware onto any old PC card that uses a different flash chip. So not only does the chip you use have to be big enough, but it also has to be a chip model that they used.

That's excellent!

This means that your method of flashing using UPDFLASH.EXE in FreeDOS ought to work.

I got your PM, and I'll give it a try tomorrow.

Thanks for your help! I felt like an idiot when I started this, and you've really helped pull me through this endeavor.

c

Hmm.. It's interesting it seems to be checking the flash chip Id, since I tried flashing it to my PC Card (using a random 2 mbit sst chip I had (39sf020)) and I didn't get any kp's, the card got recognised as a seritek card, but hdds wheren,t reconised.

Flashing it with the webietech firmware got it working, but it keeps makeing my G3 kp.... I gotta try it in a G4 tommrow

Hey no problem CC_333 I saw that you were having a problem with your card and I figured I might be able to help. Hopefully this will help and we'll all benefit from the new knowledge about the firmware.

I just tried the DOS flasher to put ROMFILE.1S2 (the 5.1.3 version) contents onto an SST chip. I padded ROMFILE.1S2 with 0xFF bytes at the end so it is exactly 256 KB in size, as suggested earlier in this thread by jruschme. The verify did fail once, so the DOS flasher still isn't completely reliable...give it multiple chances if the first time doesn't work. I verified again and the second verify was successful. Anyway, it doesn't kernel panic, but it doesn't work either.

max1zzz: it looks like the kernel panic is specific to the new 5.3.1b1 version. Here are my results with OS X 10.4.11 on my B&W G3:

- SST chip, 5.3.1b1: kernel panic

- PMC chip, 5.3.1b1: success

- SST chip, contents of ROMFILE.1S2: successful boot. Apple System Profiler doesn't show the card under PCI, but IORegistryExplorer with the dev tools sees the card. Appears that the driver doesn't load.

In fact, with ROMFILE.1S2 flashed to my SST chip, the system.log file in the Console app shows the FirmTek driver 5.1.3 loading but it bails out. It doesn't have the message about looking at the chip ID, but I'd have to assume that's why it's bailing especially after what 5.3.1b1 does. Probably just doesn't kernel panic when it fails and instead fails silently. So I really, really think that the chip ID is being checked.

Edit: OH, the card extracts its driver kexts (two of them -- FT_ATA_Sil3112.kext and Sil3112DeviceNub.kext) into /System/Library/Caches/com.apple.romextensions. One purpose of FSCAPP is to clear those out after the firmware changes.

So ROMFILE.1S2 appears to have weird encoding because it contains a compressed version of these kexts that are expanded out to the actual computer. ROMFILE.1S2 should definitely be written directly to the flash chip, no special encodings. I'm sure of it now.

Yep. I found a place in the kext in /System/Library/Caches/com.apple.romextensions where the device and chip IDs for MXIC and PMC were next to each other. I changed one of them to my SST chip's ID, manually loaded the kext, and now the driver is working correctly. It's definitely checking the chip ID. It's mixed in with other data so I don't know if there are any other chip IDs present.

As far as I can tell, the chip has to be a Pm39LV040 or an MX29LV040 in order for the driver to load.

Edit: Found a SATA drive to hook up and it works on the SST chip flashed with ROMFILE.1S2! So the chip ID was the problem all along and I'm no longer afraid to mess with the original card. CC_333 should be able to flash ROMFILE.1S2 (or my newer firmware) with the DOS flasher and it should work.

What about under OS 9 and earlier?

I would assume the OS 9 driver is going to have a similar chip ID check. If the FirmTek firmware is working under OS X, I'm pretty sure it's going to work under OS 9 as well...since it was advertised as OS 9 compatible.

Dougg3, do you think that modifing the chip I'd would get my generic card working? The card is being seen as a seritek card, and both kexts seem to have extracted themselfs, but it just won't see anything connected to it

Works fine with the webietech firmware (except from makeing my g3 kp) which also seems to extract a driver to the same place

Yep, I would recommend finding one of the two chips I mentioned and putting it on instead. I bet it would work. After the kext is extracted, it loads. Code inside the kext itself decides that it shouldn't succeed because of the chip ID. So if the kext has extracted itself I'm pretty sure your chip has good firmware on it, just it's failing the chip ID check.

The only problem is I believe CC_333 has discovered that the MX29LV040 chip doesn't work with the WiebeTech flasher, so you will probably need to use the DOS flasher (or a chip burner) to get the contents on there initially.

I'm experimenting with a few ideas for how to force the FirmTek flasher to recognize a card with blank or corrupt firmware on it.

Edit: Yep, it works! I force-quit the FirmTek updater in the middle of an update. It no longer loaded a driver or anything, so the firmware was corrupt.

If you save the two kexts in that cache folder, then manually load them with kextload:

sudo kextload -d ~/Desktop/Sil3112DeviceNub.kext ~/Desktop/FT_ATA_Sil3112.kext

Then the FirmTek updater will allow you to run and flash the card. But again, the chip has to be one of the chips that is allowed to be used by the driver.

The strategy I described above doesn't work with an empty chip though. So the DOS flasher is still a good idea.

Anyway...I finally grew a pair and screwed around with the original working chip. Yep, we're all good. ROMFILE.1S2 is a valid file to flash to the chip, either through the DOS flasher or the WiebeTech flasher (except we already know Wiebetech doesn't support Macronix chips in its flasher :-( ) OK, I promise I'm done adding a bunch of random info to this thread! Whew

Edit: I lied, one more update. I started decoding the PCI option ROM. It includes an OS 9 driver as well as an OS X mkext, version 1, which is encoded using LZSS just as I suspected!

All fixed now!

I'd like to thank every one for their help and support, especially dougg3 for his persistence and knowledge.

I will NEVER flash like that again!

WHEW!!

c

Woohoo! Well, glad to hear that UPDFLASH.EXE got you up and running.

I'm pretty sure there's something about that DOS flasher that just completely sucks under the DOS mode you can reboot into from Windows 95/98. FreeDOS on a floppy seems to be the way to make it work.

And never use XP or later's "DOS". It's just an emulation!

And never use XP or later's "DOS". It's just an emulation!

Click to expand...

Understood. I can still use it to copy stuff to disk, though.
c

any DOS in an NT based windows is a no go to add on to onlyonemac's post.. 98 or lower. (ME is trash.)

I always use a MS-DOS 6.2 floppy to flash chips. Always reliable.