Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
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.
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.
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?
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...
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?
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.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.