I flashed Image3, and no SATA. Then flashed Image2, and no SATA either.
I got a post boot screen from the Marvell controller showing the PATA DVD-Rom.
[[File:20140224_190415[3].jpg|none|auto]]
I then flashed Image1 and the boot took forever. I cleared the CMOS, and nothing changed. Tried to disable the controller and reenable to no avail. I then tried to reflash any of the other Images, but the flash tool after taking forever gives a message "No adapter found".
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
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.
I had not got the Marvell RAID Utility installed, will install it at home.
At bootup, the behaviour is as following. I turn on the power, fans are at full speed and it takes a while till they slow down. No image in the monitor. During this time Dr. Debug shows 2A. When I get image, the POST is quite slow. I can access the BIOS. Marvell controller shows up, and changing the settings give same result. After POST complete I can boot into Windows 7 x64 using the built in Intel ICH10R controller. Windows startup shows some hiccups, but can boot succesfully. Marvell controller does not show in the Device Manager, even while enabled.
Clearing the BIOS at this time did not affect this behavior.
Regarding the chip reflash, can you confirm if it can be done without desoldering using a SOIC8 clamp and the proper programmer? If I were to buy the clamp and the flasher, can you advise me which will work? I do have some knowledge on electronics and am very handy, but have no clue on EPROM chips and flashers.
So, if I understand correctly I should use AMI Flasher with options to clear up some garbage the Marvell flasher may have left in the BIOS (or incorrect leftover configs after the controller update), and also to ensure that all the variables are correctly initialized. So far, I can use the Win64 or the DOS version of the tool. Which of the two will you recommend? I guess the DOS tool should be safer (no antivirus nor any Windows program that may interfere). Using DOS I will not have the option to use the original ASRock flasher (but I will have the BIOS collection in the same USB just in case anything goes wrong so as to flash them using the AMI flasher).
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?
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?
I have tried many different options to no avail. Initially I have flashed back the ASRock firmware 2.70, cleared CMOS and disabled everything. I then selectively enabled the Marvell onboard controlled in different configurations with the Intel one. I then upgraded the BIOS to 2.81 (using the AMI tool with the switches as suggested) and tested again.
The result can be summarized as following: if the Marvell controller is disabled, the computer boots with the right timing, starts up and everything goes perfectly fine. If the Marvell controller is enabled, no matter if it is in IDE or AHCI mode, the POST takes a long time (Dr. Debug showing 2A during this time). I can boot into a USB drive, but the Marvell Flash tool result in "No adapter found".
It looks like the controller firmware got screwed beyond repair, so it cannot initialize itself properly and that delays the boot up while the motherboard BIOS tries to initialize it.
So far, the options I can think of are:
* Try a different flasher version or experiment with other options to force the flash. There may be an option to flash to a specific address (though it is undocummented and I have no clue on that). Is there any other tool that can be used
* Look for a service that can give a try flashing the chip onboard. Even though the flash may not go perfectly fine, it may fix the initialization and enable me to use another image. As a last resource, I may desolder the chip and have it flashed, or perhaps buy a spare one and have someone in the forum have it flashed and mailed to me. For this chip flashing option, which Image will be the safer bet to restore the original functionality? Do you think that flashing onboard may screw up anything else, or the worst case will be that it wont flash properly?
* I will contact ASRock support, and see if they have a different set of tools, or even if they could provide me with the propper firmware image to flash (either by the mvf_mag.exe tool or using an external one).
* As per your suggestion of flashing a modded BIOS with an updated Intel RAID OROM, is it a shot in the dark or do you think it may work? If it poses a low risk, I may test this option.
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 tried before the go -aid 0 and go -aid 1, will check go -aid 2, though I do not think it will work.
I have contacted ASRock and will wait for their response. I am currently using the motherboard with the Marvell SATA disabled. As soon as they reply, I will provide them with all your listed information on the different BIOS and shadow requirements. You may be right regarding the overflow. I will check with Fernando and if it is ok to direct them to this thread.
I do not currently have a programmer and would not risk bricking the motherboard completely. I have also requested them for a modded BIOS with the updated Intel OROM for my motherboard version as Andrea posted (his is an ASRock X58 Extreme, mine is Extreme3).
Also, I am locally looking for a motherboard repair service with the tools for properly flashing this chip. I may even buy a programmer for the sake of testing, but they are extremely expensive in my country.
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.
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.
Thanks. I have contacted Marvell tech support, but they have forwarded me to a local sales office to get support. I will insist, but it is unlikely they will help.
I will keep you all updated.
@lordkag Do you think i will be safe to mod the 2.80b bios to include the
I will have to dig into my forgotten tech projects drawer. I have a PIC controller programmer that may work to flash the BIOS.
Thanks. I have contacted Marvell tech support, but they have forwarded me to a local sales office to get support. I will insist, but it is unlikely they will help.
I will keep you all updated.
@lordkag Do you think i will be safe to mod the 2.80b bios to include the
I will have to dig into my forgotten tech projects drawer. I have a PIC controller programmer that may work to flash the BIOS.
I have found a tech service here that has the tools for flashing the Winbond 25x40BVsig chip. He will have to desolder it in order to flash it. It will be quite an expensive repair, and so I would like to have a bulletproof image to flash, as any subsequent flash will be as expensive.
I have requested it again from ASRock.
In the meanwhile, any other suggestion? Is the ASRock bios easy to flash, because if I set myself to flash the controller chip, before that I may try to flash a modded bios with the controller firmware embedded. Worst case scenario I will have the chance to flash both chips.
I won’t hold my breath when it comes to Marvell, based on what I found in their firmware so far. You are still better of with Asrock doing proper tech support, customer oriented.
Your message is cut off, but I take it you meant including Marvell OROM in mainboard’s BIOS? Space doesn’t seems to be the problem and I don’t see any apparent reason for it to fail to the point of bricking your board. But why risk it all based on a hunch?
If you do get BIOS support from your programmer, maybe you can try with the attached files. They have the same 1.0.0.1033 OROM, but with different ID.
It is too bad that you found the service to be so expensive. I know I have searched for a few days until I could found a good one, with almost a third of the price asked by others. They are just not so easy to be found.
I still think that the safest bet is the use the backup-original image you got, then you could use the Marvell flasher with a good image you have. Or you can wait for Asrock to provide a clean (possibly updated) image, but it has to be a 512KB SPI image.
You can first test your programmer for reading support. If it works you might have a chance for writing also. But use the above images with the Asrock built in flasher, only if it fails to boot and fails to restore a working BIOS (read this, but you can also use a USB stick if you don’t have a floppy), then you can use the programmer.
@lordkag I will give them a try crossing my fingers. Unfortunately ASRock does not provide dual BIOS for my motherboard, although I have found a document that explains the AMIBIOS8 Flash Update & BIOS Recovery Methods. http://www.ami.com/support/doc/AMIBIOS8_…tepaper_v10.pdf
In case I get the motherboard to recognize the marvell controller, if I use again the mvf_mag.exe tool to try to reflash a right image, will it matter that the OROM was loaded from BIOS? Couldn’t that mess with the BIOS?
I guess that in case of a failure I could resort to this. Still I am waiting for ASRock response.
You already replied, so I will re-add the last part.
It is too bad that you found the service to be so expensive. I know I have searched for a few days until I could found a good one, with almost a third of the price asked by others. They are just not so easy to be found.
I still think that the safest bet is the use the backup-original image you got, then you could use the Marvell flasher with a good image you have. Or you can wait for Asrock to provide a clean (possibly updated) image, but it has to be a 512KB SPI image.
You can first test your programmer for reading support. If it works you might have a chance for writing also. But use the above images with the Asrock built in flasher, only if it fails to boot and fails to restore a working BIOS (read this, but you can also use a USB stick if you don’t have a floppy), then you can use the programmer.
Totally agree. I will keep searching, as I would like to receive a reply from ASRock.
Just to clarify, when you mention backup-original image you mean the 512 kb file extracted by the user I contacted over the web, and grabbed by the mvf_mag.exe tool using the -r setting? That image is not compatible with the Marvell Flasher, so the only way to use it is either to use the external programmer (I do not know if the extracted image is a raw bit-bit precise image), or use the Marvell Flasher with the rebuilt image you provided based on this file.
Can you tell if the backup image is a valid SPI one?
A 512KB image should ONLY be used with a programmer: it fills the whole chip and it already has the components at the right address. A much smaller image should ONLY be used with Marvell flasher: it has to be expanded, components extracted and flashed at the right address, a log written at the end.
You have three steps:
- if (and only IF) you decide to test with the OROM inside main BIOS, use the images from the previous message, flash them using Asrock built in flasher. If the system doesn’t work anymore, use AMI BIOS recovery with the 2.80b BIOS; if it still fails, use the programmer with a backup of your current BIOS (method has been explained a few messages ago) to preserve unique IDs.
- wait for Asrock or Marvell reply: if they provide a 512KB bin image, use that for reflashing Marvell chip at the service. You have close to zero chances of using any software method. If they provide a smaller image, you must expand that image to a 512KB one and used it at the service. Upload here any image you receive, so I can take a look at it, to see if it is well formed and clean.
- use a working 512KB image at the service. Once the chip is restored, you can use Marvell flasher again with any (small) image you desire. My recommendation: use Station-Drivers image if you want RAID + performance, use F5BJR image if you want boot. If you had had a programmer, I would have eventually found the right image for you, just as I did for Hanson. Without a programmer it is basically a one shot.
Update: I tried the motherboard BIOS mod to no avail. The behavior is the same. It looks like either there the HW ID where not correct, or to be able to correctly initialize the controller the BIOS has to be modded beyond the inclusion of the OROM.
Will wait for ASRock reply to see if they can provide the proper image. Otherwise I will go on and flash the backup from other user I have.
It was more of a hope that it will load this 1033 OROM and that it will load it before 1038. It still doesn’t rules out 1038 as incompatible. It is basically our primarily lead. If image1 had the original autoload + loader and fw 2.2.0.1125 which have been tested as working, only BIOS 1.0.0.1038 was the untested part. A smaller suspect could have been the combination between older Autoload and newer BIOS + FW, but I have seen before these strange combination in Marvell images. Another weird hypothesis would be that the actual controller has 9123 ID hard-coded, despite being labeled as 9128.
Wait for Asrock, maybe they will do another miracle. If not, search for a good service with an adequate price that does BIOS chip re-programming and point them to the Marvell/Winbond chip. They will have the needed tools, all it needs is a 512KB image.
![20140224_190415[3].jpg](https://winraid.level1techs.com/uploads/default/original/2X/8/8a7cbbe27e1a99240b49fcd1be584ebc5e87b983.jpeg)
