I've opened the case of my Sharkoon SATA QuickPort XT USB 3.0 dock and confirmed the Bridge IC:
There is also an "E" version of the IC which I believe supports AES hardware encryption.
https://upload.wikimedia.org/wikipedia/commons/6/6c/ASMedia_ASM1051E_ABA91140A2_T6A_1143.jpgSome of these bridge ICs have internal code which enables them to run as a generic bridge when the external memory (8-pin SPI flash?) is disabled. If yours is one of these, then perhaps the default sector size in generic mode is 512 bytes?
Edit:
WD's My Books use the same Asmedia bridge.
https://goughlui.com/2015/10/25/how-to-remove-wd-hard-drive-from-mybook-enclosure/P/N: WDBFJK0060HBK-04
Default WD My Book 1230 VID 0158 PID 1230 REV 1065
I cut the Vcc lead (pin #8) from the EEPROM, and the device detects as USB Mass Storage Device VID 04D9 PID 2013 REV 0103 and disables the goofy 4k sector translation mode as well, so regularly written 512e drives >2Tb actually read correctly.
Hope this is useful.
– Gough
You may need to cut the *HOLD pin as well, as sometimes the IC can still be powered up via this pin (if it is tied to Vcc) when Vcc is cut.
Just to clarify:
I don't use Linux, I use Win7 and Win10.
My type of USB bridge is ASM1051 not ASM1051
E.
How can I read out PID and VID of the device in Win10?I found the PID and VID in device manager:
And that's what I read out via flash tool:
Just to be sure the "new" firmware" and the found "nearly original" is the proper one.
Where can I find
Product string and
Manufacturer string in device manager?
Just in case you don't find any suitable disk tool for Windows, you can put any linux boot CD on a USB stick and boot from it.
https://linux-hardware.org/?id=usb:174c-55aaI would suggest that you identify the serial EEPROM/flash and short the DI or DO pins while powering up the enclosure. This will invalidate the external memory and cause the bridge to operate as a generic device until the next power cycle. If the result is what you want, then you could permanently disable the chip.
https://linux-hardware.org/?id=usb:174c-55aa
That's what I found in another (linux related) VID + PID data base:
174c ASMedia Technology Inc.
07d1 Transcend ESD400 Portable SSD (USB 3.0)
1151 ASM1151W
1153 ASM1153 SATA 3Gb/s bridge
2074 ASM1074 High-Speed hub
3074 ASM1074 SuperSpeed hub
-> 5106 ASM1051 SATA 3Gb/s bridge
5136 ASM1053 SATA 3Gb/s bridge
51d6 ASM1051W SATA 3Gb/s bridge
-> 55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
The read out PID via flash tool seems to be wrong (55AA indicates ASM1051E) but in reality it is a ASM1051 without E.
Does it matter if 55AA or 5106 is used? Should I correct it (5106 resp. ASM1051)?
I would suggest that you identify the serial EEPROM/flash and short the DI or DO pins while powering up the enclosure.
This will invalidate the external memory and cause the bridge to operate as a generic device until the next power cycle.
If the result is what you want, then you could permanently disable the chip.
It's a serial EEPROM 25LC512:
Can shorting SI or SO to GND kill the IC?
I think these ICs are protected against shorts to ground. I would try shorting SO to ground.
How did you find out that this will happen?
Probably there is much more config data stored in the EEPROM (time out behavior etc.)...
How did you find out that this will happen?
Probably there is much more config data stored in the EEPROM (time out behavior etc.)...
Most bridges are designed in this way. It's rare for a bridge to need an external "ROM" for basic functionality.
See
https://habr.com/ru/companies/ntc-vulkan/articles/485966/Findings:
During the boot process, the ASM1051 tries to load the code from the ROM [ie the external SPI flash].
The first thing ASM1051 does is compare the checksum-8 byte from address 0x04 to 0x7E with the value at address 0x7F.
If the calculation of the preamble check is successful, then it can be considered for the "code" (addresses from 0x0082 to 0x807F). The ASM1051 compares this sum with the value at address 0x8083 and checks that there is a byte 0x5A at address 0x8082.
If all checks are correct, then the ASM1051 is loaded from the ROM, otherwise it uses the mask firmware.
ASM1053 datasheet:
https://datasheetspdf.com/pdf-file/917641/ASMedia/ASM1053/1