AW: NEC/RENESAS USB 3.0 Chip Host Firmware
Hi Philibilli,
du hast dich auch genau an die Anleitung gehalten, also bei "5 Copy OS files after Format" das Häkchen gesetzt und darunter den Pfad zur 7z-Datei angegeben und ansonsten hast du auch alles so eingestellt, wie auf dem Bild zu sehen ist?
4DOS hat nicht direkt was mit dem Booten zu tun. Das ist ein alternativer Befehlsinterpreter, ein Ersatz für command.com. Dass der USB-Stick nicht bootet oder nicht im Boot-Menü deines Boards auftaucht, hat nichts mit 4DOS zu tun. Für das Booten zuständig ist der FreeDOS Kernel (Kernel.sys), auf den der Code im Volume-Boot-Sektor zeigt.
Philibilli schrieb:
Und dass ich bei RMPREPUSB die Option "Boot as HDD (C: 2PTNS)" auswählen müsste.
Das kannst du versuchen. Wichtig ist nur, dass die sonstigen Einstellungen exakt so gemacht werden, wie auf dem Bild. Also auch, dass der Pfad auf die 7z-Datei (dessen Inhalt auf den Stick kopiert werden soll) zeigt und das Häkchen bei "5 Copy OS files after Format" gesetzt ist.
Die Vorgabe, dass keine Häkchen bei "4 Filesystem and Overrides" gesetzt sein sollen, bewirkt, dass der Stick wie eine HDD formatiert wird, also mit MBR und einer Partition. Daher verstehe ich nicht, wieso dieser so formatierte Stick nicht auch wie dein andere als HDD im Boot-Menü auftaucht.
Wo steckst du den Stick den rein? In einen USB-Port des onboard Controllers oder in einen der NEC/Renesas USB3.0 Karte? Von der Karte kannst du nicht booten. Ist vielleicht ein Hub zwischengeschaltet?
Philibilli schrieb:
Und noch was Seltsames:
Bei mir stehen als IDs nur "0" (siehe Anhang).
Das ist in der Tat seltsam. Dann wurden entweder vom Hersteller der Karte keine IDs in der Firmware gespeichert oder ein eventueller Vorbesitzer der Karte, der sie dann zum Händler zurückgeschickt hat, hat ein Firmware-Update versucht und dabei diese Werte gelöscht.
/Edit
Freut mich, dass es doch noch geklappt hat.
Philibilli schrieb:
Kann man denn diesen Schritt der händischen Eingabe der Daten nicht auch automatisieren? Das würde doch einiges Gefahrenpotenzial falscher Eingaben im Keim ersticken.
Leider kann ich die Daten nicht direkt per Skript auslesen. Die Daten werden durch das Aufrufen des Update-Programms mit einem bestimmten Parameter angezeigt. Das Programm stellt diese Daten leider nicht als Variable zu Verfügung. Möglicherweise braucht man die PCI-Adresse bei einer 1-Chip Lösung gar nicht angeben. Vermutlich ist das nur bei einer Mehr-Chip-Lösung unbedingt notwendig. Ich könnte das Skript also so ändern, dass bei einem Chip nur die IDs abgefragt werden. Wobei anscheinend falsch eingegebene IDs gar keine Auswirkungen haben, wie es aussieht.
Ich habe allerdings auch eine andere Idee. Da das Windows-Update-Tool auch Kommandozeilen-Befehle verarbeiten kann, könnte man das Update von Mehr-Chip-Lösungen auch direkt unter Windows in er Konsole ausführen. Das jetzige Skript funktioniert allerdings nicht unter Windows (falls da jemand auf die Idee kommt das auszuprobieren), da die Befehle und die Syntax teilweise anders sind. Ich habe das Skript für die uPD720200/uPD720200A Controller schon dahingehend modifiziert und es funktioniert anscheinend. Die Frage ist nur, ob das manchmal auftretende Hängenbleiben des Update-Prozesses nur durch die GUI (oder die von der GUI aufgerufenen Skripte) verursacht wird.
Philibilli schrieb:
PS: Brauchst du auch irgendwelche Dateien von mir, die ich dir anhängen könnte?
Die Dateien Daten.txt und Log.txt wären super.