ARM Linux und UBoot - Kann ich eine schreibgeschützte MTD beschreibbar machen?

Ich habe mehrere eingebettete Linux-Geräte an Kundenstandorten installiert. Wir haben einen aktualisierten Linux-Kernel, den wir bereit sind, auf diesen Geräten bereitzustellen. Das Problem ist, dass auf diesen Geräten die U-Boot-Argumente so angegeben sind:


bootargs = {....} mtdparts=atmel_nand:16M(kernel)ro,240M(rootfs)

Ich kann also nicht flash_erase, um den Kernel oder U-Boot über SSH zu schreiben, da MTD0 schreibgeschützt ist. Ich kann die U-Boot-Argumente ohne seriellen Zugriff nicht optimieren. Für viele Kunden wäre es extrem umständlich, alle Geräte herunterzunehmen und sie seriell anzuschließen und U-Boot zu unterbrechen, um zu den Bootargs zu gelangen. Gibt es eine Möglichkeit, MTD0 vom Kernel nach dem Laden von ro auf rw zu ändern?

Eine weitere Option könnte darin bestehen, zu prüfen, ob Ihr System die Verwendung von kexec während der Ausführung unterstützen würde, um einen neuen Kernel mit einer anderen Befehlszeile oder Konfiguration zu booten.
@ChrisStratton Das war eine großartige Idee, aber leider ist sie nicht in diesem Kernel implementiert. Ich schaue mir definitiv an, Kexec zu kompilieren und mit dem Upgrade zu verteilen, je nachdem, wie viel damit verbunden wäre.
@ChrisStratton - Ich konnte Kexec nicht zum Laufen bringen - es ist nicht in den Kernel integriert, den ich zu aktualisieren versuche. Ich habe es geschafft, Kexec-Tools zu erstellen, aber offensichtlich funktioniert das nur mit Kexec, wenn es installiert ist. aber angeblich kann man kexec von einem binären vs. eingebauten/modul ausführen? Weißt du etwas darüber?

Antworten (3)

Haben Sie darüber nachgedacht, ein einfaches Kernelmodul zu erstellen, das Sie einfügen können, um die MTD-Partition(en) beschreibbar zu machen? Ich hatte das gleiche Problem und konnte es umgehen, indem ich ein Kernelmodul schrieb. Der Einfachheit halber habe ich einfach weitergemacht und jedes MTD-Gerät beschreibbar gemacht. Grundsätzlich muss das Modul in seiner Init-Funktion so etwas tun:

struct mtd_info *mtd;
int x;
bool keep_going = true;

for (x = 0; keep_going; x++) {
    mtd = get_mtd_device(NULL, x);
    if (!IS_ERR(mtd)) {
        mtd->flags |= MTD_WRITEABLE;
        put_mtd_device(mtd);
    } else {
        keep_going = false;
    }
}

Nachdem ich dieses Modul eingefügt hatte, konnte ich flash_erase und nandwrite erfolgreich verwenden, während ich im Kernel gebootet wurde, während flash_erase mir zuvor sagte: "Fehler 13 (Zugriff verweigert)"

Hier ist ein Kernel-Modul, um genau das zu tun: github.com/mwarning/mtdRW
Eine andere Option, wenn Sie den Kernel ändern können, besteht darin, das MTD_WRITEABLEFlag über sysfs in mtdcore.c verfügbar zu machen. Auf diese Weise können Sie es nach Bedarf umschalten, um das MTD-Gerät schreibgeschützt zu halten.

Eine andere Möglichkeit besteht darin, das (mit u-boot erstellte) Dienstprogramm zu verwenden fw_setenv, um die gespeicherten Umgebungsvariablen von u-boot innerhalb von Linux zu ändern. Das würde einen Neustart erfordern, um mit dem neuen zu laufen bootargs, im Gegensatz zum Laden eines Kernelmoduls, aber das ist viel weniger Arbeit als die Verwendung eines seriellen Kabels. Es ist auch ein nützliches Werkzeug für andere Situationen.

Dokumentation ist hier: https://elinux.org/U-boot_environment_variables_in_linux

Das Wichtigste, was Sie wissen müssen, ist, dass Sie eine Konfigurationsdatei verwenden, um zu wissen, wo u-boot seine Umgebung im nichtflüchtigen Speicher speichert, und sie muss mit dem übereinstimmen, wofür u-boot kompiliert wurde fw_setenv.fw_printenv

Dies könnte in der Tat eine gute Lösung sein, wenn U-Boot eine externe Konfiguration verwendet und der Ort, an dem sie gespeichert ist, beschreibbar ist. Es ist jedoch nicht ungewöhnlich, dass standardmäßig eine kompilierte Konfiguration verwendet wird oder dass Plattformanbieter das Konfigurationssystem hacken und stattdessen im Code konfigurieren ... Aber wenn es funktioniert, ist es vielleicht am einfachsten. Idealerweise würde die Konfiguration dann so zurückgesetzt, dass das Volume nur gelesen wird, nachdem Änderungen vorgenommen wurden.
Das ist wahr. Die verfügbaren Optionen sind sehr spezifisch für Ihr Gerät und Ihre Hardwarekonfiguration.

Die übliche Lösung ist

mount / -o remount,rw
Es ist nicht das Dateisystem, das schreibgeschützt ist, sondern die Implementierung eines Blockgeräts auf dem Flash-Speicher.
ARM Linux und UBoot - Kann ich eine schreibgeschützte MTD beschreibbar machen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v