Ich habe Secure Boot auf einem eingebetteten Gerät erfolgreich aktiviert. Das Problem ist, dass der Prozess beim Booten in diesem Modus direkt nach der Zeile hängen bleibt:
Starting kernel ...
sobald U-Boot den Kernel in den Speicher kopiert und einen bootmBefehl ausgegeben hat.
In einem Debugger kann ich feststellen, dass der PC bei einer yieldAnweisung hängen bleibt, auf die eine Zuweisung folgt pc = pc-4– im Wesentlichen also eine Schleife.
Ich habe Linux noch nie auf einem so niedrigen Niveau erwähnt, daher bin ich mir nicht sicher, wo ich mit der Suche beginnen soll. Mir ist jedoch aufgefallen, dass ich das Kernel-Image erfolgreich booten konnte, wenn ich mich nicht im sicheren Modus befand. Daher ist dies möglicherweise eine geeignetere Frage an den Anbieter.
1) Wo finde ich allgemein U-Boot-Diagnoseinformationen zur Ausführungsübergabephase?
2) Ab wann wird die Ausführung vollständig an den Kernel übergeben? Das heißt, wann funktioniert U-Boot nicht mehr?
Antwort1
Möglicherweise können Sie den Speicher der frühen Linux-Drucke mit dem folgenden Verfahren sichern. Die Ursache kann sein, dass der Kernel bootet, aber vor der Initialisierung der Konsole hängen bleibt. Legen Sie die Drucke auch in den Kernel-Einstiegspunkt von uboot und bestätigen Sie, dass die Kontrolle an den Kernel übergeben wird.
Suchen Sie die System.mapDatei. Verwenden Sie den folgenden Befehl, um die log_bufAdresse zu ermitteln:
grep __log_buf System.map
Die Ausgabe lautet etwa wie folgt:
c0352d88 B __log_buf
Führen Sie einen Warmstart der Platine durch (der Inhalt im RAM sollte nicht gelöscht werden).
Erstellen Sie in Uboot einen Speicherauszug des Speichers von __log_buf(c0352d88). Dadurch werden die Kernel-Konsolenausdrucke ausgegeben. So können Sie feststellen, wo der externe Speicherausfall auftritt.
Antwort2
Ich hatte dasselbe Problem und habe eine Lösung gefunden. Das Problem liegt in einem der , der die des u-boot structure fieldspeichert. Das füllt dieses Feld nicht mit der unkomprimierten Größe, die das später zum Ändern der Größe seines verwendet , wodurch das System in einen undefinierten Zustand versetzt wird.sizeuncompressed linux kernel.u-bootlinux kernelstack
Sobald u-bootdie Starting kernel...Meldung gedruckt ist, sollte die nächste Meldung erscheinen, Uncompressing Linux... done, booting the kernelnachdem U-Boot eine Übertragung SMM Handleran den Kernel vorgenommen hat, damit dieser die Ausführung übernimmt. Möglicherweise kernelsucht der Kernel nach diesem Feld. Wenn Sie auf einem x86basierten System arbeiten, erfolgt die Dekomprimierung in den folgenden Dateiverzeichnissen:
arch/x86/boot/uncompressed/head_32.S
arch/x86/boot/uncompressed/piggy.S
Die Lösung besteht darin, das neueste U-Boot zu verwenden, das Sie hier finden:https://github.com/andy-shev/u-boot
Wenn Sie jedoch ein benutzerdefiniertes U-Boot verwenden, müssen Sie nach diesem Feld suchen.
Antwort3
x86? Booten mit earlycon=efifboder earlyprintk=vga. Ich erwähne beides, da es ungefähr zum Zeitpunkt des Commits 69c1f396f25b805aeff08f06d2e992c315ee5b1e eine Änderung von earlyprintk auf earlycon gab.