I have an Orico PASMUS3-2P Add-On PCIE USB Card. This is a 2-Port Asmedia 1042 (not 1042A) Device. I have physically verified the chip by checking model number and shape.
I dumped the original firmware using "104xfwdl.exe /A". The original firmware is Version 110530_00_02_39.
In 2014, I tried to update the firmware on the Orico card using the Firmware update available at Station-Drivers (Version 130201) - which did not work properly. I reverted back to the 110530_00_02_39 firmware.
I have now checked the 130201 firmware file header - to verify the 130201 file from Station-Drivers is for the 1042A Chipset - which explains the update failure.
I downloaded your 130125_00_02_00 file from Post 36 in this thread. I have examined the header - to confirm this is a U2104_RCFG firmware - which matches the header in the original factory firmware extracted from the Orico card using "104xfwdl.exe /A".
Previous posts in this thread indicate the firmware in Post 36 is for an embedded controller, rather than an outboard PCIE Add-On Card. Do I understand correctly? Do I require a different firmware update file?
The results of ""104xfwdl.exe /d" on the Orico card are as follows:
I have attached a file containing both the full dump of the Orico firmware (128K) using "104xfwdl.exe /A" - and also a 110530_00_02_39 firmware-update file (64K) from Orico.
Hi, Dieter. I am hoping that lordkag will respond and clarify - in regards to whether the update in Post 36 is appropriate - or whether further customization of that firmware is required to work with the Orico PCIE Card.
I finally had time to update the firmware earlier today. You update by running u.bat.
It has SOLVED my front port USB 3.0 issues!!! Before system would freeze up/hang randomly when plugging in certain USB 3.0 devices such as my Western Digital Elements SE Portable 1TB USB 3.0 drives. I plugged/unplugged over 15 times without incident! I have been trying to resolve this issue for over a year and gave up. So glad I found this thread!
Thank you everyone, especially you lordkag!! You are the man!
The original firmware was from 2011, this updated one is from 2013. I am sure there were many bugs fixed in that time period.
Edit: I am using these drivers: Asmedia ASM-104x v1.16.23 WHQL
There is no way for me to say for sure that the update is absolutely sure, but I think you can use the same firmware. Firmware 130125_00_02_00 (ASM1042) was released for an Asus-RT-N56U router, while 130201_10_02_02 (ASM1042A) and 131025_10_11_03 (ASM1042A) was released for external cards like yours. But all these firmware have also been used for onboards controllers.
I haven’t found a firmware that it is onboard/external specific, but I can’t vouch 100% that you can use the same firmware. I guess you will have take a leap of faith, like anyone flashing any device.
update to Asmedia_asm104x_131025mod update successfully
104xfwdl /D error: can not find ASMT Host 104xfwdl /u backupfile.bin error: can not find ASMT Host 104xfwdl /f error: can not find ASMT Host window Device Manager can not show and work asmedia usb
Hi lordkag, hope you can help me! I have exact same mobo and exact same SVID/SSID as user zzbloopzz. I downloaded FW from your post #36. I have created DOS usb boot with RUFUS and was able to check SVID/SSID with /d parameter and was able to backup current firmware with /a But if I want to do the update by running u.bat I always get following error : Update failed, file not found (-7) Any idea what I am doing wrong here? Would really appreciate your help since I am having occasional hangs when plugging in USB devices. Thanks in advance!
EDIT by Fernando: Unneeded fully quoted text deleted (to save space)
I had same error. You have to manually update when you boot to USB. Type the following:
1. Type "dir" 2. Take a note of the full file name of 130125_00_02_00.bin. 3. Manually update by typing "104xfwdl.exe /u 130125_00_02_00.bin (whatever full filename is of BIOS)"
IE: For me, I had to type something along the lines of this "104xfwdl.exe /u 130125_00_~.bin" The reason for this I believe is because filename is too long so DOS shortens it.
The problem is the length of the firmware file (filename). Remember going back to the stone ages requires max file name length of 8 digits and max 3 digits extension. So rename firmware file to 12345678.123 and edit .bat file (if required).
@zzbloopzz@mictlan Thanks a lot both! I feel so stupid, I never really worked with DOS before. It shows I guess… FW update was successful, let’s see if my lock-up problem is gone. Will report back in some weeks to let you all know!
1. Copied the files in the Archive attached to Post #36 to a bootable floppy disk. 2. Renamed the 130125_00_02_00 .bin file to 0125_200.bin - following the DOS 8.3 naming convention changeover used for previous Asmedia firmware files. 3. Edited u.bat to use DOS 8.3 filename - 0125_200.bin 4. Booted to DOS floppy. 5. Confirmed proper operation using d.bat 6. Ran firmware upgrade using modified u.bat 7. Firmware update noted as successful. 8. Reran d.bat to confirm updated firmware version within DOS session. 9. Powered down system. 10. Powered up system, booting from DOS floppy. 11. Reran d.bat 12. Confirmed that firmware update survived power down and restart.
Yes! It works!
Note: From what I can see - there are two forms of firmware:
1. The "104xfwdl.exe /A" command creates a 128Kb file - which as far as I am aware is a complete dump of the entire firmware-flash-memory space. If the dump is created before making any changes to the system - this file can be used to reinstall the firmware in its original state - should an error occur during a firmware-flash-update process.
2. Firmware-flash-update files are only 64Kb in size - which implies these updates only patch the "USB3 firmware space" - without touching the headers or bus interface configuration settings.
System Checks with new firmware in place:
1. Existing Asmedia Driver Version 1.16.16 successfully connects and integrates with updated firmware in Orico PASMUS3-2P Add-In PCIE Card - which uses an Asmedia 1042 bridge chip for the USB3 port. 2. New firmware and existing driver combination connects successfully to Oyen Digital MiniPro USB3/ESATA External Hard Disk - which uses an Asmedia 1053e bridge chip for the USB3 port. 2. There is a noticeable improvement in speed-of-response during bootup. 3. Most importantly - the intermittent problems with stalls during Return-from-Sleep have gone away - which was my hope for the firmware update.
Driver Update experience as follows:
1. Downloaded latest Asmedia USB3 Driver Set from Station-Drivers - Version 1.16.23 as of the date of this post. 2. Unpacked the archive and ran the AsusSetup.exe utility. 3. The AsusSetup utility launched the Asmedia USB3 Update utility, which removed the old Version 1.16.16 USB3 Driver and installed the newer Version 1.16.23 driver. 4. Tested the new drivers. Connection works through Return-from-Sleep.
Note: Do Not have your External Hard Disk active and running while performing the USB3 Driver Update!
When I tested this, the USB3 Driver Update would stall near the end of the update process until the External Hard Disk was Safely Removed from the System. Once the External Hard Disk was safely removed and powered off - even while in the middle of the Driver Update process - the USB3 Driver Update then completed normally. However, a Dialog Box appeared stating that the system was unable to automatically Format the drive letter assigned to the External Hard Disk. My Hard Disk in the Oyen Digital Enclosure was unharmed and worked normally once the system was restarted - there was no data loss. I am unaware as to whether my experience was a safety precaution built into my Oyen Digital MiniPro firmware - or whether this is a generic safety precaution built into the USB3 Driver Update process. Prudence would indicate it is wise to ensure all USB3 Devices are depowered or disconnected before performing the USB3 Driver Update process.
Background Info:
I have two motherboards here which exhibited problems with Return-from-Sleep.
These problems are probably caused by the same issues - where some users report External Hard Disks spontaneously disconnecting during use.
1. The first Motherboard is an Asus P5Q-Deluxe using the latest V2301 BIOS from Asus - with a custom Firmware update for the Intel OROM to Version 10.1.0.1008 and an update to the Marvel 88SE6121 to Version 1.1.0.L73.
2. The second Motherboard is an Asus P5Q3-Deluxe - WiFi using the latest V2105 BIOS from Asus - with a custom Firmware Update for the Intel OROM to Version 10.1.0.1008 and an update to the Marvel 88SE6121 to Version 1.1.0.L73.
Note: These motherboards are notoriously cranky when it comes to Memory Compatibility, SATA stability on the outboard Marvell Controller Chipset Ports, and Return-from-Sleep. They make an excellent testbed for compatibility issues with Hard Disk firmware and USB3 Addon Cards.
Your attached fw bu has header U2104_RCFG -> U2104_RCFG for 1042. Update in post 36 is for 1042. To update or not to is your decision. If you read the thread here you’ll notice that at least two guys killed their controllers by flashing wrong firmware. If you decide to update do a visual inspection of the ASMedia chip on the mobo to see if it is really a 1042. You should have two chips.
READ the thread and check the stuff yourself. A freeware hex editor is HxD.
I must admit that zzblooopzz, mictlan and twixt are equally right. In my attempt to give the file a clear name that would reflect the version, I forgot the DOS naming sequence. So I will reupload to this post the same firmware with the shorten name, for those that would run into the same problem without really knowing the culprit.
The two firmware are one and the same, just that /A gives you a full dump of the chip, where the firmware starts at offset 0 and afterwards is just padding of 00 or FF bytes. You can confirm this with any comparison tool or even manually by splitting the bigger file right where the small one ends. I had more than one sample to test this, based on user input. I also have some newer Marvell OROMs, in the form of 1.1.0.L75 and 1.2.0.29 (edit: Fernando already has them or newer), but this is out of the scope of this thread. Make a request by PM if you want them and I shall post them in the “AHCI & RAID ROM Modules” thread.
Thank you for the dumps, they are really helpful in building the bigger picture. You can listen to mictlan advice. The weird part is that your BIOS has already the latest firmware, but it hasn’t flashed it on the controller. So you better do this on your own.
While mictlan is right about the danger of flashing the wrong firmware, I must add some clarifications. The first user with a broken controller was Hanson, when he flashed a modded firmware prepared by me. I take this blame on me for skipping a few precaution steps and relying too much on Hanson’s programmer to save the day. I was in the process of learning and didn’t knew about 1042 and 1042A. It was shroeder that pointed this separation, in this post. The second user was vzsoft, who somehow missed the entire thread and went for the exact modded file. How on Earth he managed to do that, is beyond my understanding. How hard is to read a few posts before flashing a firmware, how hard is to miss the “mod” word in the firmware’s name, how hard is the read the very next post in which Hanson replied that his controller is broken? This is quite an achievement and is the reason why I haven’t help him, because users like him should learn the hard way to not blindly flash everything that lands in their arms.
So, from this I imply the "smarts" to adapt the firmware installation - to either an external PCIE Add-On card - or an embedded controller- are part of the firmware update executable? (104xfwdl.exe)
I will reply to the info regarding the Marvell and Intel OROMs in a post on the "AHCI & RAID ROM Modules" thread.
I’m not sure I follow your question/deduction. Are you referring to the fact that the firmware is touched by the flasher? If so, the answer is no. There is no before-after with this firmware, no customization done during flashing, not even during daily use. You can see this by dumping your current firmware and compare it to the one you flashed. They are the same in the first 64KB - the firmware space, the other 64KB are empty bytes, because the chip is 128KB. If there should be some settings stored in the chip, then it means the flasher ignores them during dumping and the only way to know for sure is dumping the chip with a programmer. But my guess is that the result will still be the same. The only customization that I’m aware of is the use of 104XFW.CFG, where only SVID and SSID can be changed.
OK. Thanks for the info. I’m trying to understand this a little better - my intent is to be able to avoid bricking a motherboard USB3 firmware - if I understand the mechanism more completely.
Is there a difference between an outboard PCIE Add-On card and an inboard on-motherboard implementation?
You already tested the hardest case - an external card. The motherboard updating has been tested by a few other users, as you can read on this thread. As long as you take the right firmware, the risk is at minimum.
