Ich portiere den aktuellen Linux-Kernel auf ältere vorhandene Hardware wie das i.MX28 EVK-Kit von Freescale und das Karo TX28-Board. Ich möchte einen Teil des NAND FLASH im Dateisystem verwenden („userfs-Partition“ im NAND).
Der erste Schritt besteht in der Verwendung von ubiattach /dev/ubi_ctrl -m 6. Dieser Vorgang versucht, eine Volume-Tabelle zu finden und liest den NAND-Chip, eine Reihe von gpmi_read_page-Vorgängen. Dies führt zu einem DMA-Timeout in start_dma_without_bch_irq (gpmi-nand.c). Das Seltsame ist, dass die ersten read_page-Vorgänge erfolgreich sind. Dann tritt ein Timeout ein.
Der erste Eindruck war, dass es sich um ein Timing-Problem handelte. Das Ändern des NAND-Timings änderte das beobachtete Verhalten nicht. Umfangreiches Debuggen, das sich hauptsächlich auf die Werte in den Registern von GPMI, GPIO und Interrupt Collector konzentrierte, brachte keine Ergebnisse.
Ich habe es geschafft, einige Messverbindungen an den Steuerleitungen des NAND-Chips in der i.MX28 EVK-Platine herzustellen. Mit einem Saleae-(Imitations-)Logikanalysator kann ich eine Anzahl korrekter Transaktionen erkennen (im Bereich von 20, 40, irgendwas). Dann wird ein Lesevorgang eingerichtet, das NAND signalisiert korrekt „bereit“, das GPMI wird aufgefordert, Daten zu lesen, und das GPMI taktet die Daten aus dem NAND aus, aberschlägt fehlum die Chip-Enable-Leitung (low active) einzustellen. Sieht so aus, als ob das GPMI intern nicht mehr richtig funktioniert. Jetzt wird der ISR zum Signalisieren des Endes des Lesevorgangs nicht eingegeben (ich habe die zweite Chip-Enable-Leitung verwendet, um das zu signalisieren, die Debug-Ausgabe erzählt dasselbe). Daher das Timeout. Sieht so aus, als ob das GPMI intern „verwirrt“ ist.
Ich habe überprüft, dass der Pin-Multiplexer für die Chip-Enable-Leitung nach dem Timeout immer noch korrekt ist. Den Debug-Ausgaben zufolge passiert das Gleiche beim Karo TX 28 (keine Messung an den Pins, ich konnte keine Verbindung herstellen).
Ich habe alte Mails zu Problemen mit i.MX23 und zweimaligem Zurücksetzen des GPMI (U-Boot und Linux-Kernel) gesehen, was dazu führte, dass das GPMI hängen blieb. Das Herumspielen mit diesem Fix hat nichts geändert. Das Problem tritt bei Linux-Kernel 5.0.8 und 4.20.7 auf. Soweit ich es beurteilen kann, funktioniert der NAND korrekt, wenn er von U-Boot aus verwendet wird. Ich habe die gleiche Zeiteinstellung wie bei U-Boot ausprobiert, ohne Erfolg.
Beachten Sie auch, dass auf der Karo-Platine ein Samsung NAND verwendet wird, auf dem i.MX28 EVK ein Teil von Spansion. Es scheint also nicht mit dem jeweiligen NAND-Chip zusammenzuhängen. Beachten Sie auch, dass dasselbe beobachtet wird, wenn die NAND-Partition über die Linux-Boot-Befehlszeile in U-Boot angehängt wird.
Die Frage ist, was zu tun ist, um die Grundursache zu finden und eine mögliche Lösung zu finden.
Antwort1
Zuerst habe ich viel debuggt, aber keine Lösung gefunden. Dann wurde mir klar, dass ich eine alte Linux-Version habe, die funktioniert (sie wurde vor Jahren von einem anderen Unternehmen erstellt). Das beweist, dass es sich nicht um ein Hardwareproblem handelt. Auch die Tatsache, dass 2 verschiedene Hardware-Boards das gleiche Problem aufweisen, weist nicht auf ein Hardwareproblem hin. Irgendwann beschloss ich, eine alte Linux-Version auszuprobieren, die der alten funktionierenden Lösung so nahe wie möglich kam. Das zeigte, dass Kernel 3.16.68 mit einem eigenen Build einwandfrei funktionierte. Meine Builds von 5.1.5 und 4.20.7 zeigen das NAND-FLASH-Problem. Weitere Experimente zeigten, dass der letzte funktionierende Kernel 4.16.18 ist, ab 4.17.1 und höher ist das Problem vorhanden. Es scheint, dass zwischenzeitlich die NAND-FLASH-Unterstützung für das Freescale GPMI-Peripheriegerät neu strukturiert wurde. Ich gehe davon aus, dass dies von Freescale getan wurde, um neuere Prozessoren/SOCs zu berücksichtigen. Es sieht so aus, als ob die Unterstützung für die alte Hardware defekt ist. Ich kann nicht sagen, ob dies bei Freescale bekannt ist oder nicht. Es gibt Anzeichen dafür, dass Freescale den alten i.MX28 nicht mehr unterstützt. Wie dem auch sei, jetzt war es an der Zeit, die Unterschiede zu analysieren. Der entscheidende Unterschied scheint ein Funktionsaufruf zur Anpassung der Taktfrequenz des GPMI-Peripheriegeräts zu sein, der hinzugefügt wurde. Aus irgendeinem Grund scheint das GPMI-Peripheriegerät nach dem Auskommentieren dieses einzelnen Aufrufs korrekt mit dem NAND FLASH zu funktionieren. Dieser Code befindet sich in der Datei „drivers/mtd/nand/raw/gpminand/gpmi-lib.c“, Funktion „gpmi_nfc_apply_timings“. Kommentieren Sie einfach den Aufruf von „clk_set_rate“ aus. Zumindest bei mir funktioniert das. Später wurde mir klar, dass es besser wäre, den Aufruf nur zu vermeiden, wenn der Prozessor i.MX28 ist, damit er auch mit späteren Chips funktioniert.
Ich habe nicht analysiert, was clk_set_rate genau macht und wie es aufgerufen werden muss, damit es für alle Prozessoren funktioniert. Ich habe keine andere Hardware und kann das daher nicht überprüfen.