Zugriff auf CPU-Register während des Zurücksetzens mit DSTREAM & DS5

Das Problem, das ich derzeit habe, besteht darin, dass ich SecureBoot auf einem Gerät testen möchte, ohne einen Satz interner Sicherheitsregister mit berechneten Hash-Informationen dauerhaft zu ändern. Die Dokumentation schlägt vor, dass Sie dazu ein modifiziertes Reset-Konfigurations-Blob laden, sodass die Ausführung beim Booten "angehalten" wird. Dies gibt Ihnen genug Zeit, JTAG zu verwenden, um die relevanten Register einzustellen, bevor Sie die CPU manuell freigeben.

Mein Problem ist jedoch, dass ich, während die CPU zurückgesetzt wird, keine Verbindung zu Registerwerten herstellen und diese lesen kann. Das JTAG-Gerät, das ich verwende, ist der ARM DSTREAM zusammen mit seiner DS5-Entwicklungsumgebung. Während des Zurücksetzens identifiziert das Toolset das Gerät, das "im Zurücksetzen gehalten" werden soll, aber alle Versuche, die Funktion "Speicherbrowser" zu verwenden, liefern keine Ergebnisse.

Dies funktioniert natürlich gut, wenn die CPU zuerst in einem laufenden Zustand ist und ich die Ausführung manuell unterbreche, bevor ich versuche, den Speicher zu lesen.

tl;dr

Können Registerwerte/Speicherinhalte einer CPU über JTAG gelesen werden, wenn der Kern im Reset gehalten wird?

BEARBEITEN

Einige der Besonderheiten bei der Konfiguration des Geräts zum Zurückhalten beim Booten sind sehr spezifisch für dieses Gerät, aber die Kerne werden in einem zurückgesetzten Zustand gehalten, wenn sie aktiviert sind. Als SoC kommt ein QorIQ LS1043A von NXP zum Einsatz. Dieser Chip ist eine Quad-Core-Variante des LS1021, für den es hier einen Anwendungshinweis gibt . Der Verweis auf die Aktivierung des Hold-Off-Zustands wird als Einstellung BOOT_HO = 1 im Reset-Konfigurationswort angegeben.

Alles, was ich sehe, wenn ich versuche, aus dem Speicher zu lesen, während die Kerne zurückgesetzt bleiben, ist Folgendes, unabhängig von der gelesenen Adresse:Geben Sie hier die Bildbeschreibung ein

Die Antwort wird spezifisch für den SoC sein (nicht für den Kern). Es kann sein, dass Sie den Teil explizit auf „Vor dem Zurücksetzen anhalten“ setzen müssen (der dokumentierte Begriff ist wahrscheinlich anders, aber der Trick besteht darin, dass die Debug-Logik nicht zurückgesetzt werden muss, nur der Kern noch nicht gestartet). Bitte verlinken Sie auf Ihre Referenzen, falls diese öffentlich sind.
@SeanHoulihane, Ah. Das macht Sinn. In der Dokumentation heißt es einfach, das Gerät so zu konfigurieren, dass es beim Booten zurückgehalten wird, was ich getan habe. Ich bin mir jedoch nicht sicher, ob die Debug-Hardware nicht zurückgesetzt wurde. Damit dies wie vorgeschlagen funktioniert, sollte es auf jeden Fall so sein.

Antworten (1)

DS-5 unterstützt den Zugriff auf die Prozessorregister, während die Nicht-Debug-Logik des Kerns nach einem Warm-Reset im Reset gehalten wird. Dies ist allgemein im Debug Hardware Configuration Guide beschrieben

Für diesen speziellen Anwendungsfall hängt es davon ab, wie der Startvorgang sequenziert wird, um dies intern zu erreichen, und ob ein Warmstart ausreicht, um den Debug-Zugriff auf generische Weise bereitzustellen. Wenn das hold resetBit gesetzt ist, wird der Prozessorzustand gehalten, nachdem das Zurücksetzen deaktiviert wurde, bis das Bit gelöscht wird.

Förderung eines Details aus den Kommentaren:

Wie sich herausstellte, musste ich DS5 anweisen, den Namespace der Debug-Hardware zu verwenden. Dieser spezielle SoC hatte eine AHB-Schnittstelle, daher wurde der Befehl als solcher vorangestellt. zB AHB_0:<adr>

Ich kann mich ohne Probleme mit der CPU verbinden. Auf der Platine befindet sich eine Reset-Taste, die, wenn sie gedrückt gehalten wird, dazu führt, dass DSTREAM beim Verbinden fehlschlägt und DS5 einen Bericht ausgibt Unable to connect .. hardware failed to initialize. Das Gerät wird nicht zurückgesetzt, sondern nur die Kerne, wie es scheint. Die Debug-Hardware ist zumindest in der Lage, sich mit dem Debugger zu verbinden, wenn sich der Zustand der Debug-Instanz in "verbunden" ändert. Alle vier Kerne zeigen „held in reset“ an. Einmal hier, funktioniert jedoch keiner der Speicherzugriffe in DS5. Nominell wird nur der 0. Kern "laufen", bis der Bootloader ausgeführt wird.
Das Feedback, das ich von DS5 bekomme, ist Unable to read from register CPSR. Target is in reset.
Und Sie können Core0 aus dem Reset nehmen, indem Sie das hold resetBit löschen? Es kann richtig sein, dass auf das CPSR nicht zugegriffen werden kann, d. h. eher ein Kernregister als ein Debug-Register (obwohl auf es über die Debug-Register zugegriffen wird). Breakpoints und ähnliches sollten zugänglich sein, alle 'externen Debug'-Register sind alles, was ich erwarten würde.
Leider kann ich im Hold-Reset keine Register lesen . Es gibt Ereignisregister, die ausdrücklich angeben, dass sie während des Hold-Resets programmierbar sein sollten, aber ich sehe nur einen leeren Speicherbrowser, wenn ich versuche, ihren Inhalt zu lesen. Ich habe meinen Beitrag mit einem Bild aktualisiert.
Entschuldigung - ich habe Cortex-A7 von der Teilenummer erhalten, als ich nachsah, die Steuerung für Cortex-A53 scheint vollständig in den SoC-Energieverwaltungsregistern zu liegen. Dies impliziert, dass DS-5 ein bestimmtes Reset-Skript benötigt, um die richtigen Teile zu aktivieren (und das stimmt mit dem App-Hinweis überein).
Ich verstehe. Können Sie der Dokumentation entnehmen, welche Schritte zum Zurücksetzen in diesen Zustand erforderlich sind? Es ist für mich nicht sofort ersichtlich. Und sorry, der Chip, mit dem ich arbeite, ist ein A53, aber das Dokument ist für einen A7, der sehr ähnlich ist
Ich habe die NXP-Dokumente nicht, und es gibt einen großen Unterschied, nicht nur in den architektonischen Debug-Aspekten, sondern auch in den Suspend/Retention-Funktionen. Ich kann nur sagen, dass sich die Register, die dies beeinflussen, nicht im CPU-Block der Debug-Region befinden werden. Wahrscheinlich gibt es eine dedizierte Debug-Funktion für Peripheriegeräte, ich habe diese auf MCU-Teilen dokumentiert gesehen.
Wollen Sie sagen, dass vor dem Zurücksetzen eine Registerkonfiguration stattfinden muss, damit die Debug-Hardware auf den Speicher zugreifen kann? Wenn nicht, was sehen Sie in der App-Notiz? Es gibt wirklich keinen Einblick in das, was die "CCS"-Konsolensitzung tut - aber eine gewisse Konfiguration, gefolgt von einem Zurücksetzen, um den Zugriff auf das Register zu ermöglichen, erscheint vernünftig.
Wenn ja, haben Sie einen Einblick, welche Debug-Konfigurationsregister für diese Aufgabe nützlich sein könnten?
Ich weiß es nicht genau, aber es muss eine gewisse Kontrolle geben, um dbg_reset zu deaktivieren (was beim Verbinden des Debuggers implizit ist), aber core_reset aktiviert zu lassen. Der App-Hinweis impliziert für mich, dass dies vom Debugger-Init-Skript behandelt wird. Dies wird durch die Tatsache kompliziert, dass alle Kerne unter der Kontrolle des restlichen SoC sowohl takt- als auch stromgesteuert sein können. Typischerweise gibt es eine speicherabgebildete Debug-Schnittstelle zu dieser Steuerung, aber in diesem Bereich ist keine Architektur vorgesehen.
Wenn ich also richtig folge, wären die Schritte, die Debug-Hardware auf irgendeine Weise zu konfigurieren, um Zugriff auf die erforderlichen Register zu haben, gefolgt von einem Soft-Reset, um den PC jedes Kerns auf Null zu setzen?
Das war wirklich hilfreich. Wie sich herausstellte, musste ich DS5 anweisen, den Namespace der Debug-Hardware zu verwenden. Dieser spezielle SoC hatte eine AHB-Schnittstelle, daher wurde der Befehl als solcher vorangestellt. zB AHB_0:<addr>.
Zugriff auf CPU-Register während des Zurücksetzens mit DSTREAM & DS5
AntwortenHierDatenschutz-Bestimmungen1y, 0v