I have started this thread to ask for a little help from @hanson or anyone with an Asmedia 104x USB 3.0 chip. I have located a 130704_10_02_01 firmware in a .ffs module and I’m trying to see if it can be extracted for flashing. This may seem impossible, since the stand-alone firmware has a custom 5 bytes checksum for CFG table and another 5 bytes checksum for the body, while the embedded firmware has none. But I want to see if it there is a way to avoid this. Download this firmware and put the content on a bootable DOS USB. You can then run from the prompt command:
104xfwdl /? - for a list of commands 104xfwdl /D - for current firmware and SSID/SVID 104xfwdl /A - the most important, for backing up current firmware. Upload this here, with the info from /D command. Users with programmer and clamps can also try to read some chips around the Asmedia controller and upload them for inspection, if the /A switch fails.
I won’t ask anyone to flash this extracted firmware, since it has some risks. In fact, I will provide the newest stand-alone firmware, version 131025_10_11_03, for those who just want the original stuff. A warning though: this was released for a RocketU external card. In theory it should work for any 104x chip and should also be easily reverted to older versions, but the practice is a different thing. Users should modify 104xfw.cfg with their corresponding SVID/SSID.
I don’t have any Asmedia chip to test this and it is only for tinkering. I don’t expect/offer any important result, so neither should you.
EDIT by Fernando: Thread title customized to be able to merge all existing posts regarding this topic
OK so here’s a dump from my chip using the ASMedia flasher. SVID = 0x1849, SSID = 1042 and running firmware is 120816_02_02_6d. Firmware is located inside a MX25L5121E SPI ROM.
Hmm, I flashed the new firmware successfully. But when I verified it told me that I’m on FW 10083_00_00_0d now. The controller works in DOS environment but not under Windows anymore. Coming to think of it I think I had this problem with the 13x FW from station drivers a couple of weeks ago already. I’m not sure how I solved it (flashing back my backup was not possible) but I investigate
Best regards hanson
EDIT:
On this picture you can see the errror I get. Do you think it has something to do with the filesize (it’s double from the size of the file that came with the downloadable FW).
You need to edit 104xfw.cfg with the following: remove // from NEWFILE, SVID, SSID, then edit with NEWFILE=1 ; SVID=0x1849 ; SSID=1042. Are you sure that your chip is 1849&1042, since normally should be 1B21&1042? What does device manager shows?
I have checked the dump and it is the same as original bin + padding. This is how it looks when comparing with a similar firmware from another ffs, meaning stand-alone vs embedded in BIOS:
[[File:Header+cfg.png|none|auto]]
I know that the checksum is 5 bytes, because this is how it looks with custom 104xfw.cfg
Even if I copy the header from another firmware, since it is just CFG table, I still have to add a checksum to the body:
I can patch the 104xfwdl.exe to ignore the checksum and flash as it is, but I don’t know who would test this kind of stuff. Anyway, a newer and original firmware is available, so nothing is lost. Thanks for all your testing, even though I don’t say this all the time. I hope you will also let me know on the UEFI VBIOS for GTX680.
OK I will try that. Yeah the UEFI GTX BIOS is waiting to be flashed. I have some problems regarding the soldering work unfortunately. I found a good chip and now I’m looking for someone who can solder it back in place…
If you try with custom .cfg and it still fails, then here is original 120816 firmware to be flashed from Windows.
If you get problems because of different SVID/SSID, even though it shouldn’t happen, copy the .bin to the 130201 or 131025 folder, alter 104xfw.cfg with the values I told you, edit u.bat with the name of the bin, in this case xHCI_v120816_02_02_6D.bin, then flash from DOS.
All 13xxxx firmware come from external cards with 4 USB ports, so maybe this is the problem. But I still advise you to try with custom .cfg
Thanks, the original FW brought it back to life. 13x FW does not work even with altered cfg. I also tried to flash it with the win flasher from 12x FW but it leads to an unusable controller…
The CFG table is different between onboard and external, also the signature. The CFG table is the same for all similar devices, onboard has one and external has another. After the body size comes the body and the footer:
I have found a 130125_00_02_00 firmware that is similar to 11xxxx and 12xxxx branches. I think this has 90% chances of working for you, maybe editing 104xfw.cfg is required.
I have also added the onboard CFG table to the latest 131025 firmware. Flash at your own risk. The interesting thing is that the 130704 firmware from Asus mainboard BIOS has the same structure as 130201 and 131025, which makes me think that the CFG table has an important part.
Edited: Asmedia_asm104x_131025mod.rar was removed because it was bricking the controller.
OK, so the 130125 FW is working without issues. Unfortunately I flashed your modded FW afterwards. Now the controller and SPI is not recognized anymore. That makes it impossile to revert neither under dos nor windows. Think I have to give the Bus Pirate a try as I don’t want to desolder the flash. I own a Bus Pirate v4.0, unfortunately I didn’t manage to get it working so far. Do you have some experience with it? Flashrom fails to init the programmer…
This should be my fault, since I didn’t explicitly wrote that you must first probe the chip with a programmer, to be sure of reverting even in case of misflash. I just thought you will do it anyway and I also thought that it shouldn’t be that hard to downgrade. Anyway, I hope you still have some working ports, since the specifications of your mainboard tell that only the front ports are handled by Asmedia.
It is sad that this happened, since I just got to the rest of unknown bytes:
The header is common for all onboard devices:
But the external cards have a different header:
That is why I thought it might be easy to just port the header from older firmware. The firmware 130704, which was found in Rampage IV mainboard BIOS, has a similar structure with 131025 and I again thought it is just a matter of right CFG Table. Someone knows if Rampage has some extra features that might make them to work with the same firmware as external cards?
Back to your problem. You should probably try with your programmer and some clamps, maybe it will detect the chip. By looking at this picture, I would say that the Asmedia controller is at the bottom and the chip under it. The datasheet for the chip is here.
But better start with the flashers I attached. Unrar to a bootable USB and run from DOS prompt: testDOS or testDOS.bat See if it detects anything from the chip. It will loop trough all the folders and run some commands, so better be patient and watch the screen, press any key when asked. If no sign of life, use the same folder from Windows and run testWIN.bat
Next stop is with Bus Pirate. Make sure you have the latest firmware for it, then download the flashrom attached, which should work from Windows. Cut power from the mainboard, attach the Bus Pirate to another system and check the COM port (example here from this post), then connect to the chip. Connect like in here and the datasheet of the chip, read the options here.
Open a command prompt from the folder containing the attached flashrom and type: flashrom -h (for help) flashrom -p buspirate_spi:dev=COMxx -r asm1042.rom (to read the chip, where COMxx is the port, like COM8, COM13…) - if the reading goes well and the dump is the same as the flashed 131025mod.bin + padding, then go ahead with the next command, otherwise post here with results. flashrom -p buspirate_spi:dev=COMxx -w DE0_026D.BIN (to flash the backup bin, which should be in the same folder as flashrom. Then flash from DOS to 130125)
No need to worry. It’s just front usb as you already found out. And so I get some skills with my bus pirate ;-). I managed to get it working already (the hint with specifying the com-port was what I needed). Tomorrow I will move my secondary PC in front and try some flashing. Your ASMedia flasher did not work unfortuntately but I have the feeling that I’ll manage it by bus pirate and report straight after.
Best regards hanson
EDIT: I made several tests with the BP and different SPI’s I had at home. All works great and as it should. If the MXIC chip is supported I will habe success for sure ;-). By the way, do you have a newer “flashrom for windows” available? I updated my FW to version 6.3 (which is the latest) but the flashrom release seems to be a bit out of date.
Unfortunately I have to report that I had no success It seems as if the chip is not good for in-circuit programming… Flashrom hangs when connected to the chip. I consider what to do now, because anyway I still look around for someone nearby who can solder (because of the GTX 680). And at the moment it’s not a big issue without the 2 ports.
It is easy for me to overlook the risk, when it is not my hardware in line. I hope you won’t keep something against me for this foolish dreaming of easy modding. I still don’t understand why manufacturers don’t provide a more reliable method of identifying controllers in case of a bad flash. If you want to have something to play until you flash the chip:
- download again the package from here and rename libusb0_x86.dll to libusb0.dll. I previously uploaded a newer libusb0.dll, maybe it had problems. You can even get libusb0 from here and install the x86 filter. Connect the Bus Pirate and run from flashrom’s folder: flashrom flashrom -p buspirate_spi:dev=COMxx Does the chip gets detected? - you probably used some clamps for connecting the Bus Pirate, so why not do the same with your EZP programmer? - maybe you will have better luck from Linux, since you can build from latest source?
Again, this is not a solution, just something to try when you are bored. The harm is already done.
Not your fault at all mate… I’m fast and interested in flashing everything that can be flashed and know well about the risks that come with it ;-). I will play around a little more and if everything fails I either live with the missing two ports or I find someone to desolder another day.
My understanding is that firmwares 130201, 131025 from HighPoint RU1144C and 130704, found on Asus Rampage IV series MB BIOSes (also in Asrock FM2A88X Extreme6+ & H81M-HDS FYI) are for the ASMedia ASM1042A chip, not for the ASM1042. This explains the difference in size & structure (and the 2104B instead of U2104). Also, the ASM1042A allows the upload of the firmware through BIOS support, not only with an external SPI ROM, as the ASM1042 do, hence the inclusion in the MB BIOS (the 130125 firmware, found on Asus RT-N65U, is indeed for the ASM1042). Nonetheless, the 131025 firmware might be of interest for people having a ASM1042A on their MB, you might want to talk with LongSoft about it, in order to include it in UBU, after testing.
Firmware is an integral part of the module "OnBrdDevDXE". The module "OnBrdDevDXE" is different for each specific motherboard is. For each model motherboard is, you must manually, using the hex editor to integrate firmware and then the resulting module is inserted into the BIOS that where it was taken
Thanks for the better explanation! My first (and bad) assumption was that it must be something like front/rear ports or onboard/external. But reading the specs and looking at the header, it makes perfect sense to see it as 2 different controllers. I have to say sorry again, Hanson.
Unfortunately, as Sonix already pointed, the firmware is somewhere in the middle of OnBrdDevDXE or Asm104x_DXE, which is a mainboard dependent module. I suppose it can be updated with a hex editor, since it lacks the header, but I doubt anyone would want to risk it. Using the standalone flasher is a better solution.
Even extracting those firmwares - Nec and Asmedia - is a tricky business, because they are missing the header for the flasher. It can be reconstructed with a bit of work and testing, but again, who would put his mainboard on the line of fire after the last fail? My first guess is that the header can be extracted from older firmwares, but my guess also failed a couple of times.
Anyway, every bit of information counts, so thank you again for your valuable input.
![IMG_0227[1].JPG](/uploads/default/original/2X/3/331d133d463ba557e40e6170a2e8b260e1291b3f.jpeg)
