ASMedia Aktuelle Externe Gehäuse Chip Firmware für 8TB ++

[onegasee59]

Usprungsproblem
https://www.computerbase.de/forum/t...irmware-fuer-8tb.1473501/page-7#post-22782898

Lösung gefunden
https://forum.acronis.com/comment/504747#comment-504747

 

[Vincent]

Usprungsproblem
https://www.computerbase.de/forum/t...irmware-fuer-8tb.1473501/page-7#post-22782898

Lösung gefunden
https://forum.acronis.com/comment/504747#comment-504747

Hab ich das richtig verstanden, der Fehler mit Win10 Ver 1903 bleibt für Asmedia ASM1153E bestehen? Die für dich zufriedenstellende "Lösung" ist sozusagen ein anderes Produkt?
Aber Acronis hat den Fehler nicht behoben, dass wenn man mehrere Festplatten durch mehrere ASM1153E Gehäuse (gleichzeitig) über USB anschließt, dass ab Win10 1903 das Acronis selbstständig während eines Backups die Laufwerksbuchstaben-Zuordnung innerhalb dieses Programms ändert, und der Backup-Vorgang fehlschlägt, richtig? Auch Neuinstallation von Win10 1903 hatte nichts gebracht.

Also ein Fehler des ASM1153E wäre ja auszuschließen, weil es bei einer früheren Win10 Version nicht auftritt.

Falls der Fehler bei Win10 1903 mit ASM1153E mit Acronis selbst mit den anderen USB-(Host)-Controllern weiterbestünde, würde ich schon bisschen mehr Druck auf Druck auf Acronis machen ^^

Ich benutze nur das Acronis-Bootmedium (auf Linux basierend), läuft prima immernoch auch mit zwei HDDs per 2 ASM1153E bridges adapters an USB gleichzeitig.

Mir kanns eh egal sein, aber nicht jeder, der Acronis unter Win10 hat soviel Geld/Zeit Lust immer was neues gleich zu kaufen.
Ich meine vom Prinzip her wegen Produkthaftung/veranwortung oder wie man das nennt.
Und weil halt vllt. noch ein Acronis-Mitarbeiter oder Moderator in die ursprüngliche Problembeschreibung ggf. noch eingearbeitet ist.
--
Falls der ursprüngliche Fehler in Acronis ja noch da wäre, vllt. löst sich das Problem eh von selbst , dann ab Win10 1909 bald im Herbst
-----

I'm looking for ASM1153E firmware with 4k emulation. Apparently, the original delivery of the Fantec DB-ALU3e-6G in 2015 had firmware which performed a 4k emulation on the ASM1153E. But I can not find this firmware.

I've bought eleven of Fantec DB-ALU3E-6G in the meantime, (from two different sellers (with ASM1153E: VID 174C, PID 55AA).
They all came with firmware "130926_A1_00_00.bin" (= standard firmware on later DB-Alu3e-6G production samples), but which is still not the newest, which does NOT support SSD-TRIM (so no TRIM support via ATA-Pass-through over SCSI), and also no SSD-TRIM (so no support for TRIM via SCSI-ATA-Translation (SCSI-Unmap=>ATA-TRIM conversion).
(UASP = SCSI-protocol over USB).
For ATA features like SSD-TRIM (=ATA) (via USB),he USB-bridge's firmware needs to support either one of them: full enough features of ATA-Passthrough via SCSI,
or full enough features of SCSI-ATA-Translation)

In any case if firmware 130926_A1_00_00.bin was the fw-update state your Fantec DB-ALU3e-6G was ALSO delivered with, which maybe supported 512Byte-to 4096 Byte emulation (or by config-setting by Fantec):

http://www.fantec.de/support-downlo...wnload&cHash=28db68ef8fd39317b8fcb43cee0c5232

=>
http://www.fantec.de/fileadmin/down...firmware/Fantec_DB-Alu3e-6G_Firmware_v1.1.zip

Fantec_DB-Alu3e-6G_Firmware_v1.1.zip (=130926_A1_00_00)
WICHTIG! - IMPORTANT!.txt

("WICHTIG!
Dieses Update wird nur für Geräte bis zur Seriennummer "11215xxxxxxxx" benötigt, neuere Geräte benötigen diese Firmware nicht!
IMPORTANT!
This update is only for devices up to serial number "11215xxxxxxxx" needed newer devices do not need this firmware!)

--Asmedia MPTool included with Fantec firmware, (this version is the same version as one of those Asmedia MPTool Version listed on usbdev.ru - (afaik => version 2.1.20.1)

-------
Firmware "140509_A1_82_40.bin" for Asmedia 1153E even supports SSD-TRIM (via SCSI->ATA-Translation (SCSI-Unmap => ATA-TRIM conversion)!
(All other versions tested, not.)

Asmedia ASMT-2115 Firmware (ASM1153, ASM1153E)
https://www.usbdev.ru/files/asmedia/asmt2115firmware/

Asmedia ASM1051 MP Tool v3.6.3.0 (ASM1051, ASM1053, ASM1351)
https://www.usbdev.ru/files/asmedia/asm105mptool/

Principially many different MPTool versions also work for ASM1153E. 2.1.20 which afaik Fantec uses also works flashing this firmware
However I had difficulties to restore all exact config-settings from original Fantec firmware "130926_A1_00_00.bin" !! (some firmware.config-settings were activated with an O symbol, some deactivated with X. However flashing back using original Fantec_DB-Alu3e-6G_Firmware_v1.1.zip didn't restore all original config-settings-afaik. All config-settings show an X now, afaik very few activated, but still an X
Afaik I remember correctlyx, with some firmware +MPTool-version combination, once it was possible to restore original X, O -settings from Fatec,
or maybe those own wehich I edited in "as_mp_Tool v0.5.ini". But mostly when tested flashing firmwares, always my special enabled in as_mp_Tool v0.5.ini settings were shown falsely "off" X in MPTool-firmware config-setting-information window about flashing attermpt. E.g I had disabled HDD-standby in in setting, but after flashing with such config, HDD still going standby (after few minutes) (even though HDD's own Adavanced Power Management: disabled in HDD-firmware)
Nethertheless USB Bridge working fine.

MPTool-password is needed to unlock all MPTool features,
like which firmware file to flash,
and edit/save/load fw-config-settings, like HDD-standby etc
from "as_mp_Tool v0.5.ini" for flashing firmware:

MPTool-password: asmedia:
---

I'm not sure if the old BIOS system (SO not using EFI) could boot from 4k native drives (4096 Bytes physical/4096 byte logical).

I know my old BIOS system computers can boot from 4096 Byte physical/512 Byte logical HDDs without issues anyways (below 2 TiByte). And (maybe) with Boot-partition in first 2 TiByte area on bigger drives.
2^32 * 512 Byte
= 2^32 * 2^9
=2^32 * 2^8 *2
=(2^40) *2
=2* (2^10)^4
=2* (1024)^4
2 TiByte

My BIOS-Computers can boot 4096Byte physcal/512 Byte logical) HDDs below 2 TiByte HDDs tested successfully.
(but still not tested with 4096Byte phycial/512 Bytes logical sector HDD bigger than 2 TiByte on BIOS_PC yet,

I know a 512Byte-native HDD (512bytes physical+logical) (>2TiByte HDD) cannot boot from BIOS (legacy) (UEFI needed), so for BIOS maybe a 512Byte to 4096 Byte emulation in USB-bridge helps, so that HDD appears eg. as 512Bytes physical/4096 Bytes logical.
If that helps,
(not sure if it works when emulation-result was 4096Bytes phycial/4096 Bytes logical (>2TiByte and <2TiByte)

If yes, then
= 2^32 * 4096Bytes
=2^32 * 512 *8 Bytes
< / =16 TiBytes max
---

Also Wheh having a 4k native HDD, (4096 byte physical+logical), if problems booting that on BIOS-PCs, a 4096 byte to 512 byte emulation, so the other way around (4096 Bytes physical / 512 bytes logical) also could be helping, but probably limited to 2TByte HDD /first 2 TiByte area.
Im quite sure, it won't work work when emulation-result was 512Bytes physical/512 Bytes logical (>2TiByte)

 

[onegasee59]

1.
Der Fehler trat auch schon beim betroffenen Rechner seit dessen Installations-Beginn mit WIN 10 1809 auf.
2.
Der Fehler "LW-Buchstabenänderung" bleibt unverändert auch mit Friscologic- und NEC-Controller als USB 3.0-Karte und unverändert nicht nur bei ASM1153E Gehäuse sondern auch mit anderen Gehäusecontrollern.
2.1.
Der Fehler "Gerät nicht migriert" ist mit Änderung von VL800- und ASM1153E-Controller auf Friscologic- und NEC-Controller als USB 3.0-Karte behoben.
3.
Wir haben unsere Problemlösung (Backup mit 2 Festplatten) per Docking-Station und das ist alles was zählt.
4.
Das bei unserem Rechner festgestellt Problem wurde zwischenzeitlich schon längst bei Acronis gemeldet - man hat unsere Thread im Acronis-Forum intern aufmerksam verfolgt. Und wir haben auf Bitten vom Acronis-Technik-Support auch alle möglichen Logins vom betroffenen System gesendet. Es hätte keinen Sinn gemacht Im Acronis-Forum und zusätzlich nochmal über Ticketsystem ohne voneinander zu wissen herumzuforschen.
Den Rest macht Acronis jetzt intern an Hand der gewonnenen Erkenntnisse.

Als Zusatzhinweis für alle Mitleser und Intressierten - in keinem Moment spielten Antivirus- oder Firewall-Software eines Drittanbieters eine Rolle. Von Anfang an wurde und wird ausschließlich die WIN 10-eigene Sicherheitssoftware Defender auf dem hier besprochenen System verwendet.

 

[Vincent]

Komisch hier hast du das Gegenteil behauptet, dass das Problem mit Acronis bei zwei ASM1153E Gehäusen gleichzeitig per USB mit früheren Windows-Versionen als 1903 noch nicht aufgetaucht wäre..
(Und andere Gehäuse (also solche mit 3,5 Zoll als Ersatz getestet) bei Win10 1903 nicht betroffen seien.)
--

https://www.computerbase.de/forum/t...-chip-firmware-fuer-8tb.1473501/post-22795092

{...}
Oder abwarten bis Microsoft das Problem gelöst hat. Schien ja vorher nicht aufzutauchen.

Tritt/trat das >Problem auch mit früheren Win10 Versionen auf oder erst seit Ver 1903?

https://www.computerbase.de/forum/t...-chip-firmware-fuer-8tb.1473501/post-22795368

Problem habe ich nur bei diesem einem System und nur bei WIN 10 1903. Ich habe noch 2 weitere Rechner die inzwischen auch WIN 10 1903 haben und ebenfalls mit jeweils 2. Backupplatten - in dem Falle allerdings 3,5-Zoll-Gehäuse bei denen keinerlei Probleme bezuüglich "Migration" ins System oder LW-Buchstabenverwechlung vorkommen bei gleichem Acronis 2017. Verwendete PCIe-Zusatzcard als 4 x USB 3.0-Controller und Mainboards sind identisch.

--

Der Fehler "LW-Buchstabenänderung" bleibt unverändert auch mit Friscologic- und NEC-Controller als USB 3.0-Karte und unverändert nicht nur bei ASM1153E Gehäuse sondern auch mit anderen Gehäusecontrollern.
2.1.
Der Fehler "Gerät nicht migriert" ist mit Änderung von VL800- und ASM1153E-Controller auf Friscologic- und NEC-Controller als USB 3.0-Karte behoben.

Klingt so, dass du die neuen USB-Host-Controller, die auch nicht halfen, zwischen von den verschiedenen Rechnern gegenseitig gegeneinander getauscht hast. Und jetzt scheint es irgendwie zu gehen.

Allerdings hast du ja letztendlich dann ein anderes Gehäuse benutzt mit noch älteren Asmedia Chip (ASM1053), weil Acronis wohl mit zwei ASM1153E weiterhin Stunk macht.
Also das eigentliche ursprüngliche Problem von Acronis unter Windows mit zwei ASM1153E simultan, ist momentan wohl noch nicht behoben, zumindest nicht mit Acronis 2017.
---
Immherin wie gesagt das Acronis TI-Bootmedium klappt auch mit mehreren ASM1153E gleichzeitig gut, also ist auf jeden Fall wohl kein Fehler im ASM1153E Bridge Chip.

 

[onegasee59]

Komisch hier hast du das Gegenteil behauptet, dass das Problem mit Acronis bei zwei ASM1153E Gehäusen gleichzeitig per USB mit früheren Windows-Versionen als 1903 noch nicht aufgetaucht wäre......

War ein Irrtum meinerseits - habe es korrigiert
https://www.computerbase.de/forum/t...irmware-fuer-8tb.1473501/page-7#post-22795368

 

[Haiku]

Hallo zusammen,

mein erster Beitrag hier:
Ich habe den ganzen Faden durchgelesen und gegoogelt wie blöd, konnte aber keine Lösung finden:

Ich habe 5 externe Festplatten in 5 Stück Fantec DB Alusky U3-6G Gehäusen, alle mit dem ASM1153E, FW 130926_A1_00_00.

Wenn nur eine Platte angeschlossen wird, läuft alles OK.
Windows Standby/Energie Sparen fährt die Platte herunter und startet sie auch wieder.
Auch hot swap ist problemlos möglich.

Sobald eine weitere Platte angeschlossen wird, funktioniert das Energiesparen nicht mehr.
Der Rechner startet nicht mehr aus dem Standby.
LED am PC leuchtet dauerhaft, Monitor bleibt schwarz, Platte aus, keine Reaktion.
Ich muß die Kiste dann mit dem Netzschalter abwürgen und neu booten.
Hot swap der ersten Platte geht auch nicht mehr, die Platte wird bei laufendem PC nicht erkannt, nur bei kompletten Neustart.
Die Platten selbst sind einwandfrei wie mehrere Checks ergaben.

Mit MPTools habe ich festgestellt, daß alle Gehäuse die gleiche Seriennummer haben.

USBdeview zeigt den Eintrag in der Registrierung des ersten Laufwerks mit einer Seriennummer, den weiterer Laufwerke ohne Seriennummer.
Die Instanzkennung des ersten Laufwerks enthält die Seriennummer des Gehäuses, die des zweiten Laufwerks nicht.
Nur die erste Platte erhält laut USBdeview eine eindeutige ID.

Diskpart zeigt zwar unterschiedliche Datenträger-IDs für beide Laufwerke.
Im Protokoll steht aber ein Eintrag "Der Datenträger "2" verfügt über dieselben Datenträger-IDs wie ein oder mehrere Datenträger, die mit dem System verbunden sind.
Rufen Sie die Microsoft-Supportwebsite (http://support.microsoft.com) auf, und suchen Sie nach KB2983588, um das Problem zu beheben."

Offenbar kann Windows die Platten wegen der gleichen Seriennummer der Gehäuse nicht korrekt auseinander halten.

Lösche ich alle Registrierungseinträge der Laufwerke, läuft die erste Platte mit Energiesparen des PC und hot swap wieder problemlos.
Sobald weitere Platten angeschlossen wurden, geht das Theater wieder von vorne los...

Dann habe ich mit MPTools versucht, nur die Seriennummer zu ändern und den unseligen 10 Minuten Standby Timer abzuschalten.
Die entsprechende ini "as_mp_Tool v0.4.-.1.hdd.standby.Aus.nur.änderung_SN" geladen.
MPTools meckert aber, der Flash startet nicht, ein Popup meldet "Error" und daß 4 Positionen zu checken sind, wobei die Einstellung von <more config> nicht zu finden ist.

Scheinbar muß immer auch die Firmware geflasht werden, nur um die Seriennummer und den Timer zu ändern.
Mit zusätzlichem Häckchen bei FW update geht die Änderung mit PASS durch.

Dann funktioniert aber Windows Standby/Energie Sparen wieder nicht mehr richtig!
Der PC geht zwar aus und wieder an.
Das externe Laufwerk läuft aber munter weiter und reagiert nicht mehr auf den Befehl, obwohl die LED am Gehäuse ausgegangen war.

Habe mittlerweile zig Stunden damit verbracht...

Bin ich der einzige, der mehrere externe Festplatten in gleichartigen Gehäusen benutzen will..?
Wieso kann Fantec/Asmedia nicht einfach schon jedem Controller eine andere Seriennummer geben, damit die Platten richtig identifiziert werden können..?

Kann die Seriennummer und der Timer geändert werden, ohne die FW neu zu flashen?
Wie kann Windows Standby/Energie Sparen beibehalten werden?

Bitte, bitte um Hilfe..!

 

[safeload]

Bestätigt, TRIM geht jetzt mit Firmware "140509_A1_82_40" (siehe Absätze+Beleg-Screenshots etw. weiter darunter)

Hallo Vincent,
ich würde gerne wegen fehlendem SSD Trim Support das Inateck FEU3NS-1E (ASM 1153e) flashen.

Firmware V. 140509_A1_82_40 https://www.usbdev.ru/files/asmedia/asmt2115firmware/
MP Tool v3.6.3.0 https://www.usbdev.ru/files/asmedia/asm105mptool/

hab ich, fühle mich jedoch mit den Einstellungen des MPTools Überfordert.

Müssen da individuell, über den Firmwarepfad hinaus, noch weitere Einstellungen angepasst werden?

edit: hab mir wohl zuviel Gedanken gemacht, hat default alles geklappt...

 

[Vincent]

Kann die Seriennummer und der Timer geändert werden, ohne die FW neu zu flashen?

Soweit ich weiß und probiert habe, ohne zu flashen, nein.

Wie kann Windows Standby/Energie Sparen beibehalten werden?

->Systemsteuerung ->Energieoptionen
Weitere ggf. mögliche Workaroundvorschläge auch weiter unten aufgelistet.

Erfahrungen zur USB-Bridge und wenig Spielraum (USB-Bridge-HDD Einstellungen werden nicht beachtet). Window-Ernergieoptionen für externe USB-HDD am ASM1153E greife nicht. wegen Standby-Einstellen siehe weiter unten.

Hallo zusammen,

mein erster Beitrag hier:
Ich habe den ganzen Faden durchgelesen und gegoogelt wie blöd, konnte aber keine Lösung finden:

Ich habe 5 externe Festplatten in 5 Stück Fantec DB Alusky U3-6G Gehäusen, alle mit dem ASM1153E, FW 130926_A1_00_00.

Wenn nur eine Platte angeschlossen wird, läuft alles OK.
Windows Standby/Energie Sparen fährt die Platte herunter und startet sie auch wieder.
Auch hot swap ist problemlos möglich.

Sobald eine weitere Platte angeschlossen wird, funktioniert das Energiesparen nicht mehr.
Der Rechner startet nicht mehr aus dem Standby.
LED am PC leuchtet dauerhaft, Monitor bleibt schwarz, Platte aus, keine Reaktion.
Ich muß die Kiste dann mit dem Netzschalter abwürgen und neu booten.
Hot swap der ersten Platte geht auch nicht mehr, die Platte wird bei laufendem PC nicht erkannt, nur bei kompletten Neustart.
Die Platten selbst sind einwandfrei wie mehrere Checks ergaben.

Mit MPTools habe ich festgestellt, daß alle Gehäuse die gleiche Seriennummer haben.

USBdeview zeigt den Eintrag in der Registrierung des ersten Laufwerks mit einer Seriennummer, den weiterer Laufwerke ohne Seriennummer.
Die Instanzkennung des ersten Laufwerks enthält die Seriennummer des Gehäuses, die des zweiten Laufwerks nicht.
Nur die erste Platte erhält laut USBdeview eine eindeutige ID.

{...}

Offenbar kann Windows die Platten wegen der gleichen Seriennummer der Gehäuse nicht korrekt auseinander halten.

Lösche ich alle Registrierungseinträge der Laufwerke, läuft die erste Platte mit Energiesparen des PC und hot swap wieder problemlos.
Sobald weitere Platten angeschlossen wurden, geht das Theater wieder von vorne los...

Dann habe ich mit MPTools versucht, nur die Seriennummer zu ändern und den unseligen 10 Minuten Standby Timer abzuschalten.
Die entsprechende ini "as_mp_Tool v0.4.-.1.hdd.standby.Aus.nur.änderung_SN" geladen.
MPTools meckert aber, der Flash startet nicht, ein Popup meldet "Error" und daß 4 Positionen zu checken sind, wobei die Einstellung von <more config> nicht zu finden ist.

Bitte, bitte um Hilfe..!

@Haiku
Öffne mal die "as_mp_Tool v0.4.ini" mit Editor/notepad. Relativ weit oben, glaub fast die letzte Zeile im ersten Passage/Absatz.
Setz mal bei Zeile Scan_HDDSN=0 den Wert auf 1!
=>Scan_HDDSN=1
Du musst aber die Firmware meines Wissens nochmal flashen, damit diese Konfiguration in der Firmware aktiv wird.

Alternativ kannst du das auch stattdessen direkt vor dem Flashen mit dem MPTool mit deiner Firmware auch im MPTool machen (Runde Checkbox im Asmedia-MPTool "Input From HDDSN") aktiveren, das entspricht der Zeile "Scan_HDDSN=1" in der "as_mp_Tool v0.4.ini".

Scan_HDDSN=1 (=Input From HDDSN): Schleift die SSD/HDD-Seriennumer durch, sodass sichtbar im Gerätemanager. Jede SSD und HDD hat ja eine eigene eindeutige Seriennumer.
Der Flash erfolgt OHNE HDD (NCIHT gedockt).
Wird nach einem erfolreichem FLash nur der Adapter angeschlossen, dann steht im MPTool-Statusfenster:
Serial Number 000000000000 angezeigt.
Wurd eine HDD gedockt, nachdem der Adapter neu erlannt wurde, wird im MPTool-Statusfenster: auch eine HDD-Sereinnumer angezeigt wie im Gerätemanager. Details etc. und die HDD-Kapazität.

Dann gibt's noch eine andere Einstellung, die auch helfen müsste. Du kannst jeder USB-ASMEDIA-Bridge deine eigene beliebige Seriennumer (hexadecimale Ziffern von 0 bis 9 und A bis max F) vergeben (z.B. 12-stellig wenn.SN_Numbers=12)
Es sollte nicht die gleiche sein für jede Bridge, grad wenn mherer Bridgs gleichzeitig, wie du ja bemerktest.

product_string=ASM1153E
serial_number=0123456789AB
serial_number_increase=1
SN_Numbers=12

oder serial_number=014590A7CBED

serial_number_increase=1
Wenn du einmal geflasht hattes, und die nächste Adapter-Bridge flasht, dann zählt das MPTool in den Zähler (hintere Stelle) automatisch um eins hoch, sodass für einen nächsten Flash die nächste Bridge eine näöchst-höhere Nummer bekommt.
Sodass nicht mehrere Bridges gleichzeitg, die selbe Nummer haben.

Mit Scan_HDDSN=1 (=Input From HDDSN) werden zumindest die Settings...
serial_number=XXXXXXXXXXXX
serial_number_increase=1
...meines Wissens außer Kraft gesetzt.
---
Noch etwas, wenn bei mir beide Zeilen folgende Zeilen gleichzeitig aktiv waren, gab es bei mir einen Failed Flash.
Check_USBStatus_enable=1
Check_USBStatus=1

Achte noch darauf, dass er nach einem Flash-Versuch die Bridge NICHT neu ins MPTool reinlädt.
rescan_after_relink=0

Meine Fantec hatte ich mal "ganz" gebrickt nach Flashen einer falschen Firmware,
und danach in Panik die USB-Bridge hinterher am USB wieder aus- und wieder eingesteckt hatte.
hier half bei mir nur ein externer Programmer.

Nach einem Failed Flash attempt AUF GAR KEINEN FALL die USB-Bridge AUS-und Ein-nstecklen, also USB-und Powerkabel dran lassen, und NICHT ausschalten und MPTool GEöffnent halten. Dann nochmal neu flashen.
SIehe oben, wenn falsche Settings benutzt wurden in der as_mp_Tool v0.4.ini

Im Zweifelsfall, wenn du nicht genau weißt, ob noch ein Setting anderer Zeile in der .ini noch stört, kopiere die Original as_mp_Tool v0.4.ini zurück, und lade sie ins MPTool-Fenster mit misglücktem Flash neu rein, und reflashe das ganze.


immer mit einer U(M)benannten Kopie der original ini des MPTools arbeiten, also NICHT von ANDERER MPTool-Verison vermischen.

--

Dann funktioniert aber Windows Standby/Energie Sparen wieder nicht mehr richtig!
Der PC geht zwar aus und wieder an.
Das externe Laufwerk läuft aber munter weiter und reagiert nicht mehr auf den Befehl, obwohl die LED am Gehäuse ausgegangen war.

Habe mittlerweile zig Stunden damit verbracht...

Ja damit hab ich auch rumgekämpft. Bei mir geht die HDD immer in Standby nach ca. 5-10 bzw. 20 Minuten Inaktivät. Obwohl HDD_standby auf 0 gesetzt hatte oder auf 1 und den Standby_Timer auf 5h gestzt hatte, trotzdem schaltet der Adapter in den Energiesparmodus.
Für den Flash verschiedene MP-Tool-Versionen zu benutzen, brachte leider nichts.
Bei der Fantec DV-ALU3E 130926 Firmware bleibt die HDD immer an.
Wenn ich eine andere Firmware flashe, z.b. die" 140509_A1_82_40.bin ", dann geht die HDD,immer wie gesagt nach ca 5-20 min in den Standby (HDDs internes Adavanced Power Management HDD deaktvieirt, also macht die Bridge das). Trotz wegen HDD-Standby-Geschichte, nehme ich lieber benötigte Firmware "140509_A1_82_40.bin" für SSD-TRIM.
Einstellungen in der ini, dass ich andere Timer will bzw. immer an bleibt), bewirken nichts) Auch verschiedene Timer-bezogene Einstellungszeilen probiert.

Wenn ich die neuste Asmedia 130926_A1_00 Firmware von Fantec zurückflashe, dann bleibt die HDD immer an auch in der USB-Bridge, wenn ich HDD_standby auf 0 setze
(ist bei Fantec Firmware Update fpr DB-ALU3e-6G glaub aber auch dafaultmäßig in der .ini disabled)

Sobald eine weitere Platte angeschlossen wird, funktioniert das Energiesparen nicht mehr.
Der Rechner startet nicht mehr aus dem Standby.
LED am PC leuchtet dauerhaft, Monitor bleibt schwarz, Platte aus, keine Reaktion.
Ich muß die Kiste dann mit dem Netzschalter abwürgen und neu booten.
Hot swap der ersten Platte geht auch nicht mehr, die Platte wird bei laufendem PC nicht erkannt, nur bei kompletten Neustart.
Die Platten selbst sind einwandfrei wie mehrere Checks ergaben.

GGf. hilft die BIOS/UEFI-Firmware zu updaten, falls verfügbar.

Ich würde S3 Schlafmodus deaktivieren in der Firmware (falls vorhanden), macht/machte bei mir immer nur Ärger, also nur S1 benutzen. Einmal ist mir en Athlon XP-2400 CPU kaputt gangen während dieses Standby-Modus, und einmal dabei auch ein P5Q3 Sockel 775 Mainboard.

Ggf. werden dabei auch diese CPU C4 C5 Power States deaktiviert. Ggf. kann man auch Intel C-State deaktivieren, das macht manchmal sonst auch Ärger, bzw. CPU Enhanced Idle Power State.

Einstellung prüfen, dass USB-Geräte PC aus dem Standby aufwecken können, mittels powercfg (in cmd als Admin)
https://www.windows-7-forum.net/thr...aesst-sich-nicht-abstellen.17272/#post-147906
(geht ntrl. auch für um,gekehrten Fall zum Aufwecken.

Prüfen, dass die +5Vsb für die USB-Ports ((jumper) so gesteckt sind).

Wenn es ja vorher immer ging, ggf. hängt sich das gesamte USB auf, wenn es diesen ID-Konflikt gibt, während Standby z.B.
ALs ggf. Workaorund in Systemsteuerung (Control Panel) bei den Energieoptionen, "Auswählen was beim Drücken des Netzschalters geschehen soll" auf "Energie Sparen" setzen. GGf. geht das auch zum Aufwecken.
(Mit Netzschalter drücken ist ntrl. der Einschaltknopf am PC-Gehäuse gemeint, ntrl. NICHT der des Netzteils")

Ich weiß nicht ob das bei dir der exakte Fall war:
Wenn die Platte z.B. extern per USB als Win-System betrieben wurde, also z.V. von SATA auf USB umgestöpselt wurde und es kommt eine weitere extern hinzu mit selber USB-Bridge-Seriennumer wo die HDD-Serinnimer nicht durchgeschleift wird, kann das WIndows ggf.s ausmTritt bringen
(da gibt's ja so nen Trick, wenn die UEFI/BIOS-Firmware UASP-Boot-Option-ROM-Treiber besitzt, was Windows-To-go per USB ermöglicht, wenn auf der externen HDD schon WIn 8.1/10 drauf war)


Oder AMD Wattman macht Ärger (AMD-Treiberprobleme). Hatte da so Probleme mit meiner R9 280, dass wenn die in Bildschirmschoner geht, und in den Energiesparmodus, dass dann kein Bild ,ehr kam, und der PC immer kaltgestartet werden muss.
--
Viel mehr fällt mir im Moment auch nicht ein, wie man das lösen könnte.
Für z.B. ein Sockel 775 Board mti einem Fresco Logic USB 3.0 xHCI Host-Controller aufm Board, gibt's z.B. bei station-drivers.com Updates. Der ältere Fresco-USB-Host-Treiber machte beim Probleme beim Schreiben auf's USB-Gerät am Host-controller, Lesen jedoch nicht (Windows 8.1). Nach dem Treiber-Update ist das Problem verschwunden. Unter Win10 (neuerer Win-USB-Fresco-Logic-Standardtreiber?) auch standardmäßig keine Probleme mehr.
Für Win10, ggf. werden die von Microsoft mitgelieferten USB-Treiber benutzt, und die sind ggf. älter. Ggf. gibt es bei station-drivers.com einen neueren vom Hersteller für den USB 3.0-Host-Chip.

Wie gesagt unter Linux mit Standard-Debian-Kernel 4.19.05, (inzwischen Kernel 5.3), keine Probleme mit mehren ASM1153E-Adaptern gleichzeitig, und mit Acronis TrueImage 2018-Bootmedium (=Linux-Basis) auch nicht. Unter WIndows noch nicht mit mehren gleichzeitig getestet, hole ich bei Bedarf nach. Scan_HDDSN=1 ist bei mir in der Firmware aktiviert, wodurch vrmtl. ntrl. auch unter Windows keine Probleme auftreten sollten.

Über USB bei manchen SSDs bzw. manchen HDDs Probleme Probleme, dass die Programme eine falsche IO-Block-Alignment_Größe erkennen; was lästig ist wenn man umpartitioniert, also wenn man nicht neu partitioniert.
Bei anderen HDDs-Modellen z.B. das Phänomen wiederum nicht beobachtet über USB am ASM1153E.

 

[ilhami96]

Hallo lieber Helfender,

ich habe seit 4 Jahren eine Cnmemory 75615 als Gehäuse für meine Festplatten (3TB, 4TB, 8TB) benutzt.

Nun ist dessen Ein/Aus-Schalter kaputt gegangen. Das Gehäuse ist Defekt.


Daraufhin habe ich mir (aus Verzweiflung, weil keine funktionierte) mehrere Brandneue Festplattengehäuse aus Amazon geholt. Ich habe leider ein Vermögen ausgegeben.

Bei jedem Neuen Gehäuse, das ich probiert habe, kommt das selbe Problem:

-Mein Mac erkennt nur das Gehäuse (also den Chip vom Gehäuse), ABER nicht die Festplatte.

-Das Betriebssystem verlangt, dass ich die Festplatte entweder Formatieren, oder Initialialisieren soll.

-Bei einem Klick auf „Initialisieren“ passiert nichts. Formatieren möchte ich es auf keinen Fall, wegen der wichtigen Daten. Ich habe die Dateien zwar geBackuppt (,weil doch immer überall dazu geraten wird), aber auch diese Festplatten erkennt sie nicht. Es ist ein Horror.

-Nach einem Blick auf die Rezensionen auf Amazon, bin ich auf Kritiken gestoßen, dass man achtsam sein müsse, weil das Gehäuse (CnMemory 75615) mit einer 4K Emulation (Chip von ASMedia 1051) arbeite. Der Mahnende warnt genau davor, was mir leider geschehen ist.

Die Festplatten sind 100% in Ordnung. Soweit ich das verstanden habe, habe ich wohl eine „4K Emulation“ mitgeschleppt, als ich das Gehäuse gewechselt habe.

Das alte Gehäuse kann man absolut nirgendwo mehr kaufen. Weder Neu, noch Gebraucht.

Ich komme weder an meine Original Daten, noch an meine Backups ran.

Ich bitte euch um Rat. Sagt mir was ich machen soll. Welches Gerät soll ich kaufen ?

Welches Gehäuse, das immernoch verkauft wird, arbeitet mit einer 4K Emulation und hat einen Chip von ASMedia 1051 ?

Besten Dank


EDIT: @Vincent hilft mir bei meinem Problem weiter. Danke an alle

 

[Vincent]

Hallo lieber Helfender,

Welches Gehäuse, das immernoch verkauft wird, arbeitet mit einer 4K Emulation und hat einen Chip von ASMedia 1051 ?

Besten Dank

Hatte mal eine WD My Book 8TB HDDs (3,5 Zoll - USB extern) gekauft. (Intern ist es WD80EZAZ SATA, mit einer SATA-USB-Adapterplatine, mit Asmedia ASM1(1)51(W), allerdings NICHT mit ASM1(0)51.

Hiervon hatte ich die Firmware mit meinem externen Programmer gesichert, siehe im Anhang.

Asmedia ASM1(1)51W, allerdings NICHT ASM1(0)51 ! :
WD_My_Book_Winbond_W25X20CL_EEPROM_ASM1151W_Backup_TL866A_gut_ausgelesen.zip
https://www.computerbase.de/forum/a...151w_backup_tl866a_gut_ausgelesen-zip.835525/

Die wird sicherlich nicht passen, weil anderer USB-Bridge-Chip,
und noch ggf. andere EEPROM-Größe, und außerdem sollte man das nur bei einem (LEEREN) Gehäuse machen, was man bereit wäre ggf. kaputtzuflashen(!)

BITTE BEI Flash-Vorgängen der Firmware,bitte die HDD AUSdocken, (Bitte HDD dabei NICHT im Gehäuse gedockt haben!) UND BITTE noch ein weiteres passendes Ersatz-Gehäuse haben, falls es von einer anderen HDD, mit auch wichtigen Daten, benutzt wird, und dessen Emulation benötigt.


Diese Firmware BRINGT FÜR DICH EH NIX, denn die Firmware emuliert auch nur 512 Byte logisch.
---
Deine 3TB, 4TB,8TB HDDs haben zwar selber schon 4096 Byte physikalisch und vrmtl. 512 Byte logisch (z.B. für extra ältere PC/Laptop-Hardware-rückwärtskompatibilität),
das alte Gehäuse machte aber ggf., dass die HDD ggf. 4096 physikalisch + 4096Byte logisch melden (statt 512 Byte logisch) und bringt jetzt mit 512 Byte Emulation, natürlich die Software durcheinander.

{...}
Das alte Gehäuse kann man absolut nirgendwo mehr kaufen. Weder Neu, noch Gebraucht.
{...]
Nun ist dessen Ein/Aus-Schalter kaputt gegangen. Das Gehäuse ist Defekt.
{...}

Die Festplatten sind 100% in Ordnung. Soweit ich das verstanden habe, habe ich wohl eine „4K Emulation“ mitgeschleppt, als ich das Gehäuse gewechselt habe.

Ich komme weder an meine Original Daten, noch an meine Backups ran.

Daraufhin habe ich mir (aus Verzweiflung, weil keine funktionierte) mehrere Brandneue Festplattengehäuse aus Amazon geholt. Ich habe leider ein Vermögen ausgegeben.

Bei jedem Neuen Gehäuse, das ich probiert habe, kommt das selbe Problem:

Ich bitte euch um Rat. Sagt mir was ich machen soll. Welches Gerät soll ich kaufen ?

Vielleicht hast du zufällig unter den mehreren Gehäusen, die du gekauft hast, ein Gehäuse mit Norelys-Chipsatz gekauft, ansonsten hätte ich Orico 6518US3 Adapterplatinen, die ich vom Orico 6518US3 ausgebaut habe, und durch Fantec-PCB erstzt hatte, und nicht mehr zwingend bräuchte, eine könnte ich dir schenken und ggf. an eine DHL-Packstationsadresse schicken, damit es möglichst anonym bleibt (ggf. in PM besprechen) (das Gehäuse selber kostet/gabs mal bei ebay für 16€ aus China). Müsste es auch bei amazon geben.

Dort ist ein Norelys NS106X Chip verbaut, und das Norelys-MPTool bietet auch eine 512Byte oder eine 4096-(4K) Byte-Emulationseinstellung (Logisch-Emulation) zum Flashen der Firmware an.

Ich bevorzuge ein anderes Produkt mit z.B. ASM1153E statt der Orico nur wegen SSD-TRIM-Fähigkeit über USB, und für optische Laufwerke (mit USB-BOTP-Fimware), weil es auf der Orico mit NS106X Chipsatz bei SATA-ODDs bei der BD-Wiedergabe regelkmäßißgen Ruckel-Aussetzer gibt (nur bei der Widerhabe von Videos), bei der Fantec mit ASM1153E aber nicht..
Ansonsten funktioniert die Orico 6518USR tadellos, und reicht auch für deine Datenrettung völlig aus.
---
Du musst NICHT genau das gleiche Gehäuse nehmen, es muss nich der gleiche Chip sein, es kann auch ein anderer sein sein, es reicht wenn man auf 512 Byte oder 4096 Byte Blockemulation in der Gehäuse-Firmware umstellen kann. Die Orico 6518US3 z.B. kann laut Norelys-MP-Tool zwischen 512 Byte und 4096 Byte Emulation umgeschalten werden!
--
Ein Norelys-MPTool-Passwort ist nicht vorhanden, zum Freischalten aller Optionen (damit 4K- und 512 Byte Emueinstellugne) sichtbar: im Passwortfenster bei Password- nur Return auf OK drücken, (Ohne Password).

Die Firmware muss meines Wissens auch bei Norelys-Chips nochmals geflasht werden, sollte eine FW-Einstellung geändert werden.

BITTE BEI Flash-Vorgängen der Firmware,bitte die HDD AUSdocken, (Bitte HDD dabei NICHT im Gehäuse gedockt haben!)
--
Ich hab noch Orico-Platinen rumliegen, kann gerne eins verschenken oder ausleihen und vorher eine 4k- oder 512Byte-Emulationsfirmware flashen.


----
https://superuser.com/questions/463952/is-it-possible-to-set-the-logical-sector-size-of-a-usb-hdd
Hier gibt's ggf. noch interessante Hinweise genauer darüber, warum die Daten einer HDD
bei zwei Gehäusen mit verschiedener Emulationsgröße nicht gleichzeitig gelesen werden können.

Es gibt noch eine Methode, dort im Link beschrrieben von kubanczyk:
edited Mar 17 '17 at 11:46

Wennn die (eigentlich zu meldende original-) logische HDD-Blockgröße durch die HDD selber, durch das neue Gehäuse nicht manipuliert wird, (vom alten Gehäuse aber schon, daraus resultierend jetzt dann andere logische Block-emulation imVergleich zu anderen Gehäuse), meldet die HDD also 512Byte Block logisch (was die meisten HDDs ja tun): 4096Byte physikalisch und 512 Byte logisch.
Der Trick besteht darin: die Original-Start-Block-Nummer der Partition/en und die letzte Blocknummer der Partiton/en zu notieren (siehe Partitinierungstools in Linux), diese Werte mit mal-Acht multiplizieren, und die Partitionstabelle auf genau diese achtfachen-Werte für die Partition/en (Start und Ende der Partiton/en) umzuändern (Vorraussetzung, die Partitionstabelle+Daten wurden bei 4K Emulation logisch erstellt) und die HDD wird am neuen Gehäuse (und/oder direkt am SATA-Port) als 512-Byte-Block-logisch erkannt.

Wenn die HDD selber 512Byte jetzt logisch hat und das Gehäuse dabei nichts emuliert, und/oder wenn es 512 Byte nochmals drüberemuliert, meldet die HDD letztendlich ja immernoch 512 Byte logisch), dann kannst du diesen Trick probieren.
WICHTIG BACKUP vorher!
Das hilft dir aber NICHT im Moment, weil die PLatte als scheinbar leer angezeigt wird, und das original alte Partitionslayout nicht sehen kannst. Außer du hattest im alten Gehäuse als es noch ging, ein direkt auswertbares 1:1 Raw Image gezogen, wo du dann direkt du mit Partitonstool die Partitions-Offsets in dem 1:1 Image angucken könntest, ohne weitere Schritte (siehe ganz unten).

Ein Haken gibt's noch bei GPT, dass hinten am Schluss die letzuten 32 Blöcke für's Layout reserviert sind. Wenn von 4096 Byte auf 512 Byte logisch umgestellt wird, geht nur der Partitionsstill bei über 2 TiByte.

Das ist alles zu kompliziert für dich würde ich sagen, auch ich habe darin keine Übung.
Ich bin etwas verwirrt, eigentlich sollte das auch NICHT gehen, denn die Datei- und Verzeichniszordnungen innerhalb Dateisysteme sind ja bei dir (ggf.) auf 4096Byte logische Sektoren ausgerichtet, d.h. stimmen bei einer anderen Emulationsgröße nicht mehr mit diesen Zuweisungen der Dateisysteme überein, d.h. alleine nur die Partitionstabelle auf auf 8fache Offsets (SEHR RISKANT!) anzupassen, bringt höchstwahrscheinlich nichts, etc.

Einfacher wäre es, nimm ein Orico 6518US3 Gehäuse, kann dir auch eins zuschicken, und dann eine 4K Emulationsfirmware noch draufflashen (Firmware und Norelys Mptool habe ich). Dann muss du auch nicht die Partitonstabelle nicht auf diese 8fache Umstellen und nicht auf ändernGPT, falls vorher MBR benutzt wurde (denn eine 4K logisch-Emulation ermöglicht ja anscheinend 2^32*4096 Byte große MBR-Partitonsgrößen=also max 16 TiByte Große mit MBR bei 4096 Byte logischer Blockgröße!)

Die einfachere/bzw. einzig zielführende Methode wäre dann eher, die Original-Emulation des altzen Gehäuses im anderen Gehäuses (z.B. Orico 6518US3/6518SUS3) zu übernehmen , und du die Daten dann mit großer Sicherheit lesen können müsstest!
Oder wie der Vorposter vorschlägt, am Original-4k-Emulations-Gehäuse den kaputten Einschalter überbrücken.

Wenn du ein Backup machen willst, ist es wichtig die Daten roh zu kopieren (z.B. mit dd unter Knoppix-Live-Linux-System) in eine Image-Datei, welche du auf irgendeiner (Zwischen)-Ziel-HDD (egal welche Emulation) zwischenspeicherst.
Ich bin mir nicht total zu 100% sicher, wenn du das Backup-Image-Datei (der gesamten Quell-HDD) (nur als Kopie) auf einer 512 Byte logischen-Emulation HDD (als Datei dort im Dateisystem) zwischenspeicherst, sollte das auch gehen, "dd" wird dann eine (scheinbare) (gemeldete) 8-fache-Blockzahl kopieren, wenn das erstmal nicht direkt auswertbare Quelllaufwerk, jetzt aus einem anderen Gehäuse aus ausgelesen wird, das 512 Byte emuliert. das ist aber in dem Fall erstmal egal ("dd" wird dann eine (scheinbare) 8-fache Blockanzahl, (aber in 1/8 der Segment-Größe im Vergleich zu Original-Emulation) kopieren =Backup =was aber exakt gleiche größe/Datenmenge wie Original ergibt)

Das kannst aber nicht unmittelbar auf die Daten im Backup zugreifen. Um darauf zugreifen zu können muss du das Backup-HDD-Image auf eine (Ersatz)-4096Byte logische-emulierte (LEERE !) HDD (OHNE zu rettede Daten! )mit "dd" roh noch rüberkopieren (überschreiben). Die Ziel-HDD muss exakt gleich groß sein, kann auch größer sein, aber sollte Nicht kleiner sein (und muss auch 4096 Byte logisch emulieren), du braucht aber immernoch ein Gehäuse mit 4096 Byte logisch Emulation) für das End-Ziellaufwerk, wenn du die Backupdaten z.B. lesen Können willst.

Sollte die Quell HDD GPT-Partitonierung gehabt haben, und du das Backup auf eine größere 4096-HDD kopierst (um die Daten lesen zu könen), der Backup-GPT-Partitonstabellen-Header am Schluss der Daten (=32 Blöcke) steht dann natürlich NICHT ganz am Ende der größeren End-Ziel-HDD, (sondern ntrl. weiter vorne, am Ende der gleichen Datenmenge).

Das heißt du kannst im Prinzip auch gleich das Orico 6518US3 Gehäuse mit 4096 Byte Logisch-Emulation nehmen, und gleich direkt die wichtigen Dateien (auf Dateisystemebene =beide Laufwerke Dateisystem gemountet/eingehängt und so von einem Laufwerk aufs andere die Dateien/Verzeichnsse rüberkopieren)

 

[mkossmann]

Nun ist dessen Ein/Aus-Schalter kaputt gegangen. Das Gehäuse ist Defekt

Keine Chance , das Gehäuse noch mal zum laufen zu bekommen, indem der Schalter gebrückt wird ?
Dann kannst du den Inhalt der Platte auf eine andere Platte sichern und diese Platte in einem neuen Gehäuse frisch formatiert wiederverwenden

 

[Vincent]

[Edit]
zu viel Text von mir. (Von Vincent gelöscht)

Es gibt eine andere Möglichkeit OHNE Gehäuse mit 4K-Emulation, die Daten richtig auswertbar/deutbar zu bekommen, sodass der Inhalt richtig angezeigt wird,
und die Daten zu retten (siehe noch weiter unten)

--
Zum vorigen Gedanken,
wegen Datenrettung von einer HDD mit ursprünglich z.B. 512 Byte logischer Sektorgröße,
die in einem alten USB-Gehäuse jedoch als 4096 Byte logische Sektor/Block-Größe (4K-Emulation) benutzt wurde,
und jetzt dieses USB-Gehäuse kaputt gegangen wäre,
und man die HDD direkt an SATA oder Ersatz-USB-Gehäuse anschließt, und jetzt die HDD wieder 512Byte logisch meldet,
aber die bisherige Daten- und Partitionierungsstruktur auf 4096-Byte logisch gemeldete Sektorgröße ausgerichtet ist,
und man an SATA, und anderen Ersatz-USB-Gehäuse man die Daten scheinbar NICHT richtig interpretiert bekommen könnte. (Lösung siehe noch weiter unten)...

...da hatte ich gesehen, dass es im Norelys MP-Tool eine Option gäbe für 4096 Byte logische Emulation, und man diese Einstellung in einer Norelys-Firmware editieren und flashen kann.
Das hatte ich am Orico 6518US3 SATA-USB-Dock (Norelys NS106X) Chip mit Firmware 3.8.0.9 nun probiert.

Leider nachdem ich die Firmware mit dieser gesetzten 4K-EInstellung auf der Orico geflasht habe,
und nun eine HDD dockte mit 512 Byte pysikalisch / (´´512 Byte logisch),
trotzdem wird bei der HDD immernoch 512 Byte physisch/logisch angezeigt.
Eigentlich sollte jetzt bei der HDD im Dock 512Byte physisch und/ 4096Byte logisch anzeigen bzw. 4096Byte physisch+logisch.

Das ist leider NICHT der Fall. D.h. klappte der Gedanke mit dem Orico-Gehäuse und der 4K-Einstellung im Norelys-MP-Tool tatsächlich NICHT.
Es gibt noch frühere Norelys-NS106X Versionen, ältere Norelys NS 106X 2.67 Version oder so (auch mit UAS) und noch zwei ältere 2.32 und 2.16 Versionen oder so (OHNE UASP ->USB-Bulk-Only-Transfer-Protocol), die am Orico-Gehäuse funktionieren.

Villeicht klappt da die 4K-MP_Tool-Option im MP-Tool in diesen Firmwares eingestellt zu bekommen, sodass es bei gedockter HDD sich tatsächlich auswirke...

---
Wie dem auch sei eine gute Nachricht hätte ich trotzdem:
Es gibt auf jeden Fall eine Möglichkeit, wie man an seine Daten rankommt, selbst wenn die Partitionierung und Dateisysteme auf 4096Byte logische Sektorgröße ausgerichtet sind, AUCH OHNE 4K-Emulations-Ersatzgehäuse,
selbst wenn man (K)ein's hat, das auch die 4096Byte logische Emulation zur Datenrettung wiederherstellt.

Dazu benötigt man ein Knoppix-Live-Linux-System, (oder eine installierte Linux/Distribution: Debian GNU/Linux /Ubuntu etc)
http://ftp.tu-chemnitz.de/pub/linux/knoppix/knoppix-dvd/KNOPPIX_V8.6.1-2019-10-14-DE.iso
Das ISO auf DVD-R /-RW /+R / +RW
/ oder auf DVD-RAM brennen (wenn von Brenner unterstützt)
mit Programm "ImgBurn" kostenlos ->Burn Image to Disc ("Imagedatei auf Disc schreiben")
https://imgburn.com

Nicht schneller als 4x Brenn-Geschwindigkeit empfohlen, grundsätzlich wegen Schreibqualität (Dauer 15 Minuten für 4,7 GB)
-
Schnell-Bootmenü Taste F7/F8/F11 bzw. F12 dürcken beim Firmware-Initialiserungsvorgang bei Anschalten des PCs.
Bzw. Bootreihenfolge von DVD als erstes zu booten:

Fall UEFI-Modus benutzt wird, und "Secure Boot" an ist, bitte abschalten.
Ansonsten wer's komplizierter haben wollte, Secure-Boot anzulassen, muss man so einen Schlüssel von Knoppix in eine Secure-Boot-White-List eintragen lassen per EFI-Shell oder so, siehe Anleitung in den Release Notes bei "knopper.net"

(Alternativ den "BIOS/CSM/legacy/UEFI-Boot-Disabled" -Modus benutzen.)

Knoppix von DVD booten.
Funktioniert im UEFI-Modus und BIOS/CSM/Legacy-(UEFI-Boot-(Dis)abled-Modus)

Wenn Knoppix gestartet, auf dem Desktop gibt's ne Option auf einem Leeren USB-Stick einen bootbaren Knoppix-USB-Stick erstellen zu lassen, was dann viel schneller bootet,
statt 2-4 Minuten geschätzt 30-60 Sekunden, selbst an USB 2.0.

Ansonsten kann glaub auch "RUFUS" aus der "KNOPPIX_V8.6.1-2019-10-14-DE.iso"
einem entspchenden bootbaren Knoppix-Live-Linux-System-USB-Stick erstellen. (USB-Stick muss leer sein - alle alten Daten darauf werden dabei gelöscht!)
https://rufus.ie/de_DE.html
--

Was die betreffende Festplatte ist (sda bzw. sdb oder sdc, oder ... usw.) , wo man retten will, findet man raus in Knoppix mit:

In Konsole (Kommandozeile) eingeben als root:
um root/superuser zu werden (in Knoppix ist Admin-Nutzer "Root" OHNE Passwort):

su -

-
Bringt Liste Liste der angeschlossenen Geräte (OHNE Namen) anhand von Gesamtgröße und Größen der darin enhaltenen Partitionen und Device-Node-Zuordnung):
(ausgegebene Größen in KibiBytes also, 1024 Bytes): Umrechnug in Bytes: ausgegebenen Wert *1024 multiplizieren

cat   /proc/partitions

--
Bringt Liste Liste der angeschlossenen Geräte (Modell-Namen und Schnittstellentyp) und Anzahl Partitionen, und deren device-Node-Zuordnung (ABER keine Größen):

ls  -la   /dev/disk/by-id

---
Bringt Liste der angeschlossenen Geräte (OHNE Namen) anhand Anzeige von enthaltenen Partitionen und Device-Node-Zuordnung, und die darauf enthaltenen Dateisysteme:

blkid

Es gibt ja das Programm "losetup" (was bei Knoppix mitkommt),
um loop-devices zu erstellen aus anderen Geräten
oder aus einer Image-Datei einer gesamten Festplatte/SSD oder einer Partition
oder um ISO-Dateien zu mounten (mount -o loop,ro Win10.iso /mountpoint)

Bei dem Programm "losetup" kann man auch von Geräte/n und Partitionen, und Image-Dateien auf ein quasi virtuelles Gerät mappen,
( /dev/loop0 ; /dev/loop0p1 ; /dev/loop0p2; /dev/loop0p3 /dev/loop0p4; etc)
( /dev/loop1 ; /dev/loop1p1 ; /dev/loop1p2; /dev/loop1p3 etc)
( /dev/loop2 ; /dev/loop2p1 ; /dev/loop2p2; /dev/loop2p3 etc)
" "

Bei dem Mapping von der SSD/HDD auf das virtuelle Gerät, kann man vom eigentlichen Ursprungsgerät,
die Blockgröße von z.B. 512 Byte auf 4096 Byte Blockgröße ummapen.


Siehe Screenshot unten mit disk Partitonierungsprogramm, was jetzt auch 4096 Byte logische Sektorengröße meldet, auf das gemappte virtuelle Ziel-Gerät:
Siehe Screenshot - Vergleich vorher: zwischen "fdisk -l /dev/sda" und "fdisk -l /dev/loop0"

---
Hinweis: Im Screenshot von mir habe ich eine SSD (hier /dev/sda) ...
(Partitionierungsart=MBR;
6 Partitionen (drei Primäre Partitionen -
die vierte Primäre Partition ist eine Erweiterte Partition - zwei logischen Partitionen darin enthalten)
...mit 512 Byte logischer Blockgröße (/dev/sda) auf 4096 Byte logische Blockgröße (/dev/loop0 ) umgemappt.
Da die Partionierunsstruktur/Partitionstabelle und Dateisysteme auf 512Byte logische Sektorengröße ausgerichtet ist,
passt in meinem Fall die 4096Byte umgemappte logische Sektorengröße nicht:
Die drei primären Partitionen werden noch angezeigt, (selbe Offsets, aber 8-fache Partionsgrößen)
die Erweiterte Partition und zwei logischen Partitonen werden nicht im loop0-Gerät angezeigt,
weil die auf 4096-Byte-logische Sektoren umgemappte Größe nicht zu der Original-Struktur passt (hier in meinem Fall), sondern zu 512 Byte logische Sektorgröße.
Weil zwischen den logischen Partitionen gibt es kleine Lücken, für eine eigene Partitionstabelle für die Beschreibung der anfügenden logischen Partitionen.

(das hier bei mir ist eine Demonstration für Testzwecke)
Weil in meinem Fall die vorderen Partitonen auch 8-fach-groß angezeigt werden und ursprünglich bei der Quelle auf 512-Byte Sektorgröße ausgerichtet sind, werden die Lücken für die Beschreibung der Logischen Partitionen (bei 4096 Byte umgemappter Größe) nicht gefunden/ (sind in falschen Bereich), und die gemappten logischen Partitionen (hier bei mir /dev/loop0p5 und /dev/loop0p6 können,
dann bei "fdisk -l /dev/loop0" (l = kleines L - für list, LPartitionsliste ausgeben) natürlich nicht gemeldet/erkannt werden.


Bei einer Quell-HDD mit Partitionierungs-Struktur und Dateisystemen angepasst ist auf 4096-Byte-logische-Blockgröße,
wo bei der Quelle 512Byte gemeldet wird, wegen UN-passendem Adapter,
wo man auf 4096 Byte um-mapt (dies darauf korrigierend anpasst), wird die Ausgabe der Partitions-Grenzen und Größen etc bei "/dev/loopX" natürlich wieder stimmen.

Hier in meinem Fall ist es falsch gemappt (4K-emuliert durch ummaping) bezogen auf die bisherige Struktur, weil die Quell-Datenstruktur/Partitions/-grenzen und -Größen ursprünglich nicht auf 4K-Emulation, sondern auf 512Byte gemeldete HDD-Sector-Größe ausgerichtet ist)

(das hier von mir bei mir ist ein Beispiel-Schema)
-----------------------------------------------

Das Um-Mappen eines Speichergerätes von 512 Byte auf 4096 Byte emulierte Sektoren-Größe, macht man damit:

losetup  --sector-size 4096  --find  --show   --partscan  --read-only  --verbose /dev/sdX

"sdX" durch "sda" bzw. "sdb" oder "sdd" bzw. durch "sde"
oder "sdf" oder "sdg" ersetzten, abahängig davon, welchen device-node (/dev/sda, oder /dev/sdb , bzw. /dev/sdc....usw)die Quell-HDD/SSD zugeordnet bekommen hat.

Selbiges Prinzip geht auch mit Image-Dateien (im geeigneten Format), also reine Rohdaten-Festplatten-Abbbildern (z.B von "dd" oder "ddrescue") (also inkls. z.B. mit einer Partitionstabelle innerhalb des Images) wo dessen gesicherte (Rohdaten) von der Quell-HDD z.B. aber vllt. auf 4096-Byte ausgerichtet sind, wo man ggf. noch unmappen muss, wenn die Mount-Funktion von Windows und Linux erstmal NICHT mit den 4096-Byte ausgerichteten Struktur in der Quell-HDD oder Quell-Image zurecht kommen sollten, wegen Auswertbarkeit:

losetup  --sector-size 4096  --find  --show   --partscan  --read-only  --verbose HDD-Backup.img

Wenn überhaupt keines der mehreren frei verfügbaren loop-Gerät belegt ist, dann wird für das dorthin zu mappen üblicherweise das erste frei verfügbare loop-device (/dev/loop0) benuzt.

Abhängig davon wie viele Partitionen das Quellgerät, oder die Imagedatei von der kompletten Festplatte/SSD hat...
....erscheinen dann nach dem Kommando...
"losetup --sector-size 4096 --find --show --partscan --read-only --verbose /dev/sdX" ...

...bei drei Partitionen z.B. :
/dev/loop0p1
/dev/loop0p2
/dev/loop0p3

...bei einer Partition:
/dev/loop0p1

Das "sdX" zu ersetzen durch entsprechend zugeordneten richtigen Device-Node
Siehe paar Abschnitte darüber (über dem Screenshot), wo drei einfache Kommandos beschrieben sind, den richtigen Device-Node der Quell-HDD zu finden. Ist es ein Image als Quelle ist es noch etw. einfacher.

Nun kann man die Partitionen von dem Quellgerät auf das virtuelle Gerät um-gemappt (jetzt 4096 Byte logische Größe), davon die Dateisyteme mounten...
Jetzt müssten die auf 4096 Byte logische Sektorgröße ausgerichetete Struktur interpretierbar sein, über das virtuelle um-gemappte Gerät...
...müssten die Partitionsoffsets und Größen richtig interpretiert werden,
... die Dateisysteme sich einhängen lassen
...und auf eine andere HDD auf Dateisystemebene umzukopieren möglich sein, die genug Platz haben muss.
Für das Rüberkopieren auf Ersatz-HDD (auf Dateisystem-Level) klappt es prinzipiell, unabhängig danvon, ob die Ersatz-HDD eine andere logische Sektorengröße nach außen meldet.
---
Dasselbe geht ntrl. auch mit VeraCrypt und TrueCrypt verschlüsselten HDDs oder mit Truecrypt/VeraCrypt-verschlüsselten-Rohdaten-Images, die auch auf eine ursprünglich ausgerichtete 4096-Byte-HDD-Sektoren-Anzahl eines alten kaputten USB-Gehuses stammen, aber in einem anderen Ersatz-USB-Gehäuse auf 512Byte logisch melden, welches die HDD-interne-Firmware-logische-512e Simulation einfach nur ordnungsgemäß durchreicht, und nicht interferiert, aber man temporär auf ein virtuelles Gerät aber auf 4096 logisch emulieren muss, um die Daten verwertbar zu retten:
Hierbei wird einfach genauso der Befehl benutzt...

"losetup  --sector-size 4096   --find  --show   --partscan  --read-only  --verbose /dev/sdX"

und im TrueCrypt oder Veracrypt-Fenster im Mount-Menü, das neue Gerät /dev/loop(Nr.) gewählt,
und mit entsprechend richtigem Password oder ggf. Password+PIM gemountet.
--
Ob die Quell-HDD "GPT"-Partitionierungs-Art oder "MBR"-Partitions-Stil benutzt, ist egal.
Das hat (K)einen Einfluss auf die Interpretierbarbarkeit / Nicht-Auswertbarkeit der Datenstruktur/Partitionen/Dateisystemen und darauf enthaltenen Daten.

----
Von dem von der Quell-HDD auf umgemappteten virtuellem Gerät, Dateisystem/Dateisysteme (wenn mehrere Partitionen vorhanden) nun mounten:

..Bei NTFS/FAT32/exFAT:

mkdir   /media/loop0p1

Partition 1 mounten - oder wenn nur eine Partition drauf vorhanden (z.B. NTFS oder FAT32 oder exFAT):
mount  -o   ro,uid=knoppix,gid=knoppix,umask=0007,iocharset=utf8   /dev/loop0p1   /media/loop0p1
--
mkdir   /media/loop0p2

Partition 2 mounten (z.B. NTFS oder FAT32 oder exFAT)
mount  -o  ro,uid=knoppix,gid=knoppix,umask=0007,iocharset=utf8   /dev/loop0p2
/media/loop0p2
---
mkdir   /media/loop0p3

Partition 3 mounten (wenn EXT2/Ext3/Ext4)
mount   -o   ro   /dev/loop0p3    /media/loop0p3

Erstz/HDD Partiton mounten:

mount  -o  uid=knoppix,gid=knoppix,umask=0007,iocharset=utf8    /dev/sdXy
/media/sdXy

Hierbei ist davon ausgegangen das auch auf der Ziel/Ersatz-HDD schon ein Dateisystem (z.B.) NTFS schon drauf ist. Es muss noch genug Speicher frei sein.

sdXy durch "sde3" "sdc3" oder "sde2" "sdc2" oder so ersetzten (sieh Ausgabe "/cat/proc/partitions", was bei Dir angezeigt wird)

Nun in "Dolphin"-Dateimanager die eingehängte Partition auf der Ersatz-HDD in das vorhin eingehängte Verzeichnis "/media/sdXy" öffnen
Und von der Quell-HDD: das umgemappten virtuellen Laufwerk (dev/loop0p1), das hierhin gemountete Dateisystem "/media/loop0p1" in weiteren Dolphin-Datemanager-Fenster öffnen.
entsprechende davon eingehängte Partition nach "/media/loop0p1", "/media/loop0p2"
öffnen und die zu rettenden Dateien ins andere Dolphin-Fenster /media/sdXy rüberkopieren.
[Edit] Das loop-device ist von der Quelle "read-only" gemappt worden, und am Einhängepunkt "read-only" gemountet, von daher kann bei der Quelle nicht versehntlich was gelöscht/umbenannt noch versehntlich verschoben werden.
[Edit] Nach dem Retten der Daten auf die andere HDD, die Partition/en auf der Ziel-HDD bitte nicht vergessen unzumounten. Sofern mehrere Partitionen auf der Ziel HDD einhehängt, Befehl entsprechend wiederholen mit höhere/niedriger Partitionsnummer, also nach dem Schema sdX6, sdX5 sdX3 sdX2 ect.

umount  /media/sdXy

sdXy durch "sde3" "sdc3" oder "sde2" "sdc2" oder so ersetzten (sieh Ausgabe "/cat/proc/partitions", was bei Dir angezeigt wird).
Sollte das un-mounten der Ziel-HDD-Partition nicht klappen, ist noch der Mount-Verzeichnis geöffnet,
und ggf. auch die- Hin-und zurück-Funktion, in- und aus dem Verzeichnis raus, in Dolphin ggf. noch gespeichert, deshalb muss der Dateimanager noch ganz geschlossen werden, und ein Wechseln raus aus dem Verzeichnis reicht nicht. Weiterhin hat der Anwender ggf. noch eine Datei offen, um den Inhalt zu überprpfen, alles stimmt, die man vorher schließen muss.

Läuft ggf. noch ein Prozess des Mountpoints der Ziel/Ersatz-HDD im Hintergrund in Hintergrund, findet man die Prozessnummer raus mit:

ps  ax  |grep  /media/sdXy

bzw.

lsof  |grep  /media/sdXy

Das "sdX" zu ersetzen durch den entsprechend benutzen Namen des Mount-verzeichnisses im Ordner /media/"

Nun wird einer/mehrere Prozess/e, mit "/media/sdXy" in Benutzung angezeigt:
Ggf werden zwei Spalten mit verschiedenen Nummern (5-stellig) (mehrere prozessnummer-zuodnungen auf selben Prozess) pro Zeile aufgelistet.

Einer Nummer der einen oder anderen Spalten (oder bzw. beide) sollte gehen:
Nun falls notwenidg, wenn unmounten sonst nicht klappt, alle Prozessnummern mit Bezeichnung "/media/sdXy" "stoppen" ("killen"):

kill   -9  Prozessnummer

Nachdem alle Przessnr. mit "/media/sdXy" "gekillt" wurden, sollte sich die Ziel-HDD nun wirklich unmounten lassen (siehe etw. darüber wie das geht).
Sollte das Dateisystem der Ziel-HDD nach dem Schreiben nicht (aus)gehängt getan worden sein, gibt es oft nur dann ein paar Dateifehler, wenn der Schreibcache vom letzen Kopiervorgang noch nicht volständig zu Ende gekommen ist, nachdem der HDD-bzw-RAM-Cache geleert wurde.
Wer sich unsicher ist, bei "NTFS"-Dateisystem, führt in Windows noch einen Check-Disk- drüber,
in cmd/Eingabebeaufforderungs-Box Rechtsklick "Als Admin Ausführen"

chkdsk  /f  LW:

Hinweis: Wenn "chkdsk" sagt "Das Laufwerk wurde erfolgreich überprüft, es wurden keine Probleme festgestellt", dann wurden trotz eines ggf. fehlenden unmountens später vor dem Neustart aus Linux, die Daten trotzdem richtig geschrieben. Ich habe die Erfahrung gemacht, wenn viele Daten geschrieben wurden, oder viele Dateien umbenannt, mals öfters paar Dateien gelöscht und kopiert, dass bei vielen Aktionen, ohne Unmountens, der
"chkdsk" oft ein paar Datei-Fehler findet.

Die Quelle muss nicht zwingend ungemountet werden, sofern der Nutzer wie in der Anleitung, den Inhalt der Quelle ausschließlich als "read-only" zugänglich gemacht hat.
----
Hinweis:
Falls die Quell- und Ziel-HDD ein NTFS-Dateisystem hat, ist noch zu bemerken, das am Ziel bei nach dem Kopierten für die neu angelegte Dateien- und Verezeichnissen durch Linux, die Zugriffsberechtigungen für diese auf "Jeder" gesetzt sind , weil Unix ein anderes Berechtigungssystem benutzt als Windows und die Attribute auf der NTFS-Partition ignoriert:
Das kann man auch für die kopierten Verzeichnisse nachholen:
Anleitung unter Windows 7 (Windows 8.1 und Win10 vom Prinzip her ähnlich), ggf. (teils) leicht abweichende Menüführung, dort wo man die Rechte ändert.
Besitz von Dateien und Verzeichnissen übernehmen und Zugriffsberechtigungen verwalten
https://support.microsoft.com/de-de/help/980023
---
In Falle von, dass man sich versehntlich aussperrt bei dem Zugriff auf die unter Linux kopierten Dateien/Ordner, wo man versucht die Zugriffsrechte, gemäß so wie es die NTFS-Partition bzw. deren Ordnerstruktur betrifft in Bezug auf Rechteverwaltung:
https://www.heise.de/ct/hotline/NTFS-Zugriffsrechte-zuruecksetzen-320980.html
NTFS-Zugriffsrechte zurücksetzen
21.08.2006
"Auf meiner externen USB-Festplatte befindet sich ein Ordner, den mich Windows nicht öffnen lässt - obwohl ich Administrator bin. Wie verschaffe ich mir Zutritt?"
{...}

 

[Mr.Anon]

@Vincent @MTechlerin

Hi,

I'm a little confused about the different chipsets, PIDs and firmwares.

According with this website, for vendor 174c (asmedia) there are this PID:

55AA: ASM1051E, ASM1053E, ASM1153, ASM1153E
5136: ASM1053
5106: ASM1051

I have a Sharkook SATA Quick Port XT USB 3.0 with an ASM1051 (i have opened it) with PID: 55AA (firmware 100824009100 updated to 13022081F602), Can the same chipset exist with two different PIDs? on this list there are two ASM1051 with different PID:

VID: 174C, PID: 5106 ASMedia ASM1051
VID: 174C, PID: 55AA ASMedia ASM1051 new firmware (2)

In this same thread I have seen some user who has bricked their device when updating the firmware, supposedly for flashing an ASM1053E (¿PID: 55AA?) firmware in an ASM1053 (¿PID: 5136?) device, but then why in the first post the download link is for both chipsets¿?

"Aktuelle Firmware für Intenso Center :ASMedia.1053/1053E Support 8TB+ HDD."

it really only works for ASM1053E, right?

Thank you very much!!

German google translate

Hallo,

Ich bin ein wenig verwirrt über die verschiedenen Chipsätze, PIDs und Firmwares.

Laut dieser website, gibt es für Anbieter 174c (asmedia) diese PID:

55AA: ASM1051E, ASM1053E, ASM1153, ASM1153E
5136: ASM1053
5106: ASM1051


Ich habe einen Sharkook SATA Quick Port XT USB 3.0 mit einem ASM1051 (ich habe ihn geöffnet) mit der PID: 55AA (Firmware 100824009100, aktualisiert auf 13022081F602). Kann derselbe Chipsatz mit zwei verschiedenen PIDs existieren? Auf dieser liste befinden sich zwei ASM1051 mit unterschiedlicher PID:

VID: 174C, PID: 5106 ASMedia ASM1051
VID: 174C, PID: 55AA ASMedia ASM1051 new firmware (2)

Im selben Thread habe ich einige Benutzer gesehen, die ihr Gerät beim Aktualisieren der Firmware blockiert haben, angeblich um eine ASM1053E (¿PID: 55AA?) - Firmware in einem ASM1053 (¿PID: 5136?) - Gerät zu flashen, aber warum dann in der ersten Den Downloadlink posten gilt für beide Chipsätze?

"Aktuelle Firmware für Intenso Center :ASMedia.1053/1053E Support 8TB+ HDD."

es funktioniert wirklich nur für ASM1053E, oder?

Vielen Dank!!

 

[Vincent]

@Mr.Anon
Many/some/a few of the firmwares MTechlerin provided (might be) outdated.
In case you'd use 4K-Emulation in firmware. E-g- afaik ASM1051/1053 has that on some firmwares, while on ASM1153E it's no longer offered, as not needed and making issues.

This usually makes just problems, when Swapping HDD into another USB case or to SATA and vise versa, for correct interpreting of the data, on different bridges with different emulation-settings.
If someone needed 4K-Emulation, recommended not by firmware (using HDDs own logical-sector size), and if needed to rescue the data, it's better to do it via software, e.g. in Linux via "losetup"-512e-to-4096Byte remapping.
See guide above post. For English speaking people, I hope google translate helps to understand the guide in post #153 better.

That over-2 TiByte just matters older BIOS PC, that BIOS cannot access all block addresses behind 2 TiBytes, which just understand MBR. From a a running operating system, even on older BIOS-PCs, you can still access all data from whole HDD, also behind 2 TiBytes (must use "GPT")

Yes TV-boxer/recorder boxes with outdated software, just knowing MBR-partition-table, might require 4K-Emulation to be able to make use of a full HDD bigger than 2 TibiByte (max up to 16 TiBiBytes) while still having MBR-table type.

PID "5136" might be in fact designated for ASM1053 or vise versa, and or by 3rd-party producer/seller who used for their sepcific product.
PID "5106": might be in fact designated for ASM1051 or vise versa, and/or by 3rd-party producer/seller who used for their sepcific product.

PID "55AA": I'm not 100% sure, if it was done intensionally to use for all them, ASM1051E, ASM1053E, ASM1153, ASM1153E.

All I know for Inateck and Fantec products I bought, which I checked they both having in fact the newer ASM1153(E), they both shows up as VID "174C" (for asmedia), PID "55AA"(ASM1153/ASM1153E)

ASM1153 (=SATA-3G) afaik is a bit older than 1153E (=SATA-6G) but both using same PID, and same firmware.
At least "55AA" is preset on the standardly delivered firmware from my Fantec and Inateck products with ASM1153E-chip, and standardly set in the Asmedia MPTool, on some zip-package where an Asmedia-MPtool is delivered with and the ASM1153/E-firmware.

I've also seen complaint's from Linux-Kernel developers, and/or from smartmontools, about broken UASP support, and UASP blacklisting for some specific older amedia chips (or just by too old firmware), that Asmedia and/or the supplier would use PID "55AA" for ASM1051/ASM1053 and ASM1153/ASM1153E, and Linux having issues what driver-settings to apply for which chips etc.

But as you found in the list, I'd then rather expect PID "5136"/"5106" was for the older generation ASM1053 and ASM1051, and PID "55AA" only for ASM1153/ASM1153E.

Yes it's correct, that there can be same firmwares for same/ very similar group of chips (ASM1153/ASM1153E);
other for (ASM1051+ASM1053)

But you may NOT use firmware from (ASM1153/E) for ASM1051/ASM1053, and other way around, this will probably brick device!!

Even if you want to flash ASM1153E-firmware+MPTool, with VID "174C" and with "PID" 55AA as preset,
afaik you still cannot use on ASM1153/E on ASM1051/1053E, this will probably brick the device.

--
Afaik, Principially the VID, and PID, which is shown, when the device is connected, can be changed manually (but principially should NOT be), by the user by a setting for the firmware in Asmedia-MMPTool/as_mptool_vx.ini, ini before flashing, prinicpially on any firmware. But principially I would NOT advice to change it, so leave it as it was like on original product. If it was changed by 3rd-party seller or in the MPTool it was delivered and preset with a few VID/PID settings from other enclosure-firmware, and you knew the built-in chip certainly has assigned a specific PID as in written VID/PID/specs/database/datasheets, you can change it in the MPTool to that, in case trying to flash a suitable firmware for the chip.

Yes it might be that ASM1153/E can still have same PID as ASM1051. I'm myself surprised that could be several PIDs sorted to those chips.

What matters that the firmware matches to the chip. Changing VID and PID-setting (or a firmware declared with MPTool with same VID+PID preset) to flash with firmware, of course does NOT make if a firmware was (in)compatible, does NOT get a wrong firmware compatible at all.

If using firmwares from anybody also from forum, I'd also compare with e.g. "usbdev.ru" the firmware-file name inside, (and its file-checksum), If you find same firmware file on "usbdev", with corresponding what is labelled on your ASM-chip.
Preferably I'd recommend a more-direct-source-site, maybe (a bit) safer than via middle-person on forum.

See example below:
In any case, a good source is "usbdev". I have never bricked my devices, using suitable firmware from there, which I looked there and found specifically written for my Asmedia chips.

E.g. here are firmwares , they go for both the chips (ASM1051/ASM1053).
The ASMT-2XXX ASM-3xxx etc. afaik is just an other naming scheme from asmedia for their different chips. )

(Asmedia ASMT-2105 Firmware (ASM1051, ASM1053)
https://www.usbdev.ru/files/asmedia/asmt2105firmware/

---
Asmedia ASMT-2115 Firmware (ASM1153, ASM1153E)
https://www.usbdev.ru/files/asmedia/asmt2115firmware/

--
There's also station-drivers.com, found good firmwares there, but recently flashed a wrong firmware for my ASM1153E, they claimed to be for ASM1153/1153E, but which afaik is for newer one (ASM1351/1352R)

--

As about the complaints from developers, sometimes problems to identify correct chip from PID+VID, there also a "product string" bar in the Asmedia-MPTool. Addionally I have put into the "Product string" ASM1153E" for my ASM1153E products, before flashing firmware, in hope that that helps the driver/software to more easily detect the real chip.
If your cases have ASM1(0)51 and/or ASM1(0)53 I'd place that into "Product string". E.g. replacing in the "Product string" bar, the name of the USB-case/vendor in the "Product string" text area, by the "ASM1051" or "ASM1053" in your place, if your products have those chips, so that it helps software to better identify chip (in case there were several Asmedia chips used same VID+PID in the MPTool/firmware-preset-settings.


--------------------------------------------------------------------------------------------------
Neulich ein paar weitere Fantec DB-ALU3(E)-6G bei "Saturn" und "Mediamarkt gekauft" (weiterhin ASM1153E so wie die "alten von 2018/2019), auch mit SATA-6Gbit -> USB 3.0+eSATA (eSATA auch mit 6Gbit/s),
und festgestellt, dass diese später (Jahr 2020) gekauften Fantecs mit einer neueren ASM1153/ASM1153E Firmware als die anderen baugleichen DB-ALU3e-6G ausgeliefert wurden, die ich noch NICHT bei station-drivers.com und NICHT bei usbdev.ru gefunden habe, und auch bei Fantec noch NICHT zum Download angeboten wird:

(ASM1153/ASM1153E): 141126a13ca0 =>141126_A1_3C_A0
(Diese ASM1153/1153E-Firmware ist neuer und besser was die (ASM1153/ASM1153E)-Firmwares betrifft von MTechlerin im Start-Post.):
Hier der EEPROM-Dump von der 141126_A1_3C_80:
141126_A1_3C_A0_Fantec-DB-ALU3e-6G_(EEPROM-Chip-ausgelötet)-EEPROM-Backup_TL866A_Programmer-Lesegerät.bin
sha256sum: 98d80ce9837e960bfa8ac0b9e8d44aacc12c4ffcf173c1ed58eb0ebbf8f187aa
md5sum: 402d51737bab2e4ece59ffd934ffddf7
Download:
http://arny.tjps.eu/vinc/141126_A1_...EEPROM-Backup_TL866A_Programmer-Lesegerät.bin

SSD-TRIM (über SCSI-Unmap) funktioniert auch damit! (wie bei 140509_A1_82_40)
Optische Laufwerke gehen damit (EDIT] wie bei (fast) allen anderen UASP-fähigen-Firmwares) allerdings (noch NICHT) über USB.

Diese Firmware schleift die HDD-Standby-Einstellung der Festplatte durch, und funkt dort nicht mehr rein.
HDD-Standby-Probleme gelöst (!!)
Hinweis:
Sofern die HDD selber (K)einen blöden APM-Wert in der HDD-Firmware schon einprogrammiert hat (wie diesen z.B. : "128": minimum Power-Consumption without Standby" ->HDD-Standby nach 5 min.),also besser selber z.B. 254 oder "Disabled", dann geht die HDD nicht in den Standby, das Gehäuse jednefalls funkt dort NICHT mehr mit rein, den HDD-Stdnaby zu erzwingen (HGST 4TB HDD APM=Disabled) bleibt im Gehäuse auch auf "Disabled".

Bei Intenso HDD 4TB (ist so eine Toshiba 4TB MGAZ... SATA oder so ähnlich drin), und WD My Book 8TB (WD80EZAZ SATA), da hilft es nichts, da die HDD-Firmware, "APM=128" benutzt, d.h. auch ungünstigere HDD-APM-Werte wie "128" in der HDD-Firmware, werden mit Firmware "141126_A1_3C_A0" durchgereicht, und HDD geht dann (doch) in den Standby (bei ungünstigen HDD-Firmware-APM_Wert).
--
Werde ich noch versuchen mit dem ext. Programmer diese Firmware zu dumpen (schon probiert über In-Circuit-Serial-programming, aber doch rel. knifflig über ICSP, werde den Fudan FM25F01 EEPROM vrmtl. auslöten müssen, um ihn fehlerfrei auszulesen)- Muss aber noch angepasst werden auf die ca. 60 KiBytes größe, weil der ganze FM25F01-EEPROM-Chip in der Fantec hat 128 KiBytes, (hatte in Vergangenheit eine ältere schonmal ausgelesen, weiter hinten hinten lauter "FF" (hinten keine Daten, also blank)und das brickt die Firmware, selbst wenn man das gedumpte 128 KiByte-Image (verkleinert auf 60 KiB), flasht, egal ob Fantec oder sonstein Gehäuse (getestet). Nur das gesamte 128 KiByte Image kann auch z.B. bei den anderen Fantec DB-ALU3e-6G flashen, aber halt nur bei diesem Model mit dieser EEPROM-Größe.
Die bei "usbdev" oder "station-drivers" müssten das gedumpte Image anpassen, wenn ich denen das bereitstellte und hochladen sollte, dass es für alle ASM1153E-USB-Gehäuse flashbar und einsetzbar wäre (ich kenne mich damit, wie man das Image anpasst, allerdings überhaupt NICHT aus)

--
Dann noch eine neuere ASM1153/ASM1153E Firmware gefunden (bei statio-drivers.com), und getestet.

141126_A1_EE_82
https://www.station-drivers.com/ind...ory&Itemid=353&func=startdown&id=4053&lang=en
"fg66 2019-12-21 22:00:35 With this firmware, TRIM is working under Windows10 :-) "


HDD-Standby-Issue fixed , setzt HDD-eigene-Firmware-Einstellungen (zwar) außer Kraft, aber erzwingt, dass das APM (de)aktiviert wird. Getestet zeigt bei allen HDDs jetzt, auch bei welchen, die selber eigentlich "128" hätten, nun: APM= 254 (Maximum performance). Muss nochmals testen, aber schaltet auch bei Reboots des PCs die HDD auch nicht ab
Was zwar auch mit Firmware 131126_A1_00 auch klappt, welche aber kein SSD-TRIM kann, und (K)eine optischen Laufwerke unterstützt.

SSD-TRIM funktioniert auch damit, getestet. (141126_A1_EE_82)
Und Optische Laufwerke werden damit erkannt (141126_A1_EE_82), +UASP mit HDDs/SSDs,
die Firmware schaltet dabei automatisch in den USB-BOT-Modus um, wenn ein ATAPI-Laufwerk (CD/DVD/Blu-ray) angeschlossen wird.
UASP geht ja zusammen mit ATAPI nicht, (K)eine SATA-USB-Geräte, noch irgendwelche Werbung mir bekannt, die das können sollen.

Die ODD-Seriennummer mit (Scan_HDDSN=1 mit asm_mptool_vx.ini Flasheinstellung) wird hier durchgeschleift, allerdings wird der ODD-Modelname nicht durchgereicht, sondern da steht dann ASM1153/ASM1153E (was bei Product-String im MPool zur Darstellung des Productnamens nachm Flashen als Text eingestellt wurde) als Model drin, das gleiche bei angeschlossener HDD/SSD.

Mitgeliefert wird ein neuere Asmedia-MPtool-Version (EDIT für die Chipreihe ASM105X, ASM11xx, die bei usbdev.ru glaub noch fehlt, welche einen neu gestalteten Config-settings-Dialog erlaubt.

-------------------------------------


ACHTUNG: Eine andere, auch in der Rubrik "ASM1153/ASM1153E" angebotene Firmware auf station-drivers.com, also"141126_A1_C4_80" ist wohl (falsch) deklariert!!

141126_A1_C4_80
Dort im .zip-Datei ist (K)eine "141126_A1_C4_80" drin, also zwar schon eine ["config-141126_A1_C4_80.bin"] (eigentlich wird zum FLashen nicht die config...bin direkt ausgewählt, sondern zwischengespeichert wohl mit ggf. geänderten FW-Einstellungen von der MPTool.ini).
Daneben ist noch eine falsche Firmware enthalten (Vorsicht!!),
, die von der Bezeichnung her (OHNE "config-..._.bin" (davor), die eher zum ASM1351/ASM1352 bzw. ASMC325M oder so ähnlich vom Namensschema her passt,
die dort im MPTool ggf. vorausgewählt ist (Vorsicht!)

Würde ich nicht nehmen, hat mir eine Fantec zerflasht.
("Fail", ich muss wohl EEPROM-Chip auslöten, neu programmieren, und neu einlöten),
oder via In-Circuit und und regelbarem Netzteil (mit verschiedenen V bis max 12V) am DC-Port probieren (wird ja in der Schaltung auf 3.3v oder so nochmals runtergeregelt), und dann per ICSP am EEPROM nochmal vorsichtig probieren, ob's jetzt zuverlässig klappt.
----

 

[Mr.Anon]

@Vincent

First of all, thanking you for your extensive response. Is very helpful for me.

4K-emulation

Yes, I am aware of this feature, In fact, i had a firmware with 4k-emulation in an ASM1051 and I changed it to another WITHOUT 4K.

PID

My Sharkoon SATA Quick Port XT USB 3.0 with an ASM1051, both before and after flashing a firmware from the sharkoon support, the PID is 55AA and not 5106.
Later I realized that it was the same firmware as "ASMedia.1051.No.Name.Device.7z" which can be found in the first post of this thread, and also comes with the PID 55AA in the preset file.
So, might be that ASM1153/E can still have same PID as ASM1051.

141126_A1_EE_82 for ASM1153E

In addition to my sharkoon with ASM1051, I bought an Inateck UA1001 unit with ASM1153E and factory stock firmware 141126_A1_E8_20 that i think does not support UASP but is compatible with ODD (ATAPI) because i tested it with a SATA DVD drive

so far I had these two firmware as recommended:

• 141125_21_00_00_ODD.bin for ODD support
• 140509_A1_82_40.bin for TRIM and UASP support

So, with 141126_A1_EE_82 can i have UASP and ODD support in one firmware, like a 2in1 firmware!? (not at the same time, since ATAPI on UASP is not possible).

"NO ODD/HDD/SSD-product-name-passthrough (uses Asmedia Product string), but yet does for the Serial-number (as_mp_Tool v0.5.ini: Scan_HDDSN=1) - Enforces Disabling HDD-Standby (APM=254 for all HDDs)"

is this important? What limitations and consequences does this firmware have no support for product-name-passthrough? Not having HDD-Standby is not a problem for me.

Thanks again!! 👏

 

[Vincent]

@Vincent
{...}
4K-emulation
Yes, I am aware of this feature, In fact, i had a firmware with 4k-emulation in an ASM1051 and I changed it to another WITHOUT 4K.
]{...}

Yes, as normally, this is a good/advisable choice!

{...}
PID
My Sharkoon SATA Quick Port XT USB 3.0 with an ASM1051, both before and after flashing a firmware from the sharkoon support, the PID is 55AA and not 5106.

Later I realized that it was the same firmware as "ASMedia.1051.No.Name.Device.7z" which can be found in the first post of this thread, and also comes with the PID 55AA in the preset file.

So, might be that ASM1153/E can still have same PID as ASM1051.

Still keep in mind, that ASM1153/E chip uses DIFFERENT firmware than the ASM1(0)5X chips, and same problem also the other way round.

Yes if the firmware MTechlerin reported was for ASM105X, yes, you can use it for your ASM105X products, (but NOT ASM1153/E and vice versa!!

There were some users who might have bricked their Fantec here on the Forum. They e.g. bought a (wrongly ) declared Fantec DB-ALU3(e)-6G, which in fact had an (wrong) ASM105X chip, who flashed over an incompatible (e.g. AM1153/E-firmware) for an ASM105X, but they expected for their Fantec DB-ALU3e-6G normally should have the ASM1153/E chip of course, bricking their device.

Best is first read the chip’s model, and opening your product, and if it is an ASM105X chip, compare the file name and its file-checksum, pr from eg. also good source like „USBdev“, and take attention that you’re at the coprrect corresponding ASM-Chip-firmware-listing-page-site for ASM 1(0)5X chips on USBdev, (if you have an ASM1(05)X chipped product.)

Same kind of principle goes for ASM1153/E chips etc.
But anyway if you have flashed the firmware „ASMedia.1051.No.Name.Device.7z“ MTechlerin provided, and the ASM105X-USB-bridge is still detected by the MPTool, and it’s working, YES then you have flashed the correct firmware for your ASM105X product/s.

Yes that might be possible that Asmedia, and/or 3rd-party sellers sometimes use same PID for some older Asmedia-chips as for some newer chips, or they decide to flash with their own one, or it might have happened by „accident“, that the user flashed another appropriate ASM105X firmware for his ASM105X chip, but he had used a preset from the MPTool with another PID. In case s.o. would have done that I'd recommend to reflash the ASM105X compatible firmware with MPTool setting, its PID changed back to the one it came originally with).
----
Anyway I haven’t tried intentionally to change the VID/PID. I would NOT recommend it to do it.
---
The set/flashed VID/PID of the Asmedia-chip is listed in the MPTool in the MPTool-USB-status-line (NOT any Devices docked to it).

When during a device is docked to the USB-SATA-adapter, the actual VID/PID listed by the MPTool of he SATA-USB-adapter appears „replaced“ by the one oft he docked device, so the real VID+PID oft he SATA-USB-bridge gets somehow hidden in the MPTool during that period, so in that consteallation you’ll only find the actual VID and PID oft he SATA-USB-adapter in the corresponding Device-manager sections:
Eg. VID/PID oft he asmedia Chip is displayed (USB-BOT-mode) in the =>“Windows-device-manager“ in the ->„USB-Controllers“ -section ->“USB-Mass Storage Device“ , ->“Details“.
In UASP-mode the USB-bridge‘s VID/PID is displayed in Device Manager under ->SCSI-icon/logo=> ->„Storage-controller“ ->“USB Attached SCSI (UAS) Mass Storage Device“ ->“Details“.

--

In addition to my sharkoon with ASM1051, I bought an Inateck UA1001 unit with ASM1153E and factory stock firmware 141126_A1_E8_20 that i think does not support UASP but is compatible with ODD (ATAPI) because i tested it with a SATA DVD drive

so far I had these two firmware as recommended:

• 141125_21_00_00_ODD.bin for ODD support
• 140509_A1_82_40.bin for TRIM and UASP support

So, with 141126_A1_E[E]_82 can i have UASP and ODD support in one firmware, like a 2in1 firmware!? (not at the same time, since ATAPI on UASP is not possible).

Yes I can confirm. My Inateck UA1001 was delivered with firmware „141126_A1_E(8)_(20)“ standardly as well, like yours.
I had bought an Inateck UA1001 myself. It has ASM1153E chip and Fudan FM25F005 EEPROM (64 KibiBytes SPI/EEPROM size).

Inateck UA1001 Standard predelivered-firmware 141126_A1_E(8)_(20)
Without ODD docked: SN=000000000000


With ODD docked: SN=K9A.........


---
Yes firmware „141126_A1_E{E}_{82}“ is for ASM1153/E.
So you can flash it for your Inateck UA1001 (with ASM1153/E) chip, because my Inateck UA1001 is with ASM1153E chip, was also pre-delivered with 141126_A1_E(8)_(20)“ like yours, so it's kind o proof that your Inateck UA1001 certainly has ASM1153/E chip as well.
---------------------------------------------------------
Yes Firmware „141126_A1_EE_82“ is a 2-in-1 firmware.

It supports ODDs (using USB-BOTP) (afaik generally there are NO ODDs supported by UASP), BUT is capable to use/switch to UASP-mode, when HDD and SSD connected (and SSD-TRIM support). And it has fixed the HDD-standby-issue, by enforcing APM=254 (Maximum-performance) on all HDDs, when adapter connected via USB to the host.
----
Yes, you are correct, the standardly delivered firmware „141126_A1_E(8)_(20)“ on the „Inateck UA1001“ uses already (only) USB-BOTP, so it does not support UASP at all. It was tested working by me also with ODDs (CD/DVD/Blu-ray).
If you were happy with USB-BOTP, and ODD-support, as well using USB-BOTP for HDDs/SSDs (so anyway NOT ANY SSD-TRIM) leave this firmware.

Firmware 141125_21_00_00_ODD.bin supports ODDs as „141126_A1_E(8)(20)“, but there is not any UASP-support with this fw (using USB-BOTP-mode generally) as on „141126_A1_E(8)(20)“. And it is minimally "worse" as it does NOT pass-through ODD serial number, just for SSDs/HDDs, but SSD/HDD/ODD-model-name

But the standard-firmware „141126_A1_E(8)_(20)“ on the Inateck UA1001 is able to pass through ODD-model name and SSD/HDD/ +ODD-model-Serial-number, HDDs etc. but there is not any UASP-support with this fw (using USB-BOTP generally) in general as on "141125_21_00_00_ODD.bin".

With ODD docked (Linux): Inateck seems to have set "ASM105X" as product setting flashed with the standard-firmware , which is irritating, because the chip at least on my Inateck UA1001 is ASM1153E. (The called product string, you have set in MPTool, and what VID/PID is principailly irrelevant which matters firmware-compatibility tot he hardware-chip, just that the taken firmware for the declared chip is correct), at least my UA1001 needs anASM1153/E firmware (it was just preflashed with a 105X product string name setting, which is just a cosmeticic thing in this case)

{...}
is this important? What limitations and consequences does this firmware have no support for product-name-passthrough? Not having HDD-Standby is not a problem for me.

Thanks again!! 👏

It’s not such a big consequense. It’s just a cosmetical „issue“.
The "consequence" of firmware 141126_A1_E{E}{82} would be, that docked ODDs/SSDs/HDDs appear (just named) as „ASM1153E USB device“ under the device/drive-section in Windows-device-manager, and in the safely-remove-USB-icon in Windows-Taskbar, so that what you have set as product string, in the MPTool, e.g. if you have set e.g. „ASM1153E“ as product string.
It will still NOT help, if you cleared the „Product String“ and reflashed with this, still the ODD/SSD/HDD model-name is NOT passed through at all.
So if you have e.g. also Cloning software and two SSDs/HDDs docked and connected, via same USB-bridge, both via same firmware „141126_A1_EE_82“, and the SSD/HDD have same capacity it might be irritating for some cases.
(In Linux the situation is a bit better, that there are some applications, like Linux-console/bash/shell/terminal, and in Acronis TrueImage (Bootable media (=uses Linux)) where the SSD/HDD/ODD model name gets passed through on some cases.)

Another example, in „Makemkv“/“AnyDVD“ ripping and ImgBurn/Burning etc software, e.g. if you had several ODDs connected via USB, it might be irritating if you have several Optical disc drives connected at the same time, to find out which drive letter was for which currently connected ODD-models, where which named inserted movie disc it was, and in the AnyDVD.ziplog (if having problems) e.g. ripping DVD/BD with AnyDVD and asking the Redfox-developer staff for help with your bought BD/DVD/movie discs (as personal backup of course), the presented "ASM1153E USB device" will be included into the "AnyDVD.ziplog", instead oft the model-text oft he docked ODD-model, so the RedFox developers can’t see from the AnyDVD-status-bar nor AnyDVD-.ziplog, which ODD-model, you used with the certain DVD/BD/UHD-BD-disc you are giving them reports having issues with.

[Edit]
Rechecked. Yes the ODD-model-name is also NOT seen by AnyDVD nor ImgBurn nor MakeMKV in Windows, nor anywhere in Windows-Device manager (as e.g. „ASM1153E“ product-string, if that what you have set)
---
https://makemkv.com/forum/viewtopic.php?f=16&t=18933&sid=b738b6a328d7de3a894bf303d6040fe1
NEW OPTION: 'UHD Friendly' Firmware Downgrade / Cross-Flash Using Official (Modified) ASUS Flasher for ASUS & LG Drives
https://forum.redfox.bz/threads/downgrade-uhd-drives-to-friendly-the-easy-and-safe-way.76551/

Anyway, even though the ODD model name is not passed through by firmware 141126_A1_E{E}{82} for ASM1153E, the ODD support of firmware "141126_A1_E{E}{82}" also includes usability of the "patched Asus/LG flashers" from Mike (MartyMcNuts) via USB, flashing UHD-friendly and/or LibreDrive-enabled-firmware from Downgrade-enabled-firmware and/or mk-firmware-pack on certain LG/Asus/ (NS50/NS55 compatible UHD-BD-drives) (BH16NS40 (NS50), LG BH16NS55, Asus BW-16D1HT (2015+), LG WH16NS60, etc.),...

(Updating Asus BW-16D1HT (Apr. 2017 =2015+ <=NS55 compatible ) UHD BD-unit 3.01 Original BW-16D1HT-to "Asus BW-16D1HT 3.10 MK"-firmware (edited by Mike MakeMKV) via SATA-USB-adapter (ASM1153E firmware 141126_A1_EE_82) via USB...
...even though the ODD-model-name is not passed through, Asus BW-16D1HT 3.01 unit listed as "ASM1153E" 3.01 (Asus BW-16D1HT FW 3.01) , updating it to "BW-16D1HT 3.10 mk"
but the user has to take attention having connected correct ODD unit, especially here with just "ASM1153E" shown, and not to confuse especially here, when other units attached etc.), and 3.01/3.10 is NOT belonging to the Asmedia chip, but to the Asus BW-16D1HT ODD drive.

After updating the Asus BW-16D1HT BD-UHD unit's firmware from 3.01 to "3.10 mk" via USB, it's still working, also in MakeMKV, shown as 3.10, and now with "LibreDrive" Enabled...

---
...and, not too bad, when connecting it via eSATA port of ASM1153E SATA->USB 3.0+eSATA enclosure, it's detected as "Asus BW-16D1HT 3.10" normally.
---
Example (via SATA/eSATA), similar to what it should look like, if ODD-model name was pass-throughed via USB:

---------------

But except of that, that SSD/HDD/ODD model-name is not pass-throughed, there are no other (possible) disadvantage oft „141126_A1_E{E}{82}[/I]“ compared to he other firmwares,
so here the other points, like two-in-one support, ODD-support (=generally only possible via USB-BOTP-mode), also with firmware 141126_A1_E{E}{82} on the SATA-USB-bridge the ability to use via USB for the patched LG/Asus flashers for Downgrading/crossflashing LG-NS55 compatible drives to UHD-friendly/LibreDrive,
while having UASP for HDDs/SSDs (+TRIM-support), and fixed HDD standby-issue, are just advantages. .

In the MPTool 2.1.21.5 DBG (DBG=debug?), in the (More Config +) button I have noticed besides a „HDDSN“ firmware-flash-setting-checkbox a „WHCK“ and „QD32“ checkbox.

[Edit]
Tried different MPTool-settings and combinations, also WHCK and QD32, but there’s still no ODD/ SSD/HDD model-name passthrough.
WHCK has something to do with Windows Driver signing according to wikipedia.

And „QD32=1“ means Queue Depth, (enabling max up to 32 Commands per Queue) via SCSI/UASP over USB, for e.g. SSD/HDD Native command queing (SATA AHCI Mode: Max. „1“ Queue, and 32 Commands per Queue – while nVME (for PCIe SSDs) supports 65535 Queues and 65536 Commands per Queue)

So QD32=1 setting (=>Queue Depth=“32“ =On) might increase random/IO-performance for the docked SATA device (SSD/HDD), and should have identical Queuing depth like SATA-ACHI (attached directly to SATA)...
...(but not for ODDs, as for ODDs just USB-BOTP possible, and USB-BOTP does not have command queing/channel parallelism) on the SATA-USB-adapter over USBl

(+ It's recommended having Write-cache enabled also for the SSD/Hard disc drive via USB in the Windows-Device manager under "Drives"-Section, if you want .e.g. noticbly 3rd-times higher speed here on USB 3.0, but has more risk if you're forgetting safely-remove, because it might buffer/sort data into into SSD/HDD-cache not attempting to write all always at once.
------
The inlcuded MPTool together with the „141126_A1_E{E}_{82}“ firmware might have as a preset s.th. like this „Ugreen storage" by standard. I have changed the text to „ASM1153E“ (without quotation marks) in the product string bar, before flashing this firmware, so that it reports as ASM1153E instead of „Ugreen…“ named device.

 

[chris-22]

Hallo,

ich habe ein Inatek Gehäuse gekauft und will den ASM1153E Controller flashen. Gibt es irgendwo ein Firmware Changelog, wo man die Änderungen sieht?

Ausgeliefert wurde das Gehäuse laut MPTool mit FW 140704a18701. Bei station-drivers sehe ich aber unter 140704 nur eine 140704_A1_A9_02, ist da womöglich eine exlusive Inatek FW Version drauf?
https://www.station-drivers.com/ind...ository&Itemid=352&func=select&id=537&lang=en

Was bringt der Flash auf FW 141126_A1_EE_82?
Wo sehe ich, ob die FW mit UASP ist?

MfG
Chris

 

[Vincent]

Hallo,

ich habe ein Inatek Gehäuse gekauft und will den ASM1153E Controller flashen. Gibt es irgendwo ein Firmware Changelog, wo man die Änderungen sieht?

Ein Changelog fände ich auch hilfreich. Bei Asmedia habe ich keine Firmwares gefunden.
"Nur" über Drittwebseiten wie "station-drivers.com" und "usbdev.ru".
Changelogs habe ich auch bei den Drittwebseiten nicht gefunden, aber zumindest Bewertungen zur jeweiligen Version, was die Firmware für spezielles Features kann.
Es gibt verscheidene Varianten von Firmwares für den selben Chip, die alle mehr oder weniger ihre Vor- und Nachteile haben. Aber ich kann aber definitiv eine EMpfehlung aussprechen, für die 141126_A1_EE_82 Grund siehe noch weiter unten.
Falls später noch eine neuere Firmware rauskommt, kannst man ntrl. wieder neu flashen und ausprobieren, ob auch die letzten (kleineren Schwächen von 1411_26_EE_82) ausgemerzt sind

--

Ausgeliefert wurde das Gehäuse laut MPTool mit FW 140704a18701. Bei station-drivers sehe ich aber unter 140704 nur eine 140704_A1_A9_02, ist da womöglich eine exlusive Inatek FW Version drauf?
{...}

Ja Inateck sieht keinen Bedarf die Firmwares ihrer Gehäuse zum download anzubieten, weil Inateck vllt. der Meinung wäre, dass dessen ausgelieferten Modelle nicht upgedated werden müssten, was ntrl. aber doch in einigen Fällen aber einige wirklich praktische Funktionen brächte, bzw. zu großes "Risiko" wegen Umtausch.

Ich würd mal annehmen, dass die ganzen Firmwares von den entsprchenden vrtrauenswürdigen 3rd-party-Webseiten Firmware-Dumps (von Gehäusen wären, die zurück zu roh-Firmwares aufbereitet wurden, sodass sie für alle Gehäuse universal wieder flashbar wären, weil ja beim Flashen einer roh-Firmware mit dem MPTool spezielle-Config-settings mitrein-geflasht werden.
Bzw. Asmedia liefert die Roh-Firmwares, aber nur an die 3rd-party-Hersteller/Verkäufer, an die, die die Komopnenten zusammenbauen. Manche Produktionsfirmen liefern Firmware-Updates für ältere Exemplare auf dessen Webseite nach. Diese gelangen dann mit der Zeit in den Umlauf bei den Dritt-Treiber/firmware webseiten wie "usbdev.ru" oder "station-drivers.com", die universal sammeln, sortieren und zum Download anbieten.
Nicht alle 3rd-party-Produktionsfirmen/Verkäufer bien viel Support in Bezug zu Firmwares. Inateck z.B. meines Wissens eher weniger, also zumindest nicht beim Produkt und Support-Sektion auf der Webseite, vllt. beim Supporrt pr Chat/Email

Ich würde folgendes raten. Bevor du eine andere Firmware flasht, teste erstmal selber ob deine spezielle Firmware "140704a18701" UASP kann. Wenn ja, teste auch noch mit einer SATA-SSD, mit dem TRIM-check-Tool, ob SCSI-Unmap/(TRIM) funktioniert (benötigt ab minimum: Win 8.1 / Win10)

Dann noch kucken, dass das Inateck-Gehäuse die HDD NICHT in den Standby schickt wenn der PC/Laptop nur kurz neu gestartet wird.
Und wenn HDD in Standby geschickt wird, dann zumindest nicht schon nach 5 Minuten.

Standby an/aus oder Standby-Zeit lässt sich einstellen per "as_mp_Tool v0.x.ini". Allerdings muss man dazu die Firmware mit dem Asmedia-MPTool neu flashen oder re-flashen. Da ich deine original-FW "140704a18701" deiner Inateck auch bei "usbdev.ru" nicht finde, müsste man also eine andere Firmware nehmen, wenn man neue Standby-Config neu flashen muss, wenn man den Standby ändern will.
Dies ist aber eher nicht so wichtig, die Original-FW hat vrmtl. sowieso keine extrem-niedrige-Standbyzeit eingestellt.
-
Dann würde ich noch testen, ob optische Laufwerke (DVD/Blu-Ray) von der Firmwar 140704_A1_A9_02 unterstützt werden. Einfach ODD an SATA ran tun und schauen ob es über USB unter Windows erkannt wird im Gerätemanager bei CD-/DVD-/Laufwerke auftaucht:
->Start ->Alle Apps ->Windows-System
->Systemsteuerung (Control Panel)
Rechts-oben Kategorie-Ansicht (Große Symbole) wechseln
->Geräte-Manager (Device-Manager) (ist mehr so'n durchgängig gräuliches Symbol wo das steht und draufklickst)
->CD-/DVD-Laufwerke: Testen ob ODD erkannt wird: Wird das ODD angezeigt?

-

Was bringt der Flash auf FW 141126_A1_EE_82?

HDD-Standby-Proboleme gelöst, vor allem für HDDs mit Haggressiven HDD-Firmware-Standby-timern, ganz extrem bei 2.5" Laptop-HDDs (HDD nacch letzer Aktivität schon nach 8 Sekunden in den Standby !!): Ein Beispiel: Western Digital WD Blue 2,5 Zoll WD10JPVX (1TB).
Die "141126_A1_EE_82" unterbindet diese Problematik

UASP geht, TRIM klappt damit auch mit der der "141126_A1_EE_82",
Optische Laufwerke gehen. Alle anderen Firmwares, die ich probiert habe, können keine ODDs, wenn sie UASP für SSD/HDDs haben.
---
Von den vielen Firmwares, die ich probiert habe, kenne ich nur drei Versionen die TRIM können:

140509_A1_82_40
(+) Im Internet verfügbar
(+) UASP
(+) TRIM
(+) Modelname-passthrough
(-) unterstützt aber leider (K)eine ODDs!
(-) zu kurze HDD-Standby-Zeit-Force-Einstellungen (erzwungen, NICHT regelbar für HDDs am SATA-USB_Gehäuse!)
(-)Asmedia-Firmware, reagiert auch nicht auf neue MPTool-Einstellungen für zu ändernde Standby-Zeiten, selbst wenn man diese 140509_A1_82_40 mit geänderte Config nochmal re-flasht! Reagiert NICHT auf Betriebsystem-HDD-Standby-Einstellungen!

141126_A1_3C_80
(+) UASP
(+) TRIM
(+) Modelname-passthrough
(-) unterstützt aber leider (K)eine ODDs!
(-) NICHT im Internet verfügbar!
(+) HDD-Standby-Passthrough
(-) HDD-Standby-Passthrough problematisch für HDDs mit zu aggressiven HDD-FW-Standby-Timern. zB. APM=128 (=5min.), teils sogar HDD-Modelle mit noch aggressiveren Standby-Timern z.B. 8 Sekunden!
(-) NICHT/Noch NICHT im Internet verfügbar!

141126_A1_EE_82
(+) Im Internet verfügbar
(+) UASP
(+) TRIM
(+) untersützt auch ODDs
(-) benutzt das ältere USB-BOT für ODDs, kein UASP für ODDs (betrifft nur ODDs)
(+) USB-BOT wie bei allen anderen FWs mit ODD-Unterstützung aber auch nötig, wie auch bei anderen USB-Adapter-Chips, egal ob Asmedia oder JMicron etc. )
(+) Zumindest keine aggressiveren Standby-Timer mehr, Standby wird abgeschaltet (erzwzungen)
(+) Standby in der Bridge Chip-Firmware 141126_A1_EE_82 per "as_mp_Tool v0.5.ini" per re-flash ggf. regelbar (erzwingt diese Einstellung bei allen HDDs) => umgeht das Problem bei HDD-Firmwares mit zu aggresiven Timern, wo OS-Einstellungn nicht wirken
(-) Leider kein SSD/HDD/ODD-Modellname-passthrough über USB!
---

Wo sehe ich, ob die FW mit UASP ist?

Nur sehr wenige ASM1153/ASM1153E Firmwares haben kein UASP.
Die allermeisten ASM1153/ASM1153E Firmwares haben UASP, aber sehr viele davon haben dort gewisse Einschränkungen und/oder andere gravierende Nachteile.
D.h. ich würde mich (auch) auf andere Sachen konzentrieren, als nur darauf ob eine Firmware nur UASP könne, sondern auch nach Version gehen, wo noch mehr Features, und keine gravierenden Schwächen mit drin sind.

Um zu testen, dass UASP geht, 4 Bedingungen:
Der USB-Host-Controller muss UASP können, Der USB-Host-Controller-Treiber muss UASP haben, das Bteriebsystem muss UASP unterstützen, der USB-Bridge-Chip und dessen Firmware muss UASP können.
Im MPTool im Config_Setting dialog steht z.B. ob bei einer bereits geflashten Firmware UASP aktiviert wird ("UASP=Yes"). allerdings sieht man das erst im MPTool-Firmware-COnfig-Fenster erst, wenn die Firmware schon drauf geflasht ist.

Neben der Methode im MPtool nachzuschauen, ob die und die Firmware UASP kann, allerdings muss auch hier die Firmware schon geflasht sein, geht das auch so: (Minimum ab Win 8.1, und aufwärts erforderlich):
->Start ->Alle Apps ->Windows-System
->Systemsteuerung (Control Panel)
Rechts-oben Kategorie-Ansicht (Große Symbole) wechseln
->Geräte-Manager (Device-Manager)
Bitte nun SSD oder Festplatte (bitte NICHT ODD!) an SATA-Port der Inateck docken, und SATA-USB-Adapter per USB an PC anschließen
Nun Geräte-Manager sollte ein neuer Eintrag, gar 2 neue auftauchen (wenn UASP an ist):
->Laufwerke
Bei ->Laufwerke muss bei der erkannten SSD/HDD "...SCSI Disk Device" dahinter stehen , wenn UASP aktiv ist.
Es müsste noch ein 2. Eintrag erscheinen: Bei ->Speichercontroller müsste noch ein Eintrag auftauchen: ->"Per USB angeschlossenes SCSI-(UAS)-Massenspeichergerät"
Rechtsklick auf: ->"Per USB angeschlossenes SCSI-(UAS)-Massenspeichergerät"
=>Eigenschaften: ->Details: ->Hardware-IDs : müsste ..."VEN_174C" (Vendor-ID für "Asmedia" und "DEV_55AA" (Device-/Product-ID: für ASM1153/ASM1153E Bridge Chip)vermerkt sein

Wenn du das bei gedockter SSD/HDD findest, dann ist UASP in der FW aktiviert.

 

[Mr.Anon]

hi again @Vincent

I have two more questions for you, in case you can help me one more time.

1) These days I bought a sata extension thinking that the optical drives would work in my dock Sharkoon SATA QUICK PORT XT USB 3.0 with ASMedia ASM1051 but it seems that it is not, is there any solution or is that chipset incompatible?

This screenshot is after flash the firmware 130220_81_F6_02 (provided by sharkoon) to get rid off 4k emulation, since it does not support UASP I thought that the optical drives (ODD) would work, but it is not. Do you know if there is any firmware that supports ODD for this chipset (and NO 4k emulation for HDDs)?

I must say that the same extension cable with the same DVD unit works fine on a Inateck UA1001 with ASMedia ASM1153E and stock firmware 141126a1e820

2) I´m thinking on update my Inateck UA1001 with ASMedia ASM1153E and stock firmware 141126_A1_E8_20 to firmware version 141126_A1_EE_82 to have UASP support for HDD and without losing ODD support via USB-OTP.

I have downloaded this file: asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com).zip

But I don't know if the version of MPTool (2.1.21.5 ¿DeBuG?) is the recommended and the includded as_mp_Tool v0.3.ini configuration is correct or not¿?

I have seen that there is a newer version on usbdev.ru (Asmedia ASM1051 MP Tool v3.6.3.0 with ini v0.5), could you tell me which version I should use and exactly what ini configuration is the best for this firmware and chipset?

thank you very much!!!

 

[Vincent]

Fullquote removed

One thing you could try out, saw this on a WDMY Book 8TB, which had SATA-pin-3 from the SATA-15-pin-power-plug (turned SATA-Pins visible from upper side, the 3rd pin from the left near to the L-angle), https://upload.wikimedia.org/wikipedia/commons/7/7c/SATA_Ports.jpg
Pin3-DevSleep to beactivated on some HDD-firmwares: E.g. from quantity of five WD my Book 8TB USB 3.0 products, with SATA internal HDD, three of them had DevSleep enabled, while the other two have not. covering Pin 3 DevSleep 3.3v on the 15-pin connector, made HDD getting work at PSU. Without insulating pin-3 on the 15pin-plug, HDD did not power on at all.
Maybe this trick works also on ODDs, with that pin3 covering with isolation tape over the pin 3, e.g. with duck-tape (very tiny piece),(covering it the SATA-15-pin-male connector on the SATA-device), on 15-pin the 3rd pin from the left near to the L-angle

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

How to Fix the 3.3V Pin Issue in White Label Disks Shucked from Western Digital 8TB Easystore Drives
"In this video, I show you a Western Digital 8TB Easystore drive that has been shucked. Due to a new SATA specification that allows a 3.3V over the third pin of the power connector to disable the drive, the white label 8TB disk may not work with certain power supplies. I show the symptom and the cause, and I demonstrate two solutions - one using Kapton tape and the other using a Molex-to-SATA power adapter. Warning: some Molex-to-SATA adapters have been known to catch fire! Please do your research before using the solution at 4:03. "
--
But this will probably/might not help, and afaik the HDD samples that used that 3.3V Devsleep, that din'tn work on PSU without covering Pin3, functioned on a SATA-USB-adapter case without covering Pin 3 anyway (tested with ASM1153E product)

So this will probably not help, as your ODD is not working on adapter (using as bypassing 3.3V), unless some ODDs used 3.3V DevSleep-pin, (which afaik they wouldn't - not sure), and only if your ASM105X adapter supported that 3,3 feature, too, like many PC-ATX-PSUs do, only then covering Pin3 would perhaps help
---

But another thing first to try out:
It seems more complicated with ASM1051/1053 as there are much more firmwares released compared to ASm1153/E, so much more to try out. Anyway I found one with ...CDROM..." in filename, so it might support ODDs, but I'm not certain if "100118_00_0A_09_CDROM.bin" doesn't use the disturbing 4k emulation. (I haven't bought ASM105X products to test)

https://www.usbdev.ru/files/asmedia/asmt2105firmware/
Asmedia ASMT-2105 Firmware (ASM1051, ASM1053)
==>http://www.usbdev.ru/?wpfb_dl=4998
Firmware ASMT-2105 [100118_00_0A_09_CDROM.bin] ; 100118_00_0A_09_CDROM.rar; size: 10 337 bytes

Afaik you can use "100118_00_0A_09_CDROM.bin" on MPTool, you took, that you know that worked with your ASM105X product: https://www.usbdev.ru/files/asmedia/asm105mptool/
First check in the MPTool in as_mptool_vx.ini", that in the .ini the VID and PID match to the VID and PID, that is reported in the MPTool-status window of your detected ASM105X.
The MPTools/firmware packages for ASM105X, MTechlerin provided in start post, should be matching one for your ASM105x to flash firmware "100118_00_0A_09_CDROM.bin".
Firmware "100118_00_0A_09_CDROM.bin" copied into MPtool directory, and in "as_mptool_0.x.ini" firmware path adapted.
---

I must say that the same extension cable with the same DVD unit works fine on a Inateck UA1001 with ASMedia ASM1153E and stock firmware 141126a1e820

Yes I've done that myself with SATA-7pin+15pin-(F.->M.)-extension cables, which worked for me, as for you as well at least with the ASM1153/E products.

2) I´m thinking on update my Inateck UA1001 with ASMedia ASM1153E and stock firmware 141126_A1_E8_20 to firmware version 141126_A1_EE_82 to have UASP support for HDD and without losing ODD support via USB-OTP.
I have downloaded this file: asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com).zip

Correct

But I don't know if the version of MPTool (2.1.21.5 ¿DeBuG?) is the recommended and the includded as_mp_Tool v0.3.ini configuration is correct or not¿?

Yes I'd use the included MPTool "MPTool 2.1.21.5 ¿DeBuG" from "asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com).zip. Its .ini is specialised to the ASM1153/E and certainly goes perfectly for this firmware.

I have seen that there is a newer version on usbdev.ru (Asmedia ASM1051 MP Tool v3.6.3.0 with ini v0.5), could you tell me which version I should use and exactly what ini configuration is the best for this firmware and chipset?

Afaik 3.6.3.0 is for ASM1351, so for newer chips than ASM1153E. There are some addional parameter-lines in its ini one some 3.6.30 packages, which don't work for ASM1153E, which don't exist on lower Asmedia-MPtool-Versions.
Just out of interest, I had tested a bit fashing firmware with that 3.6.3.0 version on ASM1153/E, but got a failed flash once and/or it rejected to flash, and so tested removing some incompatible parameter-lines and/or using "as_mp_Tool v0.3.ini" from an ASM1153/E firmware packages from included 2.1.20 MPTool, which made it work on 3.6.3.0.
But I wouldn't take the risk, it won't give you any advantage at all.
Just take the "MPTool 2.1.21.5 ¿DeBuG" from "asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com).zip. I have used that, too, on flashing "141126_A1_EE_82". Its config is adapted on to work on ASM1153E, and goes well.
---
And MPTool 2.1.21.5 ¿DeBuG" is with(out) MPTool-password.
So you don't need to type in any "asmedia" password, the other MPTool-versions use.
---
If you want SSD/HDD/ODD_SN-passthrough activated, before the flashing firmware,
first please open "...\asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com)\Upgrade tools\as_mp_Tool v0.3.ini"
in editor/notepad,
and edit the line:

Scan_HDDSN=0

to

Scan_HDDSN=1

You'd also change the path in the ini to the location where you have extracted the zip, so that MPTool finds the firmware-file:
from this:

fw_binary_name=C:\Users\Administrator\Desktop\ASM1153E Tools for Turning off Sleep Mode\Software\141126_A1_EE_82.bin

to
(e.g. if you have downloaded "asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com).zip into directory
(example) "E:\Kit\Asmedia\ASM1153x\",
and extracted the zip to "E:\Kit\Asmedia\ASM1153x\asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com)"
Example (you download and extraction direcotry might differ)

fw_binary_name=E:\Kit\Asmedia\ASM1153x\asmedia_ASM1153E_ 141126_A1_EE_82(station-drivers.com)\Software\141126_A1_EE_82.bin

Keep in mind, Asmedia MPTools have issues with firmware files in in too long file-paths (even in paths with below 255 digits) and it does not support UNC-networking paths)

Be careful to leave original new-line break in tact. Also sometimes when the MPTool-windows is minimized (to be smaller), sometimes it appears like that there was a line break, but it's not really the case, so when maximizing windows, there's not a line break in place actually.
When the line is long, eg. firnware path is longer,e.g. with minimized MPTool windows it looks as it was 2 lines, but it's not actually (as intended).
---
And this lines, I'd recommend to edit (is not too meaningful, just cosmetical)
from:

manufacturer_string=Ugreen
product_string=Ugreen Storage Device

to

manufacturer_string=asmedia
product_string=ASM1153E

You can choose anything you'd like as name, e.g. Inateck as manufacturer_string and product string eg. UA1001 etc.
The rest of original parameters from "as_mp_Tool v0.3.ini " I'd leave in place, not to change.