If you have a programmer, I could really use a dump from the chip inside U3S6. If not, you only have one shot and it is best to wait for Hanson finding the best image from the samples I will provide. I just need his image dump for final touches.
Here are some findings after looking into this problem for days.
The image that we call firmware is actually made of 3 main components: - AUTOLOAD = autoload.bin + LOADER + HW_Config.txt - BIOS = OROM - Firmware = PROGRAM0 + PROGRAM1 + DSRAM_DATA
The Autoload is responsible for initializing the chip during boot and determines instructions to be loaded (an educated guess). The 9120 has no RAID support, but I have seen reports that a different autoload disables the boot from U3S6, but enables RAID through Marvell RAID Utility (maybe they thought port multiplier). The speed of U3S6 is 5Gbps = 625MB/s, so a RAID is not really recommended; TRIM also not supported? The autoload seems to check for a specific Device ID (and maybe a specific 0x08 for all), despite HW_Config saying that it supports all 91xx controllers. This one only interests the ones who want RAID vs boot from disk or have problem booting from U3S6.
The BIOS provides IDE/AHCI/RAID capabilities. The only requirement is to match the Device ID. But even so, the only difference between 912x OROM is the ID.
The Firmware is the core of the controller. U3S6 has the same firmware for 9120 and 9123, plus some mixed reports indicates that even 9128 firmware (kind of) worked. So, in theory, the latest 2.2.0.1125b could be used, as it is designed for 9123. Only the practice could prove this beyond doubt.
So far it was easy, but when you go down to assembling these parts or looking at their version, Marvell’s mayhem begins. This is how they thought of labeling the image, with the first being an example to understand the theory (thoroughly tested), the second a normal image and the third an exception that follows another (simpler) rule.
This is how they label Autoload. Again, weird grouping and also inconsistent. I have seen images that have the same version for Autoload, even though they have a few bytes out of order.
The actual firmware has no apparent version in header, but the last digits can be found inside. The first ones can be found using simple deduction based on the year: 2.1.0.1404 (mislabeled 2.1.1.1404) = Nov 13 2009 16:39:19; 2.1.0.1408 (mislabeled 2.1.2.1408) = Dec 17 2009 17:48:14; 2.1.0.1413 = Mar 24 2010 14:13:53; 2.1.0.1504 = Aug 30 2010 13:32:01; 2.2.0.1118 = Jan 13 2011 11:49:41; 2.2.0.1124 = Sep 5 2011 16:22:27; 2.2.0.1125 = Oct 31 2011 14:26:00
And if you add that some onboard controllers have duplicated code in the mainboard’s BIOS, you get one nice blunder. It seems that they have come to some sense with 92xx controllers.
To conclude, I need one dump from the chip to check some minor things, then it is testing-torture time for Hanson.
Thanks for giving all those details and explaining it so well. We can see how much time and efforts it takes. Well, no, I don’t have a programmer unfortunately. In fact I don’t need RAID (have it onboard) and I have no problems booting from U3S6. But as it has poor performances, I was hoping for years a new FW would somehow help getting better read/write results. Thank you again for your work and hanson for doing all the testing
Hi again. So my programmer arrived today :-). Here’s the original dump of my U3S6 SPI. I tested the first two images already but computer hangs during initial post then. Dr. Debug says “94”. Nothing else happens, black screen… I test the other two and report later.
Regards hanson
Edit: Files Image3.bin and Image4.bin also don’t work. They look different compared to my original file.
@hanson There is no need to try those old images. I will assemble new ones asap. Apparently your chip had an image identical with IMAGE_RBasus1028.BIN posted by stress. Maybe you updated with that one. Just wait a few hours for new images.
@ Hanson Again with the torture of testing. I would need you to run them as depicted, with every image, to find the quirks of each one. I have limited the number of images to the bare minimum, with incremental steps: if one fails, I will know what to keep/replace and provide more images.
1. Start with a control test (only once, with current firmware), check system performance with CrystalDiskMark + AS-SSD + trimcheck. Run 3 tests with each software and determine the medium value. 2. Flash one image to Marvell. Check if the controller works: press Ctrl+M during boot and note the following - BIOS version; PCIe speed; Mode; Disk detected; SATA/IDE, size, speed. 3. Does the system boots from the SSD/HDD containing Windows partition when connected to 9120? Test with both Sata3 ports if one fails. 4. If not able to boot from U3S6, connect a spare HDD to 9120 and boot from Intel controllers, check if Windows detects the spare HDD. In this case it is all about selecting the right AUTOLOAD. 5. Run a performance test again. Compare the medium value with the control value.
Image1 = BIOS updated from 1.0.0.1028 to 1.0.0.1033; Image2 = BIOS updated from 1.0.0.1028 to 1.0.0.1038; Image3 = BIOS updated from 1.0.0.1028 to 1.0.0.1038; Firmware updated from 2.1.0.1015 (Jul 17 2009) to 2.2.0.1125b (Oct 31 2011); only FF padding at the end; Image4 = BIOS updated from 1.0.0.1028 to 1.0.0.1038; Firmware updated from 2.1.0.1015 (Jul 17 2009) to 2.2.0.1125b (Oct 31 2011); FF padding at the end, with a few original bytes; Image5 = BIOS updated from 1.0.0.1028 to 1.0.0.1038; Firmware updated from 2.1.0.1015 (Jul 17 2009) to 2.2.0.1125b (Oct 31 2011) and in DSRAM_DATA replaced Dev ID 9123 with 9120 and 91A3 with 91A0; FF padding at the end, with a few original bytes; Image6 = BIOS updated from 1.0.0.1028 to 1.0.0.1038; Firmware updated from 2.1.0.1015 (Jul 17 2009) to 2.1.0.1413 (Mar 24 2010, last with explicit Dev ID 9120); FF padding at the end, with a few original bytes; Image7 = Autoload updated from 2.0.0.0601 to 2.0.0.0617 (patched with 9120 ID); BIOS updated from 1.0.0.1028 to 1.0.0.1038; Firmware updated from 2.1.0.1015 (Jul 17 2009) to 2.2.0.1125b (Oct 31 2011) and in DSRAM_DATA replaced Dev ID 9123 with 9120 and 91A3 with 91A0; FF padding at the end, with a few original bytes;
Edit: Added Image8.bin with all updates from Image7, but also with the newest loader.
Check the above with all images, write all the details and share them. This will help me determine the best combination. You can then select your favorite image and test for system stability.
so I tested the images provided by lordkag. The BIOS post of the controller was fine for all images except 7 and 8 with which my PC won’t finish posting (screen stays black). The sequential performance does not give big differences: 280-310 MB/s read and ~75-80 MB/s write (with SanDisk Readycache 32 GB). Only with image 6 the performance was poor (160 read and about 70 write). I could boot Win Vista x86 from all images without problems. Functionality of the controller is always AHCI passthrough at a link speed of 5 Gb/s.
@lordkag Thanks a lot for your big work!! Personally I stay at image #5 and will test everything detailed. I wonder about image 7 and 8. They look totally different inside the software of my programmer (nearly half of the image is FF?). I will let u know if I find out even more interesting things to report. So far have a nice evening…
Hi everyone With which version of mvf_mag.exe should I try to flash from dos Please (after creating "Image" from BIN of course)? Or do I have to wait for any new upload?
I’m not sure as I used a programmer. If I were you I would start with the latest version that belongs to a 91xx firmware image. If you experience any problems you could switch to a different version.
Yes, You explained earlier you are using a programmer. I don’t have one. I tried to flash with the oldest mvf.exe I could get, but no luck. I guess changes are needed to the “DOS flash files” to make new images work, but only lordkag can do that I think. I’ll wait for new uploads.
By the way, Is U3S6 stable now after you flashed with new images (image5)?
Image 7 and 8 used the new Autoload, which seems is not adapted for U3S6. Please note that I reuploaded Image8 shortly after posting the image, so make sure to redownload Image8 and re-test it if it has a different CRC than the one you used. I also uploaded a new Image9 which has all from Image5, same Autoload, but the newest Loader. It is the last image I can imagine, you will basically have all the newest components. Image5 is only missing this new Loader. But you can skip this test if you want, as I think the Autoload and Loader only count for the boot sequence.
I am also trying to recover a dead Delock 89270 SATA III Marvell 9128 controller card (same as Lycom PE-115)
After flashing the 2.2.0.1125b version from station-drivers, the board started acting weird, the message from the flash was autoloader erase.
I got an EZP2010 programmer, to flash the ATMEL AT26F004 spi flash IC, but i’ve tried many different ways ( in-situ with SOIC clip, desoldered and soldered on a soic-to-dip board etc) and the chip cannot be erased or written.
I got today a second card to try to hotflash the old chip and i also ordered a similar Winbond and Macronix chip from ebay to try and write directly to these, if anything else fails.
The EZP2010 is supposed to support the AT26F004, i don’t know what the problem is. I can read but not write.
So, i’m glad i found this thread and most of all i’m glad that there is a person like lordkag here, with so much knowledge… Will have to thoroughly read all of the previous posts to see if i can make some use of the info in them.
maybe an update of your EZP2010 firmware may help. I found the actual 3.0 including the most new drivers and software after a long web research recently. I packed it for you including all the images for my 9120 chip I got from lordkag. Maybe it’s worth to give it a try.
I already had the latest FW, even though named 2010 ( files are identical ) and i used the latest driver.
Nothing happened again. Seems like the 26F004 is not fully supported, or it is somehow in WriteProtect mode.
Well, i am using my old laptop with Win32Home and i am using the driver in nt_xp_vista file, since the Win7 is only 64bit. Is that how you made it work ?
I am waiting the new controller on Wednesday next week and if that also fails, i’m waiting for the new flash IC’s to come.
I did it under XP x86. Under 8.1 and 7 x64 the flasher/programmer did not work. Also on my board (ASUS U3S6) there was a different flash IC used (EN25F40-100CP).
The EZP2010 programmer should indeed support AT26F004, so it is only a matter of connections. Here you have a datasheet of the chip, so connect corresponding pins to your programmer (look into its manual for pin distribution). But it is better to use an adapter like this.
The simplest way to test is to use the same image you dumped from your chip. If it is able to flash this, then you used a wrong sized image for updating. If it is NOT able to flash the same image it read, the connections are faulty. Compare the pin distribution for your programmer and the chip, connect them using an adapter (you mentioned you have soldering skills, so no need to torture the chip with clamps). If all fails, as a last attempt you can replace that chip with a working 512KB chip. Only the flasher has a database of supported chips, I doubt they did the same with the Marvell controller.
The real problem comes with the image to flash. You need a working/original dump from a similar board in order to extract the working autoload. The BIOS/OROM and inner firmware are compatible with different IDs, but the autoload is different between onboard and external boards. Hanson can confirm this last point.
To summarize: check the datasheet of both programmer and chip, connect them using an adapter, search for a dump from a similar board.
Something to play until you get a proper dump from a working board.
The seller responded that the item title says 24 25 93 Flash only, he also changed the description and the new one does not include AT26F004. Too bad for him, i have a pdf and html page or the original ( which is still available in ebay)
I have tried both with a SOIC clamp while the SPI was still on the controller ( pic for example ) and soldered on a SOIC to DIP board. On the first case, the programmer gave an error ( more info here ) because of the other chips on the board interacting with the controller.
I then used the second method, desoldered the chip from the controller board and soldered it on a SOIC-to-DIP adapter ( the SOIC-ZIF-to-DIP you have on the photo would be nice to have).
I always get an error while verifying, because the comparison of the buffer data (image to write) and the chip data fails.
I have a working image from a random 9123 board, i was only trying to revive the controller to get me in the magni-flash to use a proper ( expandable 232KB used with Magni-flash) image version .1033 sent to me by the vendor. I also got a second identical controller, so i will dump the original image from it and use it.
A spare AT26F004 is on way ( in case the first one is faulty ) and a Winbond 25X40BVSSIG ( SOIC-8 200mil ) will be ordered just in case everything else fails.
I bought many stuff to revive the controller…or is it because i want to learn and practice instead???
See the attached images.
I have also attached the dumped image from the corrupt AT26F004 ( after badflash ).
As I already said, I need an original image from a similar card, to extract the autoload + loader. External cards have a different Autoload from onboard devices, it is needed for the right insertion of the card into the boot sequence. I can only (actually you) blindly test with an Autoload I have (at least think so) from an external card with 9128 controller.
Maybe this is a long shot, but have you tried connecting the chip in the lower socket of the programmer? From the image it looks like the upper socket it is for 1-on-1 direct copy between two identical chips. Also, have you tried using clamps while the card is powered off, meaning the chip will receive power from the programmer, or even so it interacts with others?
No wonder your image is corrupted. It has an autoload 2.0.0.0617 (ID 9123, 91A3) and what looks like a chopped 2.1.0.1504 firmware, but it is missing a Loader, a BIOS and a valid header for the firmware.
The “wipeout autoload” message comes from go.bat and it stands for an “ERRORLEVEL 1” of the flasher, whatever that means. Here is how to test: dump the content of the attached rar onto a bootable USB, then type “go -w” at the prompt. Warning - this will erase the content of the chip, but it is already deeply corrupted, nothing to keep. If even this fails (post image of error), the chip is broken. If succeded, it is possible that the image was not well formed. Type next:
(cd bin → only if you’re not in bin folder)
mvf_mag image -newImg
…and if still error type "mvf_mag image2 -newImg"
One last attempt with the flasher is to have an original Autoload from the card, then it is only for a programmer and possibly a new chip. If you will use the programmer, just say a word and I’ll post appropriate 512KB images.
