Druckbare Version
@[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]
Wenn wir einmal davon ausgehen das die Flash-Aufteilung gleich ist, da beide Firmware nahezu identisch sind;
Warum am Bootloader basteln - die Firmware wird doch anhand eines Hex-Wertes vom Bootloader identifiziert.
.. Gruß .. Twix ..
Die eigentliche Receiver-Firmware von Next könnte dann wahrscheinlich auch der/die Octagon Bootloader laden und starten, aber in der Firmware oder den Bootloadern wird mit (höchster) Wahrscheinlichkeit irgend eine Prüfroutine sein, die da dann die Funktion verhindert. Flashen lässt sich ja die Next-Firmware auch erstmal nicht mit Hilfe des/der Octagon-Bootloader, wenn ich es richtig verstanden habe. Muss wohl irgendjemand mit einem Test-Receiver von Octagon, der mit einem funktionsfähigen RS-232 Anschluss versehen ist, was versuchen.
Falls jemand einen Octagon-Receiver erstmal mit einem RS-232 Anchluss hat, würde ich da notfalls auch aus den Firmware-Images was extrahieren, wenn derjenige mit dem Test-Receiver nicht selber zutraut. Als erstes sollte man die Oroginal-Bootloader vom Octagon extrahieren (hb da noch nicht geschaut, ob die in den Firmware-Images geeignet ethalten sind), um erstmal das UART-Boot mit diesen Original-Bootloadern zum Funktionieren zu bekommen.
Andere "Hürden" (Prüfroutinen irgendeiner Art, die Hardwarebesonderheiten/-unterschiede prüfen) könnten trotzdem erstmal das Flashen jeder anderen Firmware außer der Original-Firmware verhindern. Ist ja mittlerweile als "Schutz" vor Fremd-Firmware eine übliche Praxis geworden.
Is it possible to convert next machina 3d to Octagon sf 2028?
It could be, if both receivers identical. Look at [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...].
@[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]: schau mal in den Post hier:
[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]
Die Box hat intern zwei serielle Schnittstellen. Die Belegung habe ich mitgepostet.
Weiß ich ja, dass der SF2028 intern die RS-232 hat, da ja die Receiver-Platine die selbe ist wie beim Next Machina 3D, der einen externen RS-232 Anschluss hat. Muss eben mal jemand den internen RS-232 Anschluss des SF2028 an einen Computer hängen und die in einem Terminal-Programm des PCs vielleicht sehbaren Boot-Meldungen posten.
Bleibt noch die Frage: Wo befindet sich der 2-Pin Anschluss/Header für die Aktivierung des UART-Boot Modus vom PNX84xx-Chip? Wenn der UART-Boot Mode aktiv ist, erwartet der PNX84xx-Chip die Ymodem-Übertragung der beiden Bootloader und danach werden diese dann automatisch gestartet. Mehr passiert da erstmal nicht und führt auch nicht zu irgendwelchen Veränderungen im Flash-Speicher. Erst wenn man dann noch einen USB-Stick mit einer flashbaren Firmware MDL-Datei angesteckt hat, wird auch versucht, das zu flashen.
Bevor nicht klar ist, ob man sich im UART-Boot Mode befindet und dieser mit den Original-Bootloadern funktioniert, sollte man aber nicht versuchen, irgendwas zu flashen. Ich bin da eher der vorsichtige Type und rate das auch jedem anderen. Es macht keinen Sinn übereilt was zu versuchen, was noch niemand mit Erfolg gemacht hat.
Hier ist erst mal Schritt 1. Das kommt beim Boot auf dem 2028 auf der internen Seriellen:
Code:Starting Microloader ASM built on 3ì 21 2014 18:13:41...Initializing PLLs...
Initializing Clocks..
Initializing DDR PLLs/Clocks...
Starting Microloader ASM built on 3ì 21 2014 18:13:41...
Initializing PLLs...
Initializing Clocks..
Initializing DDR PLLs/Clocks...
Initializing DDR controller...
Initializing data section...
Initializing stack ptr...
Switching to 'C' code...
Starting Microloader C...
Version: UL 2.10 ...
Found Internal Ethernet PHY on GMAC0....
Initializing VFD...
GCS in ISA MODE
GCS: NAND DEVICE SETUP COMPLETE
NAND: Initialization complete
SecureHeader Check:ssboot image is unsigned...
Toshiba
NAND: UNCORR ECC ERROR!: Probably reading data beyond image length
Setting up default ATAG list...
Jumping to Uboot ...
U-Boot 3.8
DRAM: 512 MB
malloc: Using memory from 0x04200000 to 0x04400000
GCS: Setup In ISA MODE
UART Boot not Supported .....
GCS: NAND DEVICE SETUP COMPLETE
Boot Device: NAND Flash
NAND: 256 MiB
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
*** Warning - bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
Net: lip0
Auf der zweiten Seriellen kommt nichts Relevantes. Ganz am Schluss des Bootvorganges sieht man hier nur "123123123". Das dürfte die Serielle sein, die bei den anderen Modellen nach draußen geführt ist.
Soweit also offenbar erst mal UART Boot not supported. Freie Connectoren auf dem Mainboard: Da ist noch ein 6-poliger Anschluss namens CN101 auf dem Board. Die Anschlüsse laufen unter die CPU. Da könnte das dabei sein. @[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]: Wenn der richtige Jumper gesetzt wäre, was würde im seriellen Log erscheinen?
Guten Abend!
CN101 ?
könnte das nicht eher ein JTag Anschluss sein?
Auf jedenfall schön das diskutiert wird,vieleicht klappt es ja bald mit Fremdsoftware auf dem sf2028!
Danke für den Log. Ja die andere Seriele Schnittstelle wird wohl beim Next für einen CS-Dongle benutzt, wenn ich es richtig verstanden habe.Zitat:
Zitat von maxodil [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]
In den normalen Boot-Logs der Receiver mit PNX84xx-Chip sieht man nicht, dass es den UART-Boot Mode gibt. Wenn der aktiviert ist, sieht man es daran, dass dann über den seriellen Anschluss erstmal gar keine Boot-Meldungen kommen (glaub ich, kann mich nicht mehr recht erinnern und muss mal wider einen PNX84xx-Receiver morgen anschließen), aber ein Ymodem-Datentransfer mit den beiden Bootloadern erwartet wird. Da sieht man dann fortlaufende CCCC... im Terminal-Programm, bis man dann endlich den Ymodem-Datentransfer gestartet hat. Wenn beide Boot-Loader so übertragen wurden, dann werden diese automatisch gestartet, d.h. es wird mit diesen gebootet. Dann kommen auch die üblichen Boot-Meldungen und man kann mit dem üblichen Ablauf eine Firmware z.B. von einem USB-Stick flashen.
Sorry für die etwas verspätete Antwort, war diese Woche im Arbeitsstress.
Auch wenn bis jetzt wohl noch niemand bei den Receivern den UART-Boot Mode hinbekommen hat, es gibt noch andere Möglichkeiten, die man testen kann.
Wann kommt die Meldung "Falsche Version". Ich nehme mal an schon beim Versuch die fremde Firmware im Update-Menü des Receivers zum Flashen verwenden zu wollen. Also bevor überhaupt die Firmware richtig eingelesen wird und versucht wird, diese zu flashen.Zitat:
Zitat von Wolfgang. [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]
Das deutet auf ein Kennzeichen im Header (den ersten paar Bytes der MDL-Datei) hin. Also mall ein paar MDL-Dateien für SF2028 Firmwares unterschiedlicher Version im Hex-Editor ansehen. Da sollten dann in den verschiedenen Versionen konstante Bytes (immer der selbe Wert und wahrscheinlich auch an der selben Stelle) vorhanden sein. Das selbe mal mit ein paar MDL-Dateien für den Next Machina 3D machen. Wenn da in den Firmwares der beiden Receiver an der selben Stelle konstante Bytes nur eben jeweils mit einem anderen Wert vorhanden sind, könnte das das Kennzeichen sein, für welchen Receiver die Firmware gedacht ist.
Da könnte man dann versuchsweise den Wert der SF2028 MDL-Dateien in den Next Machina 3D MLD-Dateien eintragen und sehen, ob dann die Fremdfirmware flashbar ist. Würde ich aber so auf die Schnelle erstmal nicht machen, wenn kein funktionierendes UART-Boot zur Verfügung steht.
Ein Log der Meldungen über RS-232 beim Flashversuch der Fremdfirmware noch ohne (oder wer mutig ist, auch mit verändertem Header) könnte auch hilfreich sein.
hallo,
die FW
2014_06_26_v5030_r2482_SF2028_HD_gall.mdl
2014_07_21_v5040_r2492_SF2028_HD_gall.mdl
2014_08_26_v5063_r2515_SF2028_HD_gall.mdl
unterscheiden sich in den ersten 4096 Bytes lediglich max. in 18 Bytes
[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]
hallo Wolfgang.
Werde wir hier Zeuge deines Meisterstück für eine andere Bessere SW für den 2028.:good::cool:
gruss langer
hallo,
ich denke mal daraus wird wohl nichts :no:
ein Buch lesen ja aber und ein Buch schreiben dazu gehört ein bisschen mehr ;)
hallo
Eine Sehr Treffende Aussage so geht es mir mit dem PC immer noch.
gruss langer
Bei dem Vergleich verschiedener Firmware-Versionen für den selben Receiver geht es mir erstmal nur um die paar Header-Bytes der MDL-Dateien und welche da trotz verschiedener Firmware-Version gleich und nicht unterschiedlich sind. Einen Teil der Header-Bytesl, der unterschiedlich sein kann, hab ich ja schon teilweise in der Beschreibung der Struktur dieser MDL-Dateien beschrieben. Aber in der Beschreibung fehlen eben noch einige Header-Bytes, deren Sinn mir nicht wichtig waren, weil sie mit der eigentlichen Struktur scheinbar keinen sinnvollen Zusammenhang haben.Zitat:
Zitat von Wolfgang. [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]
Wenn ich mal Zeit habe, schau ich mir das mal genauer an, so auf die Schnelle erkenn ich da wenig. Hab für sowas aber wirklich kaum Zeit und selber auch kein besonders gesteigertes Interesse. Die Struktur der MDL-Dateien war mir nur mal vor längerer Zeit wichtig, um die beiden Bootloader und insbesondere die eigentlichen Firmware-Teile für einen ganz anderen Receiver (Golden Media Hypercube) mit dem selben Receiver-Chip extrahieren zu können. Ist aber aus allgemeinem Desinteresse und meiner geringen Freizeit für sowas dann auch im Sand verlaufen.
Insbesondere muss man den "Vergleich" auch mit verschiedenen Firmwares für den Next machen, um erkennen zu können, ob an den selben Byte-Positionen auch dort dann immer konstante, aber zum Octagon verschiedene Byte-Werte vorhanden sind.