Am Donnerstag, 16. November 2023, 19:13:41 CET schrieb Tobias Schlemmer:
Hallo,
Meine Kristallkugel sagt, dass der SPI-Treiber nicht geladen wird. Nun gibt es zwei Wege, das zu tun: Klassisch oder mit Device tree overlays.
+=1 anu
Entsprechend
(Dort war ich schon.)
sind device tree overlays WIP und nicht überall verhanden. Als erstes müsstest Du also herausfinden, welcher Mechanismus bei Dir zieht.
DT.
Wenn Dein Image overlays hat, Musst Du mindestens 2 Overlays laden spi0 und spidev), damit das Device angelegt wird. Dafür ist U-Boot zuständig. Auf der oben genannten Seite steht, wie man das (theoretisch macht).
genau, danke, ich dachte, dss mir der spi0 Hinweis weiterhilft, Fehlanzeige bisher
Hier noch ein Link zu Overlays: https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html
https://elinux.org/Device_Tree_Reference
Wenn das nicht hilft, würde ich mir an Deiner Stelle mal angucken, wie die U-Boot-Skripte aussehen. Hinweis: U-Boot braucht zum Laden immer einen Binär-Header an der Datei. Also musst Du Skripte immer erst kompilieren, bevor sie geladen werden. Und nur die Skripte, die mit binär-Kauderwelsch anfangen, können überhaupt geladen werden.
In der Richtung scheint was möglich zu sein, Bei uboot finden sich immerhin DTS. Irgendeine alte Distribution (wo es noch funktioniert hat) verwendet tatsächlich .bin und nicht (wie heute) .dtb. file kennt dtd, erkennt aber aber diese .bin nicht.
Außerdem empfehle ich Dir, mal einen Boot-Vorgang auf der seriellen Konsole mitzuloggen. U-Boot-Nachrichten tauchen IMHO in den Logs nicht auf.
Ja, aber was ich an Screenshots sah sagte nur was über "Erfolg" (Misserfolg beim Laden.
Viele Grüße
Tobias
P.S.: Noch ein guide: https://github.com/mykhani/device-tree-guide,
Danke für die Tipps!
Allerdings helfen die nicht so weiter, dass das, was ich möchte, auch klappt. 0.) Userguide Allwinner ist die Theorie (Marx), die Praxis ist Murks (s.u.) 1,) Wenn Armbian für "Platinum-Support" für bestimmte Boards spricht, dann sollte man das ernst nehmen. Mein Teil taucht nicht mal unter "Communitiy Support" auf. 2.) Wenn Leute (mit den gleichen Problemen, man ahnt an deren Fragen, an welcher Stelle der Suche sie gerade sind) sich im Forum melden, werden sie meistens regelrecht bösartig abgewiesen und ohne einen konstruktiven Hinweis wie "macht da und da und so und so weiter". m.M. wissen also die Armbian-Leute um die Problematik, haben keine Lust, da was zu machen, bzw. wissen um den nötigen, großen Aufwand. 3.) Ich habe versucht, erst einmal überhaut festzustellen, was als dtb geladen wird, das per dtc zu einem dts zurück zu bauen, die Sourcen zu vergleichen und dann zu sehen, was sich machen lässt. Da stimmt aber auch gar nichts mit irgendetwas überein, allerhöchstens dass von derselben Sache die Rede ist. (verkürzt:) dtc -Ifs /sys/ .../base dtc -Idtb /sys/.../fdt dtc -Idtb /boot/dtb/... Wenn ich das dann zurück komiliere, kommen mehr Warnungen als Ergebnis. Ich bekomme so den Eindruck, dass Armbian die uboot dts irgenwie selber "überarbeitet", ohne dass man darauf und auch die Toolchain Zugriff hat (s. 2.) Und dann kommen die Feinheiten zum Tragen (phandles, dtc -@ für Symbole). 4.) Ich habe mal angefangen die uboot dts für mein Board per Hand zu "präprozessieren", habe es aber nach gefühlt 100 #includes aufgegeben. 5.) Es ist gut möglich, dass wenn alles auf dts Strecke klappt, der Kernel seine bindings zwischenzeitlich "ergänzt" hat.
Kurz: Man sucht "den" Regenwurm im alten Misthaufen.
Da Du aber Ahnung zu haben scheinst: Ob wir uns mal per BBB (lug-dd) privat sprechen könnten ? Schlag ggf. was in einer PM vor. Vielleicht ergänzt sich da was ... Ich habe übrigens die ganzen Schritte recht sauber dokumentiert, vielleicht wird daraus ja mal ein Vortrag im Club oder anderswo. (z.Z. eher die Kernelseite, da ich dort sehen wollte/will, was von sysfs (falsch) geliefert wird.)
Danke für die Meldung! Bernhard