Yeah I tried /srom 3 yesterday to see what happens and it worked just fine. Seems weird to me that it would flash the new firmware and say it completed but then a verify says otherwise. When you flash it also verify the flash too. So a second verify fails?
Another thing I want to do today is to verify the backup just to witness a proper working verification process, just for my benefit. Someone told me that I might have another Renesas chip but I think that is impossible. My old p5b only has Intel ports and this card clearly only has one chip on it.
Iâm glad you have figured it out. I will report back later today. Thanks again for the help, itâs highly appreciated.
Here is the /srom ? output
1 2 3 4 Â
C:\Windows\System32\0>w201fw21 /srom ? Bus:0x03 Device:0x00 Function:0x00 This Device is uPD720201(Revision 3). W25XxxV series(Winbond), Product ID = 0x00EF3012 Â
And here is the /? output for information on what W201FW21.exe can do.
C:\Windows\System32\0>w201fw21 /? Serial ROM Utility for uPD720201(Revision 2 & 3) & uPD720202(Revision 2). Usage:: W201FW21 [ /? | /srom romtype | /write file1 [file2] [file3] | /dump file1 | /erase | /noerase | /log [file4] | /address deviceaddress | /fout file5 | /verify file1 [file2] [file3] | /writeall file1 [file2] [file3] ] Â Options:: /? :Display this help message. /srom :Specify SPI-Flash-ROM device type. /write :Write both file1(.mem) and file2(.ini) to SPI Flash ROM. If need to write EUI-64, specify file3(.eui). /dump :Dump ROM Image File from SPI-Flash-ROM. /erase :Erase all of the data in SPI-Flash-ROM. /noerase :Erase process is skipped. This command is used with write command if needed. /log :Generates log file named file4. (Default log file named "log.txt") /address :Specify one target device with PCI Device Address. /fout :File out to file6 (Don't write to SPI-Flash-ROM). /verify :Verify the ROM image data (Don't write to SPI-Flash-ROM). /writeall :Write both file1(.mem) and file2(.ini) to SPI Flash ROMs of multi Host controllers on same system(computer). If need to write EUI-64, specify file3(.eui). Â Where:: romtype :Serial ROM type number (0,?). Please see the supported list. 0. Auto Select (check serial rom type automatically) Supported Serial Flash ROM List - 25Lxx/6 series(Macronix) (Product ID = 0x00C220XX) - 25Lxx21E series(Macronix) (Product ID = 0x00C222XX) - W25XxxV series(Winbond) (Product ID = 0x00EF30XX) - Pm25LD512C/512C2(Chingis) (Product ID = 0x019D20XX) - M25Pxx-A series(Numonyx) (Product ID = 0x00202010) 0x00202011) - M25Pxx series(Numonyx) (Product ID = 0x00202012 0x00202013) - AT25F512B (ATMEL) (Product ID = 0x001F6500) - A25Lxxx series(AMIC) (Product ID = 0x003730XX) - EN25Fxx series(EON) (Product ID = 0x001C31XX) - SST25VFxxx/A series(SST) (Product ID = 0x00BF0048 0x00BF0049) ?. Check Serial ROM Information. file1 :Firmware File (extension is mem) released by Renesas Electroncis. file2 :Configuration File (extension is ini) including system dependent Parameters such as PCI Subsystem ID or PCI Subsystem Vendor ID. Renesas Electronics releases a sample file. User need to modify those parameters in accordance with the customer system. file3 :EUI-64 file(extension is eui) that includes EUI-64(XX-XX-XX-XX- XX-XX-XX-XX). If the Product is hot-plug device such as Express Card, the EUI-64 must be set. This requirement is released from Microsoft Windows Logo Program. As for the EUI-64, refer to the following WEB site. http://standards.ieee.org/regauth/oui/tutorials/EUI64.html file4 :LOG File Name. In case of skipping the filename4, log.txt is generated on the current directory. file5 :Output Serial ROM Image File. deviceaddress :Format is XX-YY-ZZ. XX is PCI Bus Number(HEX). YY is PCI Device Number(HEX). ZZ is PCI Function Number(HEX). If there are multiple devices on the system, user can specify one device. Â Example:: >W201FW21 >W201FW21 /srom 0 /write K2xxxxxx.MEM CFG_201.INI >W201FW21 /srom 0 /write K2xxxxxx.MEM CFG_202.INI >W201FW21 /srom 0 /erase >W201FW21 /srom 0 /address 04-00-00 /write K2xxxxxx.MEM CFG_201.INI >W201FW21 /srom 0 /address 04-00-00 /write K2xxxxxx.MEM CFG_202.INI >W201FW21 /srom 0 /verify K2xxxxxx.MEM CFG_201.INI >W201FW21 /srom 0 /verify K2xxxxxx.MEM CFG_202.INI >W201FW21 /srom 0 /writeall K2xxxxxx.MEM CFG_201.INI >W201FW21 /srom 0 /writeall K2xxxxxx.MEM CFG_202.INI Â C:\Windows\System32\0> Â
Do you notice in the Example:: section that there is no indication of a K3xxxxxx.mem file in existance? I wonder if when this 2.1.0.0 flasher program was written that they hadn't yet (or never did) made it to firmware 3 series? Even if that was the case they still uses a firmware beginning with a 2. I have now seen Firmware versions starting with K2024 and some with an F2024 (like from that Russian site). If only I knew why. Most of the ones I have all start with the K2.
I now wonder if my first flash attempt days ago using W201FW21.exe actually overwrote the proper K3 firmware? Like it said before it said it wrote it 100%, but I never verified it. I now wish I had backed up the mem when I first installed this card. lol, but the good news is the card still works perfectly as it is today. So I haven't broke it yet... Yay, lol
EDIT: On second thought, I am sure when I first installed it I checked the firmware version from within device manager and it clearly said 2020, that hasn't yet changed. I still just do not understand why it says it is writing the files, but not really. So it is writing HALF of the chip with 2024, but not the part that reports version number?
I will follow your instructions after a large cup o coffee. Thanks again.
Quick question. What should I be using in the INI file
1 2 3 4 Â
[SubSystemVendorID] FFFF [SubSystemID] FFFF Â
OR
1 2 3 4 Â
[SubSystemVendorID] 1912 [SubSystemID] 00000000 Â
The first is what is reported by the flasher, FFFF, and the later is what is reported by AIDA64 and microsofts very own USB View, not to mention also what is read in the device manager.
You should put there the same Vendor ID and System ID that you had when you were using the original backup.mem in your device manager. Probably 1912 for vendor ID and another real number for system device ID. I do not recommend to put either FFFF or 00000000 there. If in doubt or you just donât know at this point, then flash back the original backup.mem file, reboot, and go look again at what are the real IDs in device manager.
Edit: Forgot to say that all .mem files beginning with a K are for 201/202 chips series. And .mem file with a F are for uPD720200AF1(uPD720200)/uPD720200A. So a F2 file is a revision 2 file for uPD720200AF1(uPD720200)/uPD720200A. F3 is revision 3 and F4 is revision 4. Obviously, they donât seems to work like that with the K series because those flashers clearly states that a K2 files applies to 201 chips with revision 2 and 3 and 202 chips with revision 2.
This also means that there was in total 2 revisions (not counting the original that seemed to nerver have been in production) for your 201 chip and a total of 10 types of chips with either 201 or 202 (yours is type 3 Winbond).
I made some tests of my own. I had still my backup.mem of my original firmware and put it back to see how device manager listed it. I have a uPD720200AF1(uPD720200) chip (type 2, revision 3). My device hardware ID is:
What pushed me to make thoses test is that i realised that the cfg.ini file ask for the [SubSystemVendorID] and the [SubSystemID]. The âSUBâ part got me thinking⌠Because if you look at my hardware ID, you see there is a SUBSYS number that has NOTHING to do with the Vendor ID (VEN) and the Device ID (DEV).
So i put my theory to the test and entered what any normal person would do. I entered 1033 and 0194 for each respectively. After rebooting, i ended up with:
This is where i finally realized, and it took me some time, that the 1033 wasnât coming from the VEN (vendor) at all but instead from a SUBsystemvendor ID. I mean literally. Now i had finally understood how that system worked!
It turns out that the SUBSYS number is BOTH the [SubSystemVendorID] and the [SubSystemID] combined and inverted. Meaning the [SubSystemID] is the first 4 digits and the [SubSystemVendorID] is the 4 last digits in the SUBSYS number.
So i entered 1458 [SubSystemVendorID] and 5007 [SubSystemID] and after reboot, i got this:
That is now identical to the first hardware ID i had before the firmware update.
So those are the right numbers to enter there to not change the hardware ID of the device while updating the firmware.
This also means that there are probably almost no one out there that enter the right numbers when they are asked to do soâŚ
Edit: I forgot to say that the last one was also the only time that Windows didnât remove my Renesas USB 3.0 drivers to replace them with the generic ones from Microsoft after rebooting. Which is another proof that those are the right numbers to enter.
According to thoses images. It is 0000 and 0000. (The SUBSYS ID with 8 zero in it)
If those are the numbers from your original firmware, then it is right numbers even if it looks weird to be just zeros.
If it is not from the original firmware, the only way to know the right numbers is to flash back the original firmware file (backup.mem) without using the cfg.ini file in the command. Then reboot.
If you donât have the original firmware as backup.mem, then those numbers are lost and you need to ask someone with the same system who never updated it what is his SUBSYS number.
OK, just to make it clear then. I have â00000000â listed as my SUBSYS, BUT I flashed this chip with the Intel 201_rear.zip without changing anything at all. The ini from that zip uses Intelâs VEN and SUBSYS of (From Intels cfg201v3.ini file)
1 2 3 4 Â
[SubSystemVendorID] 8086 [SubSystemID] 4953 Â
But yet my SUBSYS is clearly shown as 00000000, lol. Maybe I should try only four zeroes instead? so 1912 and 0000? perhaps?
OH, and I forgot to mention something. When I did a verify today of my backup.mem file, the system instantly took a dump, like something pulled from the USB ports, and the Renesas card showed an error in the device manager. However, it fixed itself the moment I did a "Update Drivers" and its still working just fine albeit with the generic Microsoft drivers. I updated the drivers again to 3.0.23.0 and its working perfectly. So the card is still OK.
That is my card, its from a company called SEDNA and it has a built in bridge layout for eSATA. However, I am 100% sure that eSATA thing is just a trace through and has absolutely NOTHING to do with the uPD720201 chip. However, that chip does have a two port hub thing on the back of the card so that you can route a cable to the front of a chasis. Is that the Root HUB? Or is the ROOT HUB part of the chip itself?
I am not an expert in that but i think the chip control the USB hub. The rest (the SATA part) just pass through to the PCI-e.
Edit: i just looked at my own system with Hardware identify and i saw a LOT of SUBSYS 00000000 from other devices that i never modified so it may be as simple as because your chip is on an external card and not on the motherboard itself, it doesnât have a SUBSYS number and never will. That would also explain why the flasher is not able to change it.
EDIT: However, it does look like my chip was probably flashed with a mem that was originally meant for a Intel board, since the numbers keep coming up under Intel based motherboards. WeirdâŚ
Good question. Before I try editing my backup.mem I think you should take a look at it first. It looks NOTHING like yours. Mine has lots of code, then lots of FFFFâs then lots of code again, then lots of FFFFâs again. LOL
Here is the link to BOTH the 2026 firmware and my backup. They are much different. https://mega.nz/#!nARB2TyC
If, when we can figure this out I might as well just flash 2026 since that is the last publicly known firmware for my 720201 device. It kinda feels like my firmware is corrupt because of the way it appears in hex editor, but since it works fine that seems to suggest that it is normal. I am just not hex editor savvy enough to trust myself doing anything in their, lol. But these cards are so cheap I really do not care if I break it either.
Anyway, tell me what you think. Should I fill the 2026.mem file with FF FFâs anyway? lol
EDIT: Oh and the HxD editor has a fill feature to fill in bytes (FFâs?). But it does not show file sizes. So I am not sure if I am supposed to just do the math and calculate the differences and then use that as the bytes fill amount. I will surely kill this card just stabbing at guesses. lol
This is the backup that you suggested I make. So I made it.
I had already flashed it like 10 times before making a backup, like I said I had been trying since mid last week to flash it with it always failing. And I donât ever remember it reporting just one firmware version, except for in that Russian software it reported 2018 and FFFFâs. However, Device Manager has always claimed it was 2020 ever since the very moment it was installed. And I also never checked firmware version through the flashers because I didnt know how until you showed me how. Like I said, the Intel flasher worked last week many times, but it would not work with anything but its very own 2020.mem.
Maybe we should look into THAT particular 2020.mem file now? Maybe the Intel flasher corrupted it? Link below to what I flashed last week. Download only the 201_Rear.zip file, that is for the rear Renesas uPD720201 ports on their early USB 3.0 enabled motherboards. That contains the only flasher that has been working for me. Let me know what you think.
Oh and if you figure out what needs to be edited, I can try and edit it myself. I just didnt understand how you would put so many FFâs into the mem file without knowing what its size is growing to, the hex editor does not show a progress bar on size. So do I add FFâs and then save and check file size, and then edit again, and then edit again, until the sizes match? Or is there some feature I am not locating in the editor that can show me size as I am editing the file? Thatâs the only reason why I did not edit it myself. lol
I just realized that I could be wrong on what version number was installed. It could have been 2018 by default. I just never seen 2018 in the device manager and now its been too much time to remember how events unfolded.
I do remember seeing 2020, and the russian software reporting 2018, which is one of the reasons that led me to win raid again. It âmightâ have been 2018, but the russian software ALWAYS reports 2018, even today I am sure it would report 2018. Lol
Actually your guess is as good as mine. I assume what you see is weirder than you thought it would be??? haha, thats funnyâŚ
EDIT: I just looked at the K2020090.mem from Intels site and it looks perfectly normal. Now I think that even though they say it would not flash if it was the wrong mem file, I think the W201FW21.exe file did in fact flash 2020 over top, or behind the 2018 firmware. Maybe this card came with 2018 and I just never seen it, although that feels unlikely to me. But it would explain the double firmwares. I bet the Intel board has a different srom chip with a much smaller size and thus the flasher just decided to put 2020 behind the 2018 firmware? Is that even possible?
I bet editing the 2026.mem file with lots of FFâs for extra space would work just fine though. Why wouldnt it?
This is what the Russian software reported below (upper left corner it says 2018, but device manager below it says 2020), itâs just a RUN.cmd that uses flasher W201FW20.exe and the mem files from Station Drivers (I assume). This software asks you question, and you answer them. It always ended with âHW Revision errorâ because, I assume, W201FW20 doesnât work with Revision 3 chips. https://www.computerbase.de/forum/showthâŚ21#post21008021 (as you can see my English is broken at this website, because their software doesnt fully understand me so it has ommited lots of my words, so thatâs why some sentences dont make any sense)
The K2020090.mem and K2026.mem as well as K2024 seems fine because they all have the same structure. What does not seems fine is the double firmware in your backup.mem. After seeing all those, i donât think anymore that editing a file would do. The only editing that can be done is, maybe, extract the 2018 firmware that seems to be still intact in your backup file. But that would not help to update your chip.
The only thing that can be done at this point to ensure a clean flash with only one firmware on the chip is this: Do the /erase command, that will put FF everywhere in your chip. Then flash the update you wish. This will ensure that only one version is on the chip.
