@lordkag
I have just noticed that the last flash made the Marvell IDE Channels non functional (I have an IDE DVD Rom).

I am eager to test your images.


Thanks again!

@Gaudi

Just when I thought that Marvell couldn't do any more mess. To continue what I started in this post, here is how the header of the image/firmware should look like:



Between those components it should be just padding, plus some bytes at the end of the chip which I asumme are some sort of logging from the flasher. When I first looked at the original image you uploaded, I thought that I stumbled upon the first true RAID firmware, which would have made my work a lot harder. But splitting the image into components and connecting those out-of-order parts, it revealed that they were actually some leftovers from firmware 2.1.1.1407 (Dec/10/2009 10:55:28) instead of padding, while the actual firmware is 2.1.0.1410 (Jan/19/2010 16:31:25). How Asrock or Marvell managed to do that, one can only imagine. Luckily, you don't have that on your chip, only the autoload is your concern.

For those looking to build an image: mostly everything in the header can be deduced, but it still needs a HMAC_SHA_256 Authentication in line 2, so using imgcreate is a must. Just avoid the image creator from last 91xx packages. It is bugged and cannot create a valid header for image, only for raw components. Use imgCreate.exe from the last 91xx package only for raw components, not for the whole image. Use imgCreate.exe from a 92xx package for creating a full image for the flasher, it creates a valid header while keeping the content intact.

Image = Autoload + BIOS + Firmware = (autoload.bin + hw_config.txt + loader) + (91xx.bin) + (Program0 + Program1 + DSRAM_Data) = (AUTOLOAD + HW_CONFIG + BOOT_HDR) + (Option_ROM) + (CODE1_HDR + CODE2_HDR + DATA1_HDR).

The original image = Image 1.0.0.1210 ; Autoload 2.0.0.0604 (ID 9123) ; BIOS 1.0.0.1014 (ID 91A3) ; Firmware 2.1.0.1410
Image from F5BJR = Image 1.0.0.1213 ; Autoload 2.0.0.0602 (ID 91A3, 91A4) ; BIOS 1.0.0.1027 (ID 91A3) ; Firmware 2.1.0.1413
Image from Station= Image 1.0.0.1808 ; Autoload 2.0.0.0612 (ID 9123) ; BIOS 1.0.0.1033 (ID 9123) ; Firmware 2.2.0.1125

Here are some test images. It is best to use them with BIOS 2.81 beta, it has a bugfix concerning Marvell controller. Also, the Autoload is a critical component involved in the boot sequence, so it is best to proceed with caution. Set Marvell somewhere in the end of the boot sequence and disconnect all other HDD/SSD, leave only the ones connected to Marvell. If the Autoload messes the boot, just use the USB to reflash the Marvell chip, or reset CMOS if all else fails. I cannot guarantee that a different Autoload will be just as benign as previous ones.

I can provide a combination of 4 Loaders and 6 autoload.bin, a total of 24 test images. But I will save you from this torture and only post 7 of them. Place the content on a bootable USB and type

cd bin
mvf_mag imagex -newImg (Edited)

...where imagex is image1 or image2 or whatever image you flash.

Image1 = autoload 2.0.0.0604 original, loader original, BIOS 1.0.0.1038 (ID 9128), firmware 2.2.0.1125
Image2 = autoload 2.0.0.0604 original, loader newest, BIOS 1.0.0.1038 (ID 9128), firmware 2.2.0.1125
Image3 = autoload 2.0.0.0617 (mod ID 9128), loader newest, BIOS 1.0.0.1038 (ID 9128), firmware 2.2.0.1125
Image4 = autoload 2.0.0.0612 (mod ID 9128), loader newest, BIOS 1.0.0.1038 (ID 9128), firmware 2.2.0.1125
Image5 = autoload 2.0.0.0611 (mod ID 9128), loader newest, BIOS 1.0.0.1038 (ID 9128), firmware 2.2.0.1125
Image6 = autoload 2.0.0.0610 (mod ID 9128), loader newest, BIOS 1.0.0.1038 (ID 9128), firmware 2.2.0.1125
Image7 = autoload 2.0.0.0612 external, loader newest, BIOS 1.0.0.1038 (ID 9128), firmware 2.2.0.1125

Image1 is the safest you can try, with original Autoload and Loader. The downside is that such an old version might be missing a few bugfixes. From there it is just testing until touchdown. I only recommend Image1, Image2 and Image3, the rest are provided in case those fails. Image7 is highly dangerous because it contains an Autoload from an external card, posted only as a last measure.

@Gaudi

I have edited the previous message. It is only "mvf_mag imagex -newImg" without "-w". The "-w" erases the chip, don't know how I misread that.

Thank you very much for your work.
I will give the images a try and will post results.

Can you confirm if Image1 is the factory default for the controller?

Also, I have noticed that Image3 has the latest autoload, newest bios and also latest firmware, so my guess is that it would be the recommended choice if it works. Is that correct?

Have you got any idea why the flash tool shows the device ID as being 9123 (screen capture)?


Many thanks again!


PS: have acknowledged the correct syntax for flashing.

Image1 has the original Autoload, which will give you booting back, but also has BIOS updated from 1.0.0.1014 (ID 91A3) to 1.0.0.1038 (ID 9128) and Firmware updated from 2.1.0.1410 to 2.2.0.1125. Normally just the Autoload matters and has to be paired with the right ID, the BIOS and firmware can have other ID. If you want the original untouched image, it can be done, but you are missing the fixes from newer versions.

If you just want the latest image, go with Image3 -> Image2 -> Image1 order, then 4 -> 5 -> 6 -> 7, until you find the right image. If you value safety, go with 1 -> ... ->7.

My guess is the tool shows the ID from the BIOS/OROM, which is 9123 for latest Station-Drivers and 91A3 for F5BJR.

Zitat von lordkag im Beitrag #20

---

Image1 has the original Autoload, which will give you booting back, but also has BIOS updated from 1.0.0.1014 (ID 91A3) to 1.0.0.1038 (ID 9128) and Firmware updated from 2.1.0.1410 to 2.2.0.1125. Normally just the Autoload matters and has to be paired with the right ID, the BIOS and firmware can have other ID. If you want the original untouched image, it can be done, but you are missing the fixes from newer versions.

If you just want the latest image, go with Image3 -> Image2 -> Image1 order, then 4 -> 5 -> 6 -> 7, until you find the right image. If you value safety, go with 1 -> ... ->7.

My guess is the tool shows the ID from the BIOS/OROM, which is 9123 for latest Station-Drivers and 91A3 for F5BJR.

---

@Gaudi

Flashing must be done with all HDD/SSD disconnected from Marvell, followed by a shutdown after flash. Maybe Image3 was far fetched with all the updates, Image2 in the middle, but Image1 should have been pretty safe. It has original autoload + loader and the firmware 2.2.0.1125 - which you already tested as working. The only strange part was BIOS 1.0.0.1038, but Sonix hasn't got any complaints since he offered this image inside UBU, neither Hanson reported any problem. Maybe it worked - if you had done a shutdown in between, maybe it didn't worked no matter what. The first image shows Marvell in IDE mode, so a shutdown followed by setting Marvell to AHCI should have been an accurate test.

This may sound like a lame excuse, but I think it may yet again come from Marvell, specifically the flasher. You have some users in this forums who complained about a bad flash, that was only solved with a programmer (more here), you have Felix who had a deeply corrupted image after several attempts of flashing, you even have your original image that has left-overs from a previous flash. There are many reports of Marvell bad flash, but this one seems quite similar. Different boards, different manufacturer, even different BIOS type (AMI vs AWARD); only the Marvell flasher is the common point. It could be that it fails to clear the previous image and that it writes in other areas. I have spent days on figuring how the firmware is assembled, I can give you all the steps so you can rebuild an image and compare it with my images. But even if I was completely wrong and assembled a nuclear image, simply disabling the controller should clear all my traps. This shows that the flasher went overboard and possibly touched something else, like the mainboard BIOS.

There are a few things to test. Does the Marvel RAID Utility (install from support CD) detects anything (image) from the chip? Does Dr. Debug shows any value? Is the chip detected during boot (Ctrl + M), it slows down the system even after boot?

Remove Marvell from boot or set it last, set AddOn ROM Display to Disabled. Check the booting time. Set Marvell SATA3 Configuration to Disabled. Check again.

Set Marvell controller to IDE/AHCI/RAID and test with each one - a) the booting time and also b) if the flasher detects the chip. Using "go -r" will save an image that will show us 2 things: if the chip is detected and what was written.

Use again the bootable USB and type at the command prompt "go -w". It will erase the chip (!!!) and give you a new start. Then flash either one of the images you have and worked, or flash the original image I attached, made from the original components, nothing touched. If it turns out to be just a bad flash, maybe you can even give imageupd a go (original autoload and loader + everything else from the image posted at S-D). Type at the prompt:

cd bin
mvf_mag imageorig -newImg

If it shows again "no adapter found", it hurts me to say this, but you may need to go to a service and reflash the chip with that original 512KB image you got.

As a last step, try to flash a previous BIOS version (like 2.70) for the mainboard, maybe the flasher changed something. Return to 2.80 and check again.
However, I doubt that Asrock flasher writes all blocks, I think it only updates some parts. You must then use amiflash for a full BIOS restore. It is very dangerous in the sense that a bad flash will brick your board. After that, the solution will be to extract the mainboard's BIOS chip from its socket and go with it to someone who has a programmer, it will most likely be supported, it is a common chip.

Download amiflash from here. Go to AMIBIOS -> afuwin -> 32/64 depending on your OS -> type at the command prompt from that 32/64 folder:

afuwin x58e3bkp.rom /O
or
afuwinx64 x58e3bkp.rom /O

This will make a backup of your BIOS chip, named x58e3bkp.rom. If you upload it here, I will inspect it to see if something important is changed. It is best to clear CMOS and restore defaults before doing this. Next comes the dangerous part.

Close all working programs, especially antivirus!
Open afuwin/afuwinx64. Click Open and select 2.80/2.81 rom file. In Setup tab select: Block options - check all; CMOS options - Destroy CMOS checksum or Load ROM failsafe; Non Critical block - All; Preserve SMBIOS - A (as in type the letter A - preserve all serials); Update MAC - you could enter your current MAC address without spaces, but leave empty; Click Flash and pray. You will see the progress. Restart only if success, otherwise try again or flash the original .exe from Asrock.

If you want to work from DOS, use the following command:
afudos your_bios.rom /P /B /N /C /E /K /R

@lordkag

Thanks for the time you devote to help us all.

I will follow all the suggested troubleshooting steps as soon as I return home from work. I will document the steps as completely as possible for debugging.


In the meanwhile, I have some comments/questions you may answer.

Zitat von lordkag im Beitrag #22

---

There are a few things to test. Does the Marvel RAID Utility (install from support CD) detects anything (image) from the chip? Does Dr. Debug shows any value? Is the chip detected during boot (Ctrl + M), it slows down the system even after boot?

---

Zitat von lordkag im Beitrag #22

---

Remove Marvell from boot or set it last, set AddOn ROM Display to Disabled. Check the booting time. Set Marvell SATA3 Configuration to Disabled. Check again.

Set Marvell controller to IDE/AHCI/RAID and test with each one - a) the booting time and also b) if the flasher detects the chip. Using "go -r" will save an image that will show us 2 things: if the chip is detected and what was written.

Use again the bootable USB and type at the command prompt "go -w". It will erase the chip (!!!) and give you a new start. Then flash either one of the images you have and worked, or flash the original image I attached, made from the original components, nothing touched. If it turns out to be just a bad flash, maybe you can even give imageupd a go (original autoload and loader + everything else from the image posted at S-D). Type at the prompt:

cd bin
mvf_mag imageorig -newImg

If it shows again "no adapter found", it hurts me to say this, but you may need to go to a service and reflash the chip with that original 512KB image you got.

---

Zitat von lordkag im Beitrag #22

---

As a last step, try to flash a previous BIOS version (like 2.70) for the mainboard, maybe the flasher changed something. Return to 2.80 and check again.
However, I doubt that Asrock flasher writes all blocks, I think it only updates some parts. You must then use amiflash for a full BIOS restore. It is very dangerous in the sense that a bad flash will brick your board. After that, the solution will be to extract the mainboard's BIOS chip from its socket and go with it to someone who has a programmer, it will most likely be supported, it is a common chip.

Download amiflash from here. Go to AMIBIOS -> afuwin -> 32/64 depending on your OS -> type at the command prompt from that 32/64 folder:

afuwin x58e3bkp.rom /O
or
afuwinx64 x58e3bkp.rom /O

This will make a backup of your BIOS chip, named x58e3bkp.rom. If you upload it here, I will inspect it to see if something important is changed. It is best to clear CMOS and restore defaults before doing this. Next comes the dangerous part.

Close all working programs, especially antivirus!
Open afuwin/afuwinx64. Click Open and select 2.80/2.81 rom file. In Setup tab select: Block options - check all; CMOS options - Destroy CMOS checksum or Load ROM failsafe; Non Critical block - All; Preserve SMBIOS - A (as in type the letter A - preserve all serials); Update MAC - you could enter your current MAC address without spaces, but leave empty; Click Flash and pray. You will see the progress. Restart only if success, otherwise try again or flash the original .exe from Asrock.

If you want to work from DOS, use the following command:
afudos your_bios.rom /P /B /N /C /E /K /R

---

One more question, there are 3 downloads for each BIOS in the ASRock webpage, Windows, DOS and Instant Flash.

DOS seems to be a self contained flasher in the form of an .exe file, whereas Instant Flash is a binary file. I assume I should use the binary file from the Instant Flash with the AMI Flash Tools.

Would you recommend using the built in BIOS flash utility, the AMI Flash Tool in pure DOS (Rufus boot disk), or the .exe file downloaded from ASRock webpage?


Thanks again!

It is best to follow all steps from above post to provide accurate details and to find the true cause.

Code 2A from Dr. Debug means initializing devices, so it could pinpoint to BIOS 1.0.0.1038 not being full compatible with your board: appearing as IDE at boot, not seen by Windows, possible not even by Marvell RAID Utility. Add these tests to the list:

- remove any devices from Marvell and test with Marvell set to AHCI, then test with Disable.
- remove as many as possible devices from mainboard: GPU if you have onboard/iGPU, external sound card, any other PCIe card. Leave only the HDD/SSD connected to Intel controller, disable any Lan Boot or Marvell boot; test with Intel (yes, Intel) set to IDE, AHCI and then RAID.
- other reports can be found on this error (see here); another user with a possible solution

I wouldn't recommend you to try to flash the Marvell chip on your one. You will need the right programmer with support for your Winbond chip, good clamps and a whole lot of luck. As you can see from Felix attempts, it might still not be enough. Try only if you already thought of buying a programmer for later use. I paid like 20 EUR for my laptop, which included the whole disassembly - desolder - write a modded image of my own - solder - reassemble process. Your board is opened, so it should cost less; the mainboard BIOS is detachable, with even lesser cost (if it really gets there).

As for mainboard BIOS: Instant Flash is the one to be renamed to something like bios.rom and used with afuwin/afudos. The other DOS/Windows is to be used as a backup scenario in case the generic amiflash fails. Normally I would recommend using afudos, with less interference. But with afudos you must use the right sequence of commands and you might get a cryptic error message, which will send you on reading pages of documentation. Use first the built in Asrock flash utility to downgrade to 2.70 and then upgrade to 2.80. If the behaviour is the same, use afudos/afuwin (your choice) with the BIOS from Instant Flash package.

You could push your luck even further and update the Intel RAID OROM from 8.0.0.1039 to 10.1.0.1008 with TRIM supported, maybe it is just a case of incompatibility between newer Marvell OROM and older Intel OROM. I can provide this update, but how would you feel if you will hit another wall and you will have 2 chips for flashing?

Zitat von lordkag im Beitrag #25

---

It is best to follow all steps from above post to provide accurate details and to find the true cause.

Code 2A from Dr. Debug means initializing devices, so it could pinpoint to BIOS 1.0.0.1038 not being full compatible with your board: appearing as IDE at boot, not seen by Windows, possible not even by Marvell RAID Utility. Add these tests to the list:

- remove any devices from Marvell and test with Marvell set to AHCI, then test with Disable.
- remove as many as possible devices from mainboard: GPU if you have onboard/iGPU, external sound card, any other PCIe card. Leave only the HDD/SSD connected to Intel controller, disable any Lan Boot or Marvell boot; test with Intel (yes, Intel) set to IDE, AHCI and then RAID.
- other reports can be found on this error (see here); another user with a possible solution

I wouldn't recommend you to try to flash the Marvell chip on your one. You will need the right programmer with support for your Winbond chip, good clamps and a whole lot of luck. As you can see from Felix attempts, it might still not be enough. Try only if you already thought of buying a programmer for later use. I paid like 20 EUR for my laptop, which included the whole disassembly - desolder - write a modded image of my own - solder - reassemble process. Your board is opened, so it should cost less; the mainboard BIOS is detachable, with even lesser cost (if it really gets there).

As for mainboard BIOS: Instant Flash is the one to be renamed to something like bios.rom and used with afuwin/afudos. The other DOS/Windows is to be used as a backup scenario in case the generic amiflash fails. Normally I would recommend using afudos, with less interference. But with afudos you must use the right sequence of commands and you might get a cryptic error message, which will send you on reading pages of documentation. Use first the built in Asrock flash utility to downgrade to 2.70 and then upgrade to 2.80. If the behaviour is the same, use afudos/afuwin (your choice) with the BIOS from Instant Flash package.

You could push your luck even further and update the Intel RAID OROM from 8.0.0.1039 to 10.1.0.1008 with TRIM supported, maybe it is just a case of incompatibility between newer Marvell OROM and older Intel OROM. I can provide this update, but how would you feel if you will hit another wall and you will have 2 chips for flashing?

---

@Gaudi

From your input I can put the blame on BIOS/OROM 1.0.0.1038 with 90% confidence. I don't work for Marvell to know exactly how they coded the image, but I can work with some assumptions. The Autoload adds the device to the boot sequence after POST, meaning a wrong Autoload would prevent booting from Marvell or appear as a blinking cursor. You already had this with S-D image. The firmware determines the performance in OS and you already tested 2.2.0.1125 with success. The BIOS in Marvell is actually the OROM, which is loaded during POST in 2A stage and correctly identifies the device and AHCI/RAID capabilities.

The cause for this could be multiple. Either this new OROM is incompatible with your board / other OROMs on your board. Or you have found another case of space limits during shadowing. This 1.0.0.1038 BIOS is bigger than previous one, increasing from 27,5KB to 32,5KB and maybe it bounced a hard-coded limit of 32KB.

Your options are these:

- different flashers and options have been tested before with no success. You could try with "go -aid 0" or "go -aid 2". There are no other options to force a flash.

- contact Asrock and ask if: a) they have any reports or comment on BIOS 1.0.0.1038 being compatible with your board; b) they can provide a beta BIOS with a bigger buffer for shadowing OROM, at least 33KB for Marvell and at least 120KB for Intel. A user did just that and was answered (look here), so you should ask them for inserting Intel RAID OROM 11.6.0.1702 and increase the space for Marvell OROM.

- for flashing the chip I would recommend using the original backup image you got, even though it has some garbage instead of padding. I could clean it, but why pushing your luck? After you flashed this original image (any decent service should be able to do that), you either stick with this image or flash the S-D one and drop boot for better performance. If you find a good price, a discount for returning or even a handy friend with a programmer, you could try some images with the 1.0.0.1033 BIOS and different Autoload. I think I can limit the number to just 3 test images.

- many users reported problems when updating to 11.2.x or 11.6.x OROM, because of limited space, but all had success with 10.1.0.1008 OROM. For your board you should use 11.2 or 11.6, as it has benefits for the RAID performance, but you can also start with 10.1.0.1008 until Asrock replies.

- another thought would be to insert the right 1.0.0.1033 OROM directly into BIOS, maybe it would get loaded before 1.0.0.1038. But I don't know how your board would react to that, so a programmer is a must before testing this.

Let me know if you need the images or the modded BIOS.

Zitat von lordkag im Beitrag #27

---

@Gaudi

From your input I can put the blame on BIOS/OROM 1.0.0.1038 with 90% confidence. I don't work for Marvell to know exactly how they coded the image, but I can work with some assumptions. The Autoload adds the device to the boot sequence after POST, meaning a wrong Autoload would prevent booting from Marvell or appear as a blinking cursor. You already had this with S-D image. The firmware determines the performance in OS and you already tested 2.2.0.1125 with success. The BIOS in Marvell is actually the OROM, which is loaded during POST in 2A stage and correctly identifies the device and AHCI/RAID capabilities.

The cause for this could be multiple. Either this new OROM is incompatible with your board / other OROMs on your board. Or you have found another case of space limits during shadowing. This 1.0.0.1038 BIOS is bigger than previous one, increasing from 27,5KB to 32,5KB and maybe it bounced a hard-coded limit of 32KB.

Your options are these:

- different flashers and options have been tested before with no success. You could try with "go -aid 0" or "go -aid 2". There are no other options to force a flash.

- contact Asrock and ask if: a) they have any reports or comment on BIOS 1.0.0.1038 being compatible with your board; b) they can provide a beta BIOS with a bigger buffer for shadowing OROM, at least 33KB for Marvell and at least 120KB for Intel. A user did just that and was answered (look here), so you should ask them for inserting Intel RAID OROM 11.6.0.1702 and increase the space for Marvell OROM.

- for flashing the chip I would recommend using the original backup image you got, even though it has some garbage instead of padding. I could clean it, but why pushing your luck? After you flashed this original image (any decent service should be able to do that), you either stick with this image or flash the S-D one and drop boot for better performance. If you find a good price, a discount for returning or even a handy friend with a programmer, you could try some images with the 1.0.0.1033 BIOS and different Autoload. I think I can limit the number to just 3 test images.

- many users reported problems when updating to 11.2.x or 11.6.x OROM, because of limited space, but all had success with 10.1.0.1008 OROM. For your board you should use 11.2 or 11.6, as it has benefits for the RAID performance, but you can also start with 10.1.0.1008 until Asrock replies.

- another thought would be to insert the right 1.0.0.1033 OROM directly into BIOS, maybe it would get loaded before 1.0.0.1038. But I don't know how your board would react to that, so a programmer is a must before testing this.

Let me know if you need the images or the modded BIOS.

---

I have not yet managed to get a service that can flash my Marvell controller firmware.
I will keep looking. In the meanwhile, I sent two emails to ASRock support, one detailing the issue with the bad flash, the other to request an update in the Intel OROM.

Intel RAID Update:
They provided me with a beta firmware presumably based on v2.80 that has the Intel RAID OROM updated to 11.6.
I did not request the increase in the shadow size for Marvell nor any other tweak, as the request related to this update was quite simple and concise.
I have attached BIOS versions 2.70, 2.80, 2.81 (Beta correcting some Marvell standby issue according to their webpage) and 2.80b (updated RAID firmware) for your dissecting pleasure.


Marvell wrong flash:
I have made a summary of the situation listing some possible solutions:

* Requested a beta BIOS with a bigger buffer for shadowing OROM, at least 33KB for Marvell and at least 120KB for Intel it may work and enable me to reflash the original controller image (which I do have). I have not the knowledge to check if the shadow has been increased in the 2.80b BIOS, but can confirm that the problem exist and the flasher is still unable to recognize the marvell controller to flash.

* I requested to insert the right 1.0.0.1033 OROM directly into BIOS? Maybe it would get loaded before 1.0.0.1038.

* I also requested a clean Marvell firmware image to flash via an external programmer.


After some clarifications, the support person is to forward the request to Taiwan for them to comment.


Will keep you informed.


Thanks

@Gaudi

I looked inside this 2.80b BIOS and it seems they did the same thing as for the other user: removing logos and reconstructing the BIOS from the base. Besides greatly reducing the size of 1B and 22 modules, they did some tweaks in module 08 (BootBlock - Runtime Interface) and 55 (Extended Boot Block Region) which might hold the key for increasing space for OROMs. I don't think they tweaked something for Marvell yet, since you didn't asked anything else in that first message.

We can now remove incompatibility between Intel and Marvell OROMs from the list. The only other OROM is Realtek PXE Boot, but you said you already tested with "Boot From Onboard LAN" set to Disabled.

Increasing the space for allowing 1.0.0.1038 to fit in - or simply adding 1.0.0.1033 in the BIOS and the bootblock - might get your controller to work, but I don't know if it will be enough to make the chip visible for the flasher. It is possible that the flasher did another scramble with the image when it couldn't proper detect the chip after the first/second flash, so you might still end up with the programmer for a fully restored image.

If you get any other image, be it from Asrock or Marvell, please add it here, so I can take a look; maybe they will add something new or they will serve as starting point for something else. But I still say that I'm impressed with Asrock for the fast reply and helpful answer.