Beim iMX8MQ braucht man für das LPDDR4 leider proprietäre firmware (https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin (ist eine Archivdatei)), das stört mich ein wenig. (Wenn man die Nummer in der URL ändert, kann man noch andere Firmwareversionen finden). Jetzt würde ich das gerne reverse-engineeren, und dann durch eigene Firmware ersetzen. Leider hab ich etwas Probleme damit, überhaupt irgendwas darüber rauszufinden. Ich habe versucht, binwalk darüberlaufen zu lassen, das hat aber überhaupt nichts gefunden. Ohne die Architektur zu kennen, kann ich dinge wie Disassemblieren aber ja erstmal komplett vergessen. Ich hab mal versucht, die Häufigkeit der Bytes, normalisiert von 00-FF, ohne die 0 bytes, auszugeben. Ich glaube die Dateien sind nicht komprimiert, die *_dmem.bin Dateien könnten Daten sein, und die *_imem.bin ist vermutlich code, ich hab das oben mal angehängt. Man kann da gewisse Muster sehen, X0 und 0X scheinen häufiger vorzukommen, als die meisten anderen werte, insbesondere 10, 20, 40, 80, C0, E0, F0, FF, 0F, 78, etc. wobei C0 am häufigsten vorkommt. Die Werte erinnern mich sehr an typische Bitmasken. An dem Punkt bin ich jetzt aber etwas hängen geblieben, wie gehe ich nun weiter vor?
Angehängte Dateien:
-
Unbenannt.PNG
20 KB
Hm. Eine Suche nach "iMX8MQ" ergibt als Treffer "i.MX 8 Series Applications Processors | Arm® Cortex®-A72/A53/A35/M4" Das wäre also ein ARM. Ich meine, irgendwoher musst Du doch die Bezeichnung "iMX8MQ"" haben. Wo her? Von einem IC abgelesen? Auf ner Verpackung? Manual? Dann wüsste man, ob die Zuordnung plausibel ist.
Theor schrieb: > Eine Suche nach "iMX8MQ" ergibt als Treffer "i.MX 8 Series > Applications Processors | Arm® Cortex®-A72/A53/A35/M4" > Das wäre also ein ARM. Ja, der Hauptprozessor schon. Aber der DDR-PHY in dem SOC, auf dem der Code läuft, scheint aber was anderes zu sein. Meine Versuche, das als diverse varianten von ARM code zu disassemblieren, haben jedenfalls nichts hervorgebracht, was mir plausibel erschienen wäre. Theor schrieb: > Ich meine, irgendwoher musst Du doch die Bezeichnung "iMX8MQ"" haben. Wo > her? Das ist der SOC, der im L5 Devkit & Phone verbaut ist.
Ein Prozessor extra zur Ansteuerung von RAM klingt etwas kurios... Sicher dass das Programmcode ist, und nicht einfach eine Art Tabelle mit Kalibrations-Daten für das Timing des PHY für verschiedene RAM-Typen? Wie wird diese Datei denn eingesetzt - an eine bestimmte Speicher Stelle geschrieben? Du könntest schauen was NXP sonst noch so an (proprietären?) Architekturen verwendet und schauen ob das ein entsprechender Code ist. Wenn schon wird das was Low-Cost mäßiges sein, 8051 oder sowas. ARM wäre für so ein Helferlein zu teuer...
Ja. Mir kommt es auch wahrscheinlicher vor, dass das Code ist der eine andere PHY-Konfiguration beinhaltet und auf dem ARM läuft. Oder eine Datendatei die vielleicht nur Konfigurationsdaten enthält. Gibts denn keine Angaben dazu, was man mit der Datei anfangen soll? PHYs mit eigenen Prozessor? Hm. IP-Cores kenne ich dafür noch.
Theor schrieb: > und auf dem ARM läuft. Also ARM A32 Code ist das fast sicher nicht. Wenn schon dann T32 oder A64. Welcher i.MX ist das genau? Einer mit ARMv8? Welcher ARM-Kern? DPA schrieb: > Meine Versuche, das als diverse varianten von ARM code zu > disassemblieren, haben jedenfalls nichts hervorgebracht, was mir > plausibel erschienen wäre Zeig mal... Vielleicht wäre es sinnvoll die Datei als großes Integer Array zu interpretieren und darüber Statistiken zu machen (Histogramm und so). Wenn das eine Tabelle ist, sollten sich da Tendenzen erkennen lassen...
Eine Version 5.4 findet man öfters, hier steht eine Beschreibung dazu: https://github.com/Freescale/meta-freescale/blob/master/SCR/SCR-4.1.15-2.0.0.txt Package: firmware-imx-5.4.bin Outgoing License: LA_OPT_BASE_LICENSE v12 March 2016 License Files: COPYING Package Category: BSP Type of content: Binaries Description and comments: BSP firmware - EPDC, SDMA, VPU Release Location: i.MX Yocto Project mirror Origin: Freescale Semiconductor, Inc. (proprietary) Chips & Media, Inc. (proprietary) (BSP = board support package ?) EPDC, SDMA, VPU scheint unterschiedliche Hardware zu sein, die hier bedient wird
Auf dem Programmierer schrieb: > Welcher i.MX ist das genau? Der MQ https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i.mx-applications-processors/i.mx-8-processors/i.mx-8m-family-armcortex-a53-cortex-m4-audio-voice-video:i.MX8M > Einer mit ARMv8? Welcher ARM-Kern? Es hat 4 Arm Cortex-A53, dort drauf läuft U-Boot, wenn der ram initialisiert & die firmware hochgeladen wird. Im moment macht das der U-Boot code alles selbst (https://source.puri.sm/Librem5/uboot-imx/blob/librem5/board/freescale/imx8mq_arm2/ddr/helper.c#L39), früher wurde dafür mal der M4 benutzt (https://source.puri.sm/Librem5/Cortex_M4/blob/master/ddr_loader.c#L49). Ich bin mir aber ziemlich sicher, dass diese den Code nicht selbst ausführen. Programmierer schrieb: > Sicher dass das Programmcode ist, und nicht einfach eine Art Tabelle mit > Kalibrations-Daten für das Timing des PHY für verschiedene RAM-Typen? Die Timingdaten können mit einem Tool von NXP generiert werden, und werden dann in U-Boot gesetzt. Die NXP Firmware muss also was anderes sein. (https://source.puri.sm/Librem5/uboot-imx/blob/librem5/board/purism/librem5_devkit/lpddr4_timing.c) Was mir auch noch aufgefallen ist, einige bytes, insbesondere C0 und 70, scheinen fast immer an ungeraden Offsets aufzutauchen. Ich glaube, was auch immer das ist, kommt in 16bit einheiten.
Wenn das die FW für die Training-Engine ist, die die korrekten Phasenoffsets für die Übernahme der Daten bestimmt, könnte das sonstwas selbstgestricktes sein. Besonders intelligent und umfangreich muss die CPU da nicht sein. Könnte also auch ein 8051 sein ;)
An deiner Stelle würde ich mich zuerst für die folgenden Dateien interessieren.
1 | ./firmware-imx-7.9/firmware/vpu/vpu_fw_imx8_dec.bin |
2 | ./firmware-imx-7.9/firmware/vpu/vpu_fw_imx8_enc.bin |
3 | ./firmware-imx-7.9/firmware/epdc/epdc_ED060XH2C1.fw.nonrestricted |
4 | ./firmware-imx-7.9/firmware/hdmi/cadence/signed_dp_imx8m.bin |
die sind alle excuteable im Gegensatz zu dem Rest. Die *_imem.bin und *_dmem.bin haben laut binwalk eine Entropy von ca. 0.8 das legt den Verdacht nahe da diese Gepackt oder Verschlüsselt sein können. Sollte es ein Schlüssel sein, wirst du nicht drumherum kommen diesen zu Extrairen, woher auch immer. interessant können auch die txt Datein sein, welche dir ein paar Begriffe URLs und schlag Wörter für google liefern könnten um die Firmware mehr zu verstehen.
1 | ./firmware-imx-7.9/firmware/seco/readme.txt |
2 | ./firmware-imx-7.9/SCR-firmware-imx.txt |
imonbln schrieb: > An deiner Stelle würde ich mich zuerst für die folgenden Dateien > interessieren. > ./firmware-imx-7.9/firmware/vpu/vpu_fw_imx8_dec.bin > ./firmware-imx-7.9/firmware/vpu/vpu_fw_imx8_enc.bin > ./firmware-imx-7.9/firmware/epdc/epdc_ED060XH2C1.fw.nonrestricted > ./firmware-imx-7.9/firmware/hdmi/cadence/signed_dp_imx8m.bin Die Dateien verwende ich momentan aber garnicht. Auf den RAM hingegen, kann ich nicht verzichten.
DPA schrieb: > Die Dateien verwende ich momentan aber garnicht. Auf den RAM hingegen, > kann ich nicht verzichten. Und? wie du im Original Post geschrieben hast: DPA schrieb: > Jetzt würde ich das gerne reverse-engineeren, und dann durch eigene > Firmware ersetzen. Leider hab ich etwas Probleme damit, überhaupt > irgendwas darüber rauszufinden. Du brauchst also etwas das, dir Hilft die originale Firmware zu verstehen. Die Entropy der Teile die dich Interessieren deutet an, dass Sie Komprimiert sind oder Verschlüsselt. Diese Dateien welche ich Dir genannt habe, haben A eine Entropy von ca 0.2 und B unterscheiden Sie sich von den anderen dadurch das Sie excuteable sind. Es lohnt sich also hier zu forschen um Erkenntnisse über das gesamt System zu erhalten auch wenn das nicht die Droiden sind die Du suchst. Die alliierten, haben unter anderem die Wetterdaten zum Knacken der Enigma verwendet. (siehe https://de.wikipedia.org/wiki/Enigma_(Maschine)#Entzifferung ) ich kann dir Garantieren, die wollten sicher auch nicht über das Wetter reden, es hat Ihnen aber geholfen an die wichtigen Informationen zu kommen. Deine Aufgabe ist es nun ein Zugang zu den Daten zu finden und deshalb schlage ich vor, jeder Abweichung nachzugehen, bis du genügend Informationen hast um den Teil zu verstehen der Dich interessiert.
imonbln schrieb: > Die Entropy der Teile die dich Interessieren deutet an, dass > Sie Komprimiert sind oder Verschlüsselt. Dann wäre das aber keine besonders gute Komprimierung. Schau dir nur mal das Bild im ersten Post an. Bei verschlüsselten Inhalten, gegzipten Dateien und weissem Rauschen hab ich eine sehr gleichmässige Verteilung, aber bei der Firmwaredatei sieht man da eindeutig muster und bytes die öfter vorkommen. Wenn man nur die geraden oder ungeraden bytes anschaut, wird es sogar noch eindeutiger. > Diese Dateien welche ich Dir genannt habe, haben A eine Entropy von ca > 0.2 und B unterscheiden Sie sich von den anderen dadurch das Sie > excuteable sind. Diese sind aber auch für komplett andere Komponenten. Selbst wenn diese mit dem DDR-PHY interagieren, die Ansteuerung von aussen ist ja kein Geheimnis, da schau ich besser im U-Boot code oder in den Datenblättern nach (wenn ich die mal finde). Ich muss rausfinden, was das Ding intern mit dem Firmwarecode macht, und da hilft es definitiv nichts, wenn ich mir was davon komplett unabhängiges anschaue. Das ist auch nicht wie die Wetterdaten bei der Enigma, die SOC Hersteller kaufen sich die einzelnen Komponenten doch von unterschiedlichen anderen Herstellern ein, und verbinden die dann halt, dadurch sind interne gemeinsamkeiten zwischen diesen dort doch sehr unwahrscheinlich.
1 MByte ist aber schon ordentlich viel für bisschen DDR-PHY training und intialisieren - da ist doch sicher noch mehr drin für irgendwas anderes (möglicherweise also sogar unterschiedliche Architekturen in einem Binary).
Ich habe grade das hier gefunden: https://mntmn.com/reform-irc-logs/2019-04-17.log.html Anscheinend soll es sich demnach um eine ARC ISA handeln.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.