Hallo zusammen
Nach dem erfolgreichen Krimi
Beitrag "Re: Eigenes i.MX6 Board - JTAG läuft. Wie nun weiter mit U-Boot?"
Kommt nun ein zweiter Teil. "Wie weiter mit dem Kernel"
Ich freue mich, wenn ich auch diesesmal wieder zahlreiche Leser und
Leserinnen haben werde.
----
Also
U-Boot und Netzwerk sowie MMC und Uart funktionieren ja inzwischen.
Nun habe ich begonnen mittels Buildroot, einen Kernel zu kompilieren.
Dazu habe ich folgendes Versucht:
1) imx_v6_v7_defconfig verwendet.
zusammen mit meinem Device-Tree vom U-Boot.
Wobei ich doch noch einige Fehler im DT hatte (ungenutzte Verweise etc.)
Diese habe ich korrigiert und dadurch einen 8.2MB grossen Kernel uImage
erhalten.
Diesen habe ich mittels tftp an adresse 0x80200000 geladen und dann
mittels bootm gestartet. Es kommt dann die Meldung "starting kernel..."
und dann nichts mehr.
etwwas googlen und gemerkt, da muss ich noch ein paar Dinge einstellen.
2. Versuch.
Ich habe eine eigene defconfig erstellt. Diese von allen GPU relevanten
dingen befreit und noch folgendes hinzugefügt:
1
CONFIG_DEBUG_LL=y
2
CONFIG_DEBUG_LL_INCLUDE="mach/imx.S"
3
CONFIG_DEBUG_IMXUL_UART=y
4
CONFIG_DEBUG_IMX_UART_PORT=1
Mit menu makeconfig unter kernel die loadaddresse 0x80200000 gesetzt.
Kernel format: uImage with appended DT
Compression: gzip
(weitere Settings im Bild)
Kompiliert....
Ergibt einen 5.2MiB grossen Kernel. Also etwas kleiner. So wie erwartet.
Dann in U-Boot folgendes gesetzt:
## Booting kernel from Legacy Image at 80200000 ...
14
Image Name: Linux-5.1.6
15
Image Type: ARM Linux Kernel Image (uncompressed)
16
Data Size: 5452262 Bytes = 5.2 MiB
17
Load Address: 80200000
18
Entry Point: 80200000
19
Verifying Checksum ... OK
20
Loading Kernel Image ... OK
21
22
Starting kernel ...
Was jedoch interessant zu erwähnen ist ist, dass wenn ich mit GDB die
Ausführung unterbreche sehe ich, dass der PC bei 0xC0822798 steht.
Eigentlich sollte der nach meinem Wissen irgendwo bei 0x8xxxxxx stehen,
also im RAM.
Leider habe ich es bisher nicht geschafft, weitere Informationen zum
Startvorgang herauszubekommen...
Es gäbe ja eigentlich noch eine Community von NXP für solche Anliegen.
Dort muss man aber für jedes neue Thema erst mal ca. 12-24h warten, bis
dieses überhaupt freigeschaltet wurde. Dann für jede Antwort wieder
mehrere Stunden... Zudem habe ich das gefühl, hier sind mehr Experten
unterwegs :)
Vielleicht hat ja jemand wieder einen guten Tipp
Danke :)
Hallo Holger,
möglicherweise kannst Du die eine oder andere Info
aus meinem Thread zum BPi-R2 herausziehen.
Beitrag "Linux Kernel 5.1.1. auf dem BPi-R2"
Habe auch in Deinem Thread (oder Krimi) zum iMX6
gelesen und wider einiges gelernt.
Möglicherweise ist Dir bereits bekannt, dass der Kernel,
je nach dem wie er kompiliert wurde eine, eine
initrd (eine initiale Ramdisk) mit Treibern benötigt
um zu starten.
Auch wird ein DT benötigt, den Du aber möglicherweise
schon im U-Boot konfiguriert hast.
Dieser wird aber von Kernel ja auch separat geladen, so
wie ich das verstehe, muss also auch beim Bootvorgang
ins RAM geladen werden wie das Linux Image und die initrd.
Viel Erfolg
Markus
Markus W. schrieb:> möglicherweise kannst Du die eine oder andere Info> aus meinem Thread zum BPi-R2 herausziehen.
Vielen Dank für den Link
Werde ich mir auf jedenfall anschauen.
Markus W. schrieb:> Habe auch in Deinem Thread (oder Krimi) zum iMX6> gelesen und wider einiges gelernt.
Das freut mich! So war das Ganze noch etwas weniger "umsonst"
Markus W. schrieb:> Möglicherweise ist Dir bereits bekannt, dass der Kernel,> je nach dem wie er kompiliert wurde eine, eine> initrd (eine initiale Ramdisk) mit Treibern benötigt> um zu starten.
Nein, ich hatte da nicht daran gedacht. Jetzt wo du es erwähnst erinnere
ich mich aber an den Begriff. Ich dachte nur, dass vielleicht etwas mehr
als nur "starting kernel..." zu erhalten wäre. Denn bei einigen sieht
das ganze doch etwas anders aus, nachdem sie earlyprintk aktiviert
haben. Ich dachte, mit meiner konfig hätte ich dies.
Hier mal ein Beispiel wo man mehr sieht:
1
Starting kernel ...
2
3
4
5
Uncompressing Linux... done, booting the kernel.
6
7
[ 0.000000] Booting Linux on physical CPU 0x0
8
9
[ 0.000000] Linux version 3.14.28-1.0.0_ga+g91cf351 (Lavanya@FSETBLR1LX035) (gcc version 4.9.1 (GCC) ) #3 SMP PREEMPT Wed Jun 29 16:42:46 IST 2016
[ 0.000000] cma: CMA: reserved 320 MiB at 1c000000
Ich denke, zumindest "uncompressing Linux" müsste ich doch zu sehen
bekommen?
Markus W. schrieb:> Auch wird ein DT benötigt, den Du aber möglicherweise> schon im U-Boot konfiguriert hast.> Dieser wird aber von Kernel ja auch separat geladen, so> wie ich das verstehe, muss also auch beim Bootvorgang> ins RAM geladen werden wie das Linux Image und die initrd.
Dass der DT benötigt wird, wusste ich.
Da ich beim image ausgewählt habe "uImage appended DT" dachte ich, dass
mein DT nun im Image steckt...
Markus W. schrieb:> Viel Erfolg
Vielen Dank :)
Hallo Holger,
so wie ich das verstanden habe, macht es kein
Sinn, dass der DT im Kernel steckt.
Beim Kompilieren des Kernels bringst Du nur dem
Kernel bei einen DT entsprechend lesen zu könne
und diese Infos mittels der entsprechenden Treiber
auch zu nutzen.
Der Sinn vom DT ist ja eben nicht den Kernel immer
wieder kompilieren zu müssen, sondern den DT sagen
wir mal wie ein Addon einbinden zu können um die
darunterliegende Hardware vom Kernel besser und
gezielter ansprechen zu können.
Damit werden die Devicetreiber von ihrer Art universeller
und nicht zu speziell für jede darunterliegende HW.
Ich hoffe das so richtig wiedergegeben zu haben
und bin gerne bereit diese Aussage zu revidieren, wenn
begründete Einwände/Korrekturen hier genannt werden.
Markus
Hallo Holger
du hast doch JTAG. Da kannst du auch den Bootprozess von Linux debuggen
;-) Das geht eigentlich ganz gut wenn man sich darüber bewusst ist das
auch der Kernel ei
Holger K. schrieb:> Was jedoch interessant zu erwähnen ist ist, dass wenn ich mit GDB die> Ausführung unterbreche sehe ich, dass der PC bei 0xC0822798 steht.> Eigentlich sollte der nach meinem Wissen irgendwo bei 0x8xxxxxx stehen,> also im RAM.
Kann sein das dein Kernel schon im virtuellen Adressraum läuft du das
aber nur nicht siehst. Daher die Adresse außerhalb des RAM.
Du bekommst auf jeden Fall Ausgaben auch ohne (init)rootfs wenn der
Kernel richtig konfiguriert ist.
Ich würde an deiner Stelle einen DT nehmen der mit dem Kernel mitkommt
und auf dein Board anpassen. Dann kein uImage sondern ein zImage +
separatem DT image. Und den Kernel auch selber bauen außerhalb von
Buildroot.
Viel fehlt sicher nicht. Hardware läuft ja.
Holger K. schrieb:> Ich denke, zumindest "uncompressing Linux" müsste ich doch zu sehen> bekommen?
Ich glaube, dass du diese Zeile nicht zu sehen bekommst, weil du einen
unkomprimierten Kernel uImage verwendest. zImage ist gepackt. Ich würde
mal probieren den Device Tree nicht an das Image zu hängen sondern per
U-Boot in den RAM zu laden. Die Adresse für den Device Tree kannst du
dann an den Kernel in U-Boot übergeben.
Du kannst auf das uImage auch komplett verzichten, weil das ist Legacy
und nicht mehr nötig.
Dann musst du drei Dateien laden:
- den Kernel selbst (zImage)
- initramfs (das cpio-Teil)
- den Devicetree (FDT).
An welche Adresse du die lädst, ist relativ egal, der Kernel sollte sich
selbst umherschieben können. Wenn er erstmal läuft, ist die MMU aktiv
und physische Adressen sind (bis auf cma) egal.
Starten tust du das Teil mit "bootz", dem du die drei Adressen mitgibst
(Kernel, initramfs, fdt). Wenn du kein initramfs hast, nimmst du "-" als
Adresse. Also "bootz 0x80200000 - 0x80100000" oder so.
Auch ohne initramfs solltest du die Kernel-Meldungen bekommen.
Zumindest, wenn du den Kernel mit "earlyprintk" und ohne "quiet"
benutzt. Wie du festgestellt hast, kommen die Argumente nach "bootargs".
Wenn der Kernel läuft, ist Paging aktiv und der Kernel sollte im oberen
Gigabyte des Adressraums liegen. Dein 0xC....... klingt also korrekt.
Ich tippe mal darauf, dass mindestens die Ausgabe nicht funktioniert.
Als letzten Schritt startet der Kernel "init", und wenn das nicht geht
(mangels initramfs/rootfs), gibt es ein Panic. Das solltest du sehen,
vorher brauchst du eigentlich nicht weitermachen.
Noch ein Nachtrag: Du solltest im Prinzip jeden ARM-Kernel (mit
aktivierten Treibern) booten können, also insbesondere auch die
Distributions-Standardkernel. Genau dafür ist der Devicetree ja mal
eingeführt worden.
Ich war jedenfalls schon sehr oft erfolgreich darin, kaputte Kernel zu
bauen. Ein known-good ist hilfreich, selbst wenn er frühzeitig panic()t.
Moin,
Hab' da schon lange nix mehr gemacht, aber da scheint mir ja recht frueh
schon ordentlich was schief zu gehen. Spontan fallen mir 2 Sachen ein:
* Stimmt die angegebene Konsole?
* Wie schaut das mit dem "uncompressing the Kernel" aus? Kanns sein,
dass der sich beim aufblasen irgendwie selber ueberschreibt?
Gruss
WK
Danke für all eure Antworten.
Markus W. schrieb:> Der Sinn vom DT ist ja eben nicht den Kernel immer> wieder kompilieren zu müssen, sondern den DT sagen> wir mal wie ein Addon einbinden zu können um die> darunterliegende Hardware vom Kernel besser und> gezielter ansprechen zu können.
Da stimme ich dir zu.
Ich dachte nur, dass es für den Entwicklungsprozess praktisch ist, wenn
ich nicht noch ein weiteres File hinzuladen muss.
Μαtthias W. schrieb:> du hast doch JTAG. Da kannst du auch den Bootprozess von Linux debuggen> ;-) Das geht eigentlich ganz gut wenn man sich darüber bewusst ist das> auch der Kernel ei
ei?
Ja, dazu bräuchte ich dann das ELF-File :) meinst du damit, dass der
kernel eigentlich ein elf-file ist?
Μαtthias W. schrieb:> Du bekommst auf jeden Fall Ausgaben auch ohne (init)rootfs wenn der> Kernel richtig konfiguriert ist.
Das klingt ja schonmal gut.
Ich finde es auch etwas merkwürdig, dass da garnichts rauskommt.
Der DT ist ja von einem eval mit gleichem Prozessor kopiert.
Die Pinbelegungen stimmen auch. Die Register für UART sind im Prozessor
ja bereits konfiguriert.
Μαtthias W. schrieb:> Ich würde an deiner Stelle einen DT nehmen der mit dem Kernel mitkommt> und auf dein Board anpassen.
Das hab ich gemacht. DT von einem EVAL genommen und angepasst. Bzw.
eigentlich nur ein paar Dinge entfernt.
Μαtthias W. schrieb:> Viel fehlt sicher nicht. Hardware läuft ja.
Ich hoffe es :)
moep schrieb:> Ich glaube, dass du diese Zeile nicht zu sehen bekommst, weil du einen> unkomprimierten Kernel uImage verwendest. zImage ist gepackt. Ich würde> mal probieren den Device Tree nicht an das Image zu hängen sondern per> U-Boot in den RAM zu laden. Die Adresse für den Device Tree kannst du> dann an den Kernel in U-Boot übergeben.
Ok, werde ich gleich mal versuchen.
S. R. schrieb:> Dann musst du drei Dateien laden:> - den Kernel selbst (zImage)> - initramfs (das cpio-Teil)> - den Devicetree (FDT).
Vielen Dank für deine ausführliche Erklärung. Dies werde ich gleich mal
versuchen.
S. R. schrieb:> Dein 0xC....... klingt also korrekt.> Ich tippe mal darauf, dass mindestens die Ausgabe nicht funktioniert.
Klingt ja schonmal nicht ganz so schlecht.
Dergute W. schrieb:> schon ordentlich was schief zu gehen. Spontan fallen mir 2 Sachen ein:> * Stimmt die angegebene Konsole?> * Wie schaut das mit dem "uncompressing the Kernel" aus? Kanns sein,> dass der sich beim aufblasen irgendwie selber ueberschreibt?
Das ist eine gute frage...
Wobei das uImage aktuell nicht komprimiert ist.
Also ich habe den Kernel nun mit folgenden bootargs getestet:
leider alle ohne Erfolg.
Ich versuche nun noch die variante mit zImage und einzelnen DT.
Ich frage mich, woher ich weiss, wie meine console unter linux
heisst....
Ist CONFIG_EARLY_PRINTK aktiviert?
An welchen Pins des i.MX6ULL ist der UART den du für die Konsole
benutzt?
Was ttymxc0 und was ttymxc1 ist, wird über den Device Tree festgelegt.
ttyS0 ist mit dem Prozessor definitiv falsch. tty1 bringt nur dann
etwas, wenn du ein Display angeschlossen und korrekt im Device Tree
konfiguriert hast.
Wenn sich die CPU schon bei 0xC0822798 tummelt, kannst du das vmlinux in
GDB laden um zu sehen in welcher Funktion sie sich befindet. Man könnte
auch den printk Puffer darüber auslesen.
Guten Morgen.
Vielen Dank für deine Antwort.
Daniel schrieb:> Ist CONFIG_EARLY_PRINTK aktiviert?
Nein... war es natürlich nicht. Wir gleich eingebaut und nochmals
compliliert.
Daniel schrieb:> Was ttymxc0 und was ttymxc1 ist, wird über den Device Tree festgelegt.
Nun, da steht leider nicht wirklich was von tty drinn.
Beim devicetree aus dem eval steht (diesen habe ich übernommen, daher
steht bei mir das gleiche drin. Hab einfach ein paar Devices
rausgenommen):
1
chosen {
2
stdout-path = &uart1;
3
};
4
....
5
&uart1 {
6
pinctrl-names = "default";
7
pinctrl-0 = <&pinctrl_uart1>;
8
status = "okay";
9
};
10
....
11
&iomuxc {
12
pinctrl-names = "default";
13
14
pinctrl_uart1: uart1grp {
15
fsl,pins = <
16
MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
17
MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
18
>;
19
};
20
}
bei einem Raspberry steht z.B. auch
1
&uart0 {
2
pinctrl-names = "default";
3
pinctrl-0 = <&uart0_gpio14>;
4
status = "okay";
5
};
Und trotzdem greift man dann über z.B. tty... darauf zu...
So, hab nun ein neues zImage erstellt.
Diesesmal mit
CONFIG_EARLY_PRINTK
Interessanterweise wurde das Image um ein paar Bytes kleiner.
Aber wirklich nur ca. 200 Bytes.
Habe dann versucht mit folgenden Konfigs zu booten
Daniel schrieb:> Wenn sich die CPU schon bei 0xC0822798 tummelt, kannst du das vmlinux in> GDB laden um zu sehen in welcher Funktion sie sich befindet. Man könnte> auch den printk Puffer darüber auslesen.
Das hört sich interessant an. Wie macht man das genau?
Da gibt es glaube ich noch eine Wissenslücke bei mir...
EDIT:
Hier habe ich noch was gefunden:
https://stackoverflow.com/questions/18994633/how-to-specify-the-device-name-for-uart-in-device-tree-dts-file
Offenbar wird die Serielleschnittstelle zu ttyS0..
Habe jetzt mal die aliase hinzugefügt.
1
aliases {
2
serial1 = &uart1; // becomes /dev/ttyS1
3
};
Müsste nun also ttyS1 sein.
EDIT:
Gerade auch versucht mit ttyS1.
Hoffnungslos... Da kommt einfach nichts auf der konsole raus.
Daniel schrieb:> An welchen Pins des i.MX6ULL ist der UART den du für die Konsole> benutzt?
Die UART ist an den Pins UART1_RX_DATA und UART1_TX_DATA , BALL K16 und
K14
EDIT:
Daniel schrieb:> Man könnte> auch den printk Puffer darüber auslesen.
Hab mal das System.map File angeschaut.
Gemäss diesem Artikel:
https://tinylab.gitbooks.io/elinux/en/dbg_portal/kernel_dbg/Debugging_by_printing/Debugging_by_printing.html
Müsste ich einen printk_buf finden.
Ich finde aber nur trace_array_printk_buf
Ob dies das gleiche ist? vermutlich ja nicht...
Kompiliere den Kernel mit Debug-Symbolen, nimm JTAG und lasse den
Debugger den Backtrace ausrechnen. Sobald Linux die MMU in Betrieb
nimmt, kannst du mit den "Raw"-Adressen nichts mehr anfangen.
An dem Trace kann man aber vielleicht raten, was der Kernel zu tun
versucht. Falls er tatsächlich hängt, würde ich vermuten, dass für
irgendein Subsystem eine Clock nicht aktiviert ist. Der Trace verrät
dann vielleicht, welches.
Edit: Ach, ich sehe gerade, der Vorschlag kam schon. Du kannst das
vmlinux-Image gdb einfach als Argument beim Starten übergeben, dann lädt
es die Symbole von dort. Ich weiß nicht genau, welcher Teil des Ganzen
das virtual/physical Address Mapping macht, aber bei mir hat es zum
Glück einfach so funktioniert ...
Hallo,
da ist einiges durcheinander.
Holger K. schrieb:> Das hab ich gemacht. DT von einem EVAL genommen und angepasst.> Bzw. eigentlich nur ein paar Dinge entfernt.
Es sollte eigentlich reichen, die jeweiligen Devices mit
1
status = "disabled";
zu deaktivieren.
Holger K. schrieb:> So, hab nun ein neues zImage erstellt.> Diesesmal mit>> CONFIG_EARLY_PRINTK
Achtung: "early printk" läuft, bevor die eigentlichen Treiber geladen
sind. Das heißt, weder pinmuxing noch die serielle Schnittstelle sind
aktiv und die DT-Einstellungen sind auch noch nicht geladen.
Deswegen musst du in der Kernel-Konfiguration die zu verwendende
Schnittstelle für early-printk separat konfigurieren und die
Unterstützung auch per Kernel-Argument "earlyprintk" extra einschalten.
Schau mal unter CONFIG_DEBUG_LL und vergleichbar (im menuconfig sollte
das recht eindeutig sein).
Ungefähr so:
Kein Leerzeichen zwischen Device, Komma und Baudrate.
Dann solltest du zumindest etwas sehen, bis der serielle Treiber
übernimmt.
Holger K. schrieb:> Nun, da steht leider nicht wirklich was von tty drinn.
Der Kernel nennt serielle Schnittstellen historisch immer ttyXXXnn,
wobei XXX vom Treiber entschieden wird und nn eine laufende Nummer ist.
Darum heißen USB-Adapter ttyACM (wenn USB-CDC) oder ttyUSB (wenn nicht),
und die klassischen ns16550 heißen ttyS. Dein ttyS0 ist also definitiv
falsch.
Siehe zum Beispiel hier:
http://trac.gateworks.com/wiki/serial> Beim devicetree aus dem eval steht (diesen habe ich übernommen,> daher steht bei mir das gleiche drin. Hab einfach ein paar Devices> rausgenommen):> chosen {> stdout-path = &uart1;> };
Die "chosen"-Node ist etwas speziell. Die Idee ist, dass der Bootloader
diese Node zur Laufzeit aus vom Benutzer eingestellten Dingen erzeugt
(z.B. Bootmenü). Scheint aber nicht üblich zu sein.
In jedem Fall steht dort das Device drin, welches für die Konsole
benutzt werden soll. Du solltest also auch ohne "console=" booten
können.
> pinctrl_uart1: uart1grp {> fsl,pins = <> MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1> MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1> >;> };
Stimmt das bei dir auch? :-)
> Und trotzdem greift man dann über z.B. tty... darauf zu...
Der Devicetree beschreibt die Hardware, nicht das Betriebssystem! Da
steht nicht drin, wie Linux die Devices zu nennen hat, sondern welche es
gibt und wo sie liegen.
> Hier habe ich noch was gefunden:> https://stackoverflow.com/questions/18994633/how-to-specify-the-device-name-for-uart-in-device-tree-dts-file>> Offenbar wird die Serielleschnittstelle zu ttyS0..
Wenn du in den Eintrag schaust, siehst du
1
compatible = "ns16550";
(neben anderen). Das ist der Treiber, der auch auf PCs benutzt wird und
darum heißt es dort ttyS. Bei dir definitiv nicht!
Danke für eure Antworten.
Sven B. schrieb:> Du kannst das> vmlinux-Image gdb einfach als Argument beim Starten übergeben, dann lädt> es die Symbole von dort.
Ok, werde ich mir mal anschauen.
S. R. schrieb:> Es sollte eigentlich reichen, die jeweiligen Devices mit
Danke. das kannte ich noch nicht.
S. R. schrieb:> Achtung: "early printk" läuft, bevor die eigentlichen Treiber geladen> sind. Das heißt, weder pinmuxing noch die serielle Schnittstelle sind> aktiv und die DT-Einstellungen sind auch noch nicht geladen.
Dann sollte dies ja eigentlich gut sein. Denn die Schnittstelle wurde ja
bereits in u-boot korrekt konfiguriert.
S. R. schrieb:> Deswegen musst du in der Kernel-Konfiguration die zu verwendende> Schnittstelle für early-printk separat konfigurieren und die> Unterstützung auch per Kernel-Argument "earlyprintk" extra einschalten.>> Schau mal unter CONFIG_DEBUG_LL und vergleichbar (im menuconfig sollte> das recht eindeutig sein).
Hab ich.
Meine Config sieht so aus:
1
CONFIG_SOC_IMX6UL=y
2
CONFIG_DEBUG_LL=y
3
CONFIG_DEBUG_LL_INCLUDE="mach/imx.S"
4
CONFIG_DEBUG_IMXUL_UART=y
5
CONFIG_DEBUG_IMX_UART_PORT=1
6
CONFIG_EARLY_PRINTK
S. R. schrieb:> setenv bootargs console=ttymxc0,115200n8 earlyprintk
Ich hab jetzt folgendes versucht:
Leider weiterhin ohne erfolg. Nichtmal "uncompressing" bekomme ich zu
sehen.
S. R. schrieb:> Stimmt das bei dir auch? :-)
Wie meinst du das?
Es steht jedenfalls dies bei mir im DT. Und ich verwende ja genau diese
beiden Pins...
S. R. schrieb:> Wenn du in den Eintrag schaust, siehst du compatible = "ns16550";> (neben anderen). Das ist der Treiber, der auch auf PCs benutzt wird und> darum heißt es dort ttyS. Bei dir definitiv nicht!
Stimmt, habs jetzt auch gesehen :)
Ich würde aus dem was du siehst nicht zu viele Rückschlüsse ziehen wie
weit der Kernel tatsächlich kommt im Bootprozess. Der macht relativ
viel, bevor er endlich beschließt, den Ringbuffer auf die serielle
Konsole zu schreiben.
Sven B. schrieb:> Ich würde aus dem was du siehst nicht zu viele Rückschlüsse ziehen wie> weit der Kernel tatsächlich kommt im Bootprozess. Der macht relativ> viel, bevor er endlich beschließt, den Ringbuffer auf die serielle> Konsole zu schreiben.
Das ist wohl richtig, aber das "uncompressing the kernel" kommt ja noch
garnicht vom Kernel, oder? Solange der nicht dekomprimiert ist, kann er
ja eigentlich nicht ausgeführt werden.
Ich würde darauf tippen, dass da irgendwelche Teile des Bootloaders
überschrieben werden und zwar schon beim Laden des Image in den RAM. Und
ab diesem Moment passiert dann einfach nur noch irgendwelcher Unsinn.
Ich würde also erstmal ganz penibel eine memory map von dem Zustand
erstellen, wie er sich direkt vor dem Laden des Kernels darstellt und
dann kontrollieren, dass davon beim Laden des Kernels nix überschrieben
wird.
Holger K. schrieb:> Dann sollte dies ja eigentlich gut sein.> Denn die Schnittstelle wurde ja bereits in u-boot korrekt konfiguriert.
Das sagt nicht viel, weil earlyprintk das (möglicherweise) nochmal tut.
Da müsstest du in die Sourcen schauen.
>> Stimmt das bei dir auch? :-)> Wie meinst du das?> Es steht jedenfalls dies bei mir im DT.> Und ich verwende ja genau diese beiden Pins...
Genau das wollte ich bestätigt haben, wie auch die
CONFIG_DEBUG_LL-Geschichten. :-)
Hast du mal einen fertigen Standardkernel ausprobiert?
Oder zumindest ein unverändertes _defconfig?
log_buf ist ein Pointer auf den Puffer. In log_buf_len steht die Länge
des Puffers. So bei Zeile 280 in kernel/printk/printk.c ist eine
Beschreibung wie der Inhalt des Puffers zu interpretieren ist.
Gibt auch Python-Skripte für GDB, die einem dabei helfen. Siehe
Documentation/dev-tools/gdb-kernel-debugging.rst. Hab ich selbst noch
nie benutzt.
CONFIG_DEBUG_IMX_UART_PORT=1 ist bei den Pins korrekt. Die 1 ist der
UART bei 0x2020000 (siehe arch/arm/include/debug/imx-uart.h).
Mach deinen serial1 Eintrag in /aliases weg. imx6ul.dtsi enthält bereits
serial0 = &uart1. Damit ist ttymxc0 der richtige.
Probier mal earlyprintk=serial statt nur earlyprintk.
Sag mal, wo sagst du U-Boot eigentlich, dass es dem Kernel einen Device
Tree mitgeben soll?
Daniel schrieb:> Sag mal, wo sagst du U-Boot eigentlich, dass es dem Kernel einen Device> Tree mitgeben soll?
Ah, im ersten Post noch nicht, aber seit du bootz benutzt.
Um das "Uncompressing Linux..." zu bekommen, muss
CONFIG_DEBUG_UNCOMPRESS eingeschaltet sein.
c-hater schrieb:> Das ist wohl richtig, aber das "uncompressing the kernel" kommt ja noch> garnicht vom Kernel, oder? Solange der nicht dekomprimiert ist, kann er> ja eigentlich nicht ausgeführt werden.
Sehe ich auch so.
c-hater schrieb:> Ich würde darauf tippen, dass da irgendwelche Teile des Bootloaders> überschrieben werden und zwar schon beim Laden des Image in den RAM. Und> ab diesem Moment passiert dann einfach nur noch irgendwelcher Unsinn.
Also den Bootloader kopiere ich an adresse 0x87800000
Dieser verschiebt sich dann selbst and die relocaddr. Diese ist:
0x8ffb2000
Das zImage lade ich an Adresse 0x80200000.
Da liegen dann ca 250 MBytes dazwischen.
Ich denke mal, das sollte reichen :)
S. R. schrieb:> Holger K. schrieb:>> Dann sollte dies ja eigentlich gut sein.>> Denn die Schnittstelle wurde ja bereits in u-boot korrekt konfiguriert.>> Das sagt nicht viel, weil earlyprintk das (möglicherweise) nochmal tut.> Da müsstest du in die Sourcen schauen.
Etwas weiter oben hiess es aber, dass die Initialisierung nur mit DT
stattfinde. Aber du hast schon recht. Wirklich wissen tut mans erst,
wenn man sich die Sourcen anschaut.
S. R. schrieb:> Genau das wollte ich bestätigt haben, wie auch die> CONFIG_DEBUG_LL-Geschichten. :-)>> Hast du mal einen fertigen Standardkernel ausprobiert?> Oder zumindest ein unverändertes _defconfig?
Ja, ich hab mir mal die imx_v6_v7_defconfig benutzt.
Kernel wird dann zwar etwa 8.5 MByte statt meinen 5 aber am Verhalten
ändert sich nichts.
Kein "decompressing" rein nichts...
Einen bereits fertigen kernel habe ich allerdings noch nicht versucht.
Daniel schrieb:> log_buf ist ein Pointer auf den Puffer. In log_buf_len steht die Länge> des Puffers. So bei Zeile 280 in kernel/printk/printk.c ist eine> Beschreibung wie der Inhalt des Puffers zu interpretieren ist.
Spannend. log_buf hab ich gefunden:
1
c0d17cd8 d log_buf
Daniel schrieb:> Mach deinen serial1 Eintrag in /aliases weg. imx6ul.dtsi enthält bereits> serial0 = &uart1. Damit ist ttymxc0 der richtige.
Stimmt. gut, werde ich entfernen.
Daniel schrieb:> Probier mal earlyprintk=serial statt nur earlyprintk.
hab ich versucht. hat sich nichts geändert.
Daniel schrieb:> Sag mal, wo sagst du U-Boot eigentlich, dass es dem Kernel einen Device> Tree mitgeben soll?
Ich mach das so:
1
tftp 0x80000000 tree.dtb
2
tftp 0x80200000 zImage
3
bootz 0x80200000 - 0x80000000
Dies wurde weiter oben vorgeschlagen.
Daniel schrieb:> Um das "Uncompressing Linux..." zu bekommen, muss> CONFIG_DEBUG_UNCOMPRESS eingeschaltet sein.
Das ist wieder reines Insider-Wissen :)
Darauf muss man erstmal kommen.
Ich werde es gleich mal mit einbinden und den Kernel neu generieren...
Holger K. schrieb:> Etwas weiter oben hiess es aber, dass die Initialisierung nur mit DT> stattfinde. Aber du hast schon recht. Wirklich wissen tut mans erst,> wenn man sich die Sourcen anschaut.
Nun, earlyprintk nutzt eigene, minimale Treiber. Zu dem Zeitpunkt weiß
der Kernel noch nicht, ob es überhaupt einen DT oder serielle
Schnittstellen gibt. Bis alles ordentlich konfiguriert ist (und der
tty-Layer auch läuft), gibt es earlyprintk.
Holger K. schrieb:> c-hater schrieb:>> Das ist wohl richtig, aber das "uncompressing the kernel" kommt ja noch>> garnicht vom Kernel, oder? Solange der nicht dekomprimiert ist, kann er>> ja eigentlich nicht ausgeführt werden.>> Sehe ich auch so.
Es gibt self-decompressing-Kernel. Ich glaube das ist sogar der
Standard. Also doch, das kommt afaik vom Kernel.
Ich würde echt dazu raten den JTAG-Trace zu versuchen. Das hat eine gute
Chance schnell sehr konkrete Hinweise zu geben. Der Rest ist ziemliches
rumgerate ;)
Sven B. schrieb:> Ich würde echt dazu raten den JTAG-Trace zu versuchen. Das hat eine gute> Chance schnell sehr konkrete Hinweise zu geben. Der Rest ist ziemliches> rumgerate ;)
Ok, wie setzte ich diesen ein?
Habe nun DEBUG_Uncompress eingestellt.
Das zImage wurde wieder ein Paar hundert Bytes grösser.
Nun kommt tatsächlich etwas mehr!
Wenn es hängen würde, könntest du einfach den Debugger während die CPU
läuft attachen, den Pfad zum vmlinx-Image als Argument übergeben, und
dann "backtrace" ausführen.
So musst du vermutlich noch einen Breakpoint im entsprechenden Fault
Handler setzen. Wie das geht, weiß ich nicht, lässt sich aber vermutlich
leicht herausfinden.
Sven B. schrieb:> Wenn es hängen würde, könntest du einfach den Debugger während die> CPU> läuft attachen, den Pfad zum vmlinx-Image als Argument übergeben, und> dann "backtrace" ausführen.>> So musst du vermutlich noch einen Breakpoint im entsprechenden Fault> Handler setzen. Wie das geht, weiß ich nicht, lässt sich aber vermutlich> leicht herausfinden.
Der Faulthandler ist ja auch nur eine Adresse..
Das sollte machbar sein.
Aber ich glaube auf der Konsole sehe ich bereits alle relevanten
Register zum Zeitpunkt des Faults.
Einen Data Abort gibts auch mit deaktivierter MMU.
Hat der imx6 im physikalischen Adressmapping Data Abort Bereiche?
Ansonsten wirft die MMU Data Aborts wenn man auf Pages zugreift wo die
Zugriffsrechte nicht ausreichen oder nicht gemapped sind.
Der Data Abort sieht mir aber so aus als wär der noch von uboot.
Also der Abort kommt so früh, dass in der IVT noch die Vectoren von
UBoot stehen.
Leider fehlt die wichtigste Info in diesem Handler.
Nämlich die Adresse an der er lesen/schreiben wollte.
> Leider fehlt die wichtigste Info in diesem Handler.> Nämlich die Adresse an der er lesen/schreiben wollte.
Hä? Steht doch alles da!
Er crasht, weil er versucht auf irgendwas bei 0x43f90040 zuzugreifen.
0x43f90000 ist die Basisadresse eines UARTs beim i.MX25, i.MX31 und
i.MX35.
Hast du in der Kernelconfig die richtige CPU ausgewählt?
Vielleicht sollte ich etwas weiter ausholen:
Den Kram in der "Code" Zeile disassemblieren (und dabei die
Bytereihenfolge umkehren wegen little-endian) ergibt, dass die letzte
Instruktion "str r0, [r1, #64]" war. In r1 steht 0x43f90000. Ich vermute
das Einschalten von CONFIG_EARLY_PRINTK hat dazu geführt, dass er jetzt
crasht bevor die MMU eingeschaltet ist. Deswegen ist pc auch ganz
woanders. Ohne MMU können wir auch davon ausgehen, dass es kein
imprecise data abort war.
Soweit ich das oben herauslese, machst du Änderungen an der Kernelconfig
indem du Zeilen in einer defconfig änderst bzw. hinzufügst. Das ist
keine gute Idee. Auch wenn da CONFIG_DEBUG_IMXUL_UART=y drin steht, kann
es sein, dass andere Konfigurationsoptionen dazu führen, dass das nicht
umgesetzt wird und am Ende CONFIG_DEBUG_IMX25_UART=y oder so gilt. Mach
Änderungen am besten mit "make menuconfig ARCH=arm
CROSS_COMPILE=arm-was-weiß-ich-wie-deine-toolchain-heißt-". Das zeigt
dir nur die Optionen die nicht von anderen Optionen verhindert werden.
Wenn dir eine fehlt, drück / und such (CONFIG_ dabei weglassen). Mit der
Zahl in Klammern kannst du direkt zur Option springen. Es wird dir auch
angezeigt was für Abhängigkeiten die Option hat.
Holger K. schrieb:> Gemäss diesem Forumpost sollte man die BASE-Adresse anpassen:> https://forum.odroid.com/viewtopic.php?t=9128
Warum suchst du in Foren zu Samsung Exynos, wenn du doch einen i.MX6
benutzt? Die absoluten Lowlevel-Dinge (wo ist der RAM, welche Funktionen
müssen im Kernel eingetragen werden, etc.) sind doch völlig anders.
Ich behaupte mal ins Blaue, dass dein Kernel kaputt ist.
Darum mein Vorschlag, einen definitiv funktionierenden Kernel zu nehmen.
Es gibt Debian-Builds für i.MX6-Boards, da kannst du deren Kernel
extrahieren und mit deinem DTB booten. Ob der dann alles kann oder
nicht, ist egal.
Daniel schrieb:> Hast du in der Kernelconfig die richtige CPU ausgewählt?
Meiner Meinung nach, ja.
Hier mal die defconfig
https://pastebin.com/9DTHYjxHDaniel schrieb:> Soweit ich das oben herauslese, machst du Änderungen an der Kernelconfig> indem du Zeilen in einer defconfig änderst bzw. hinzufügst. Das ist> keine gute Idee. Auch wenn da CONFIG_DEBUG_IMXUL_UART=y drin steht, kann> es sein, dass andere Konfigurationsoptionen dazu führen, dass das nicht> umgesetzt wird und am Ende CONFIG_DEBUG_IMX25_UART=y oder so gilt.
Interessant, das wusste ich nicht.
Leider habe ich aber Konfig wie DEBUG_LL so nicht im make menuconfig
gefunden.
S. R. schrieb:> Warum suchst du in Foren zu Samsung Exynos, wenn du doch einen i.MX6> benutzt? Die absoluten Lowlevel-Dinge (wo ist der RAM, welche Funktionen> müssen im Kernel eingetragen werden, etc.) sind doch völlig anders.
Es ging mir darum ein Gefühl dafür zu bekommen, worum es bei dem Thema
überhaupt geht.
S. R. schrieb:> Ich behaupte mal ins Blaue, dass dein Kernel kaputt ist.> Darum mein Vorschlag, einen definitiv funktionierenden Kernel zu nehmen.> Es gibt Debian-Builds für i.MX6-Boards, da kannst du deren Kernel> extrahieren und mit deinem DTB booten. Ob der dann alles kann oder> nicht, ist egal.
Habe ich jetzt versucht.
Habe ein zImage von hier:
https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/i.mx-evaluation-and-development-boards/evaluation-kit-for-the-i.mx-6ull-and-6ulz-applications-processor:MCIMX6ULL-EVK
Da gibts eines für den ULL chip.
Hab das zImage genommen und mit
> Hier mal die defconfig> https://pastebin.com/9DTHYjxH
Joa, wenn man die reinlädt, dann ist CONFIG_DEBUG_IMX31_UART aktiviert
und CONFIG_DEBUG_IMX6UL_UART ist nicht gesetzt. Liegt bestimmt and er
Reihenfolge in der die Optionen in der defconfig stehen. Schalt mal
CONFIG_ARCH_MULTI_V6 aus. Dann kommt der i.MX31 nicht mehr in Frage.
Und bei CONFIG_EARLY_PRINTK fehlt ein =y.
> Leider habe ich aber Konfig wie DEBUG_LL so nicht im make menuconfig> gefunden.
Wenn ich dort nach DEBUG_LL suche, wird mir
Daniel schrieb:> Liegt bestimmt and er Reihenfolge in der die Optionen in der defconfig stehen.
Ach quatsch, da ist ein Tippfehler in CONFIG_DEBUG_IMX6UL_UART. Deswegen
hat kconfig den Default genommen.
Daniel schrieb:> Vielleicht sollte ich etwas weiter ausholen:>> Den Kram in der "Code" Zeile disassemblieren (und dabei die> Bytereihenfolge umkehren wegen little-endian) ergibt, dass die letzte> Instruktion "str r0, [r1, #64]" war.
So weit hab ichs nicht getrieben.
Bei meinen eigenbau Faulthandlern les ich eben die MMU (oder MPU bei M)
aus um direkt an die Adresse zu kommen.
Auch bei nicht aktivierter MMU lässt sich die Data Abort Adresse aus der
MMU auslesen.
Soo. Weiter geht die wilde Fahrt.
Daniel schrieb:> Daniel schrieb:>> Liegt bestimmt and er Reihenfolge in der die Optionen in der defconfig stehen.>> Ach quatsch, da ist ein Tippfehler in CONFIG_DEBUG_IMX6UL_UART. Deswegen> hat kconfig den Default genommen.
Ohh, werde ich gleich mal korrigieren.
Danke für den Hinweis.
Nun steht:
1
CONFIG_SOC_IMX6UL=y
2
CONFIG_DEBUG_LL=y
3
CONFIG_DEBUG_LL_INCLUDE="mach/imx.S"
4
CONFIG_DEBUG_IMX6UL_UART=y
5
CONFIG_DEBUG_IMX_UART_PORT=1
6
CONFIG_DEBUG_UNCOMPRESS=y
7
CONFIG_EARLY_PRINTK=y
Werde berichten, sobald ich das neue image getestet habe.
Jawoll!!!!
Es war der Tippfehler!
nun kommt deutlich mehr:
1
Starting kernel ...
2
3
Uncompressing Linux... done, booting the kernel.
4
5
Error: invalid dtb and unrecognized/unsupported machine ID
Please check your kernel config and/or bootloader.
Aus unbekanntem Grund scheint der Kernel für MX31 gebuildet worden zu
sein.
Daniel schrieb:> Joa, wenn man die reinlädt, dann ist CONFIG_DEBUG_IMX31_UART aktiviert> und CONFIG_DEBUG_IMX6UL_UART ist nicht gesetzt.
Wie hast du die "reingeladen" um zu sehen, was da aktiv ist?
Meinst du damit, bei make menuconfig unter <Load> die defconf angeben?
Daniel schrieb:> Wenn ich dort nach DEBUG_LL suche, wird mir
Wenn ich in make menuconfig von buildroot DEBUG_LL suche, dann erhalte
ich keine Ergebnise. (Siehe Bild).
> Aus unbekanntem Grund scheint der Kernel für MX31 gebuildet worden zu sein.
Das ist nicht das Problem. Er ist auch für den i.MX31 gebaut.
Das Problem ist, dass dein U-Boot keinen Device Tree an Linux übergibt.
r1 muss 0xffffffff und r2 ein Pointer auf dessen Anfang sein.
Statt dessen versucht U-Boot legacy ATAGs zu übergeben (01 00 41 54 =
ATAG_CORE) und benutzt die undefinierte Machine ID 0.
Wurde U-Boot mit eingeschaltetem CONFIG_OF_LIBFDT gebaut?
> Wie hast du die "reingeladen" um zu sehen, was da aktiv ist?
Nach .config kopiert und make olddefconfig gemacht. Danach enthält
.config die komplette Konfiguration.
> Wenn ich in make menuconfig von buildroot DEBUG_LL suche, dann erhalte ich keine
Ergebnise. (Siehe Bild).
Ach du benutzt Buildroot! Das hat noch ein anderes Menü drum herum
gebastelt.
https://stackoverflow.com/questions/1414968/how-do-i-configure-the-linux-kernel-within-buildroot
Holger K. schrieb:> Aus unbekanntem Grund scheint der Kernel> für MX31 gebuildet worden zu sein.
Bevor es Devicetrees gab, wurde jedem Board eine ID zugeordnet
(zentral!), die der Bootloader dem Kernel übergeben hat. Der Kernel
wusste dann, für welche Boards er gebaut wurde und konnte abbrechen,
wenn er das Board nicht kannte. Das war großer Mist.
Mit Devicetrees ist es möglich, einen generischen Kernel für alle Boards
haben zu können. Der Kompatiblität wegen unterstützt der Kernel beides
parallel, in deinem Fall ist dein Board ein "Generic DT based system"
mit der ID 0xffffffff.
Die anderen Boards (Freescale MX31ADS und BugLabs BUGbase) hast du in
der Konfiguration zusätzlich ausgewählt, aber sie spielen für dich keine
Rolle. Du musst ein Devicetree-Blob übergeben.
Wie hast du den Kernel genau gestartet?
Holger K. schrieb:>> Wenn ich dort nach DEBUG_LL suche, wird mir>> Wenn ich in make menuconfig von buildroot DEBUG_LL suche,> dann erhalte ich keine Ergebnise. (Siehe Bild).
Du solltest in der Konfiguration des Kernels suchen, nicht in der
Konfiguration von Buildroot. Das sind verschiedene Dinge, Stichwort
"make kernel-menuconfig".
Daniel schrieb:> Wurde U-Boot mit eingeschaltetem CONFIG_OF_LIBFDT gebaut?
Nein...
Daniel schrieb:> Das Problem ist, dass dein U-Boot keinen Device Tree an Linux übergibt.>> r1 muss 0xffffffff und r2 ein Pointer auf dessen Anfang sein.> Statt dessen versucht U-Boot legacy ATAGs zu übergeben (01 00 41 54 => ATAG_CORE) und benutzt die undefinierte Machine ID 0.Daniel schrieb:> Ach du benutzt Buildroot! Das hat noch ein anderes Menü drum herum> gebastelt.> https://stackoverflow.com/questions/1414968/how-do-i-configure-the-linux-kernel-within-buildroot
Danke für den Link! Jetzt wirds klarer ^^
S. R. schrieb:> Bevor es Devicetrees gab, wurde jedem Board eine ID zugeordnet> (zentral!), die der Bootloader dem Kernel übergeben hat. Der Kernel> wusste dann, für welche Boards er gebaut wurde und konnte abbrechen,> wenn er das Board nicht kannte. Das war großer Mist.>> Mit Devicetrees ist es möglich, einen generischen Kernel für alle Boards> haben zu können. Der Kompatiblität wegen unterstützt der Kernel beides> parallel, in deinem Fall ist dein Board ein "Generic DT based system"> mit der ID 0xffffffff.>> Die anderen Boards (Freescale MX31ADS und BugLabs BUGbase) hast du in> der Konfiguration zusätzlich ausgewählt, aber sie spielen für dich keine> Rolle. Du musst ein Devicetree-Blob übergeben.
Vielen Dank für diese ausführliche Erklärung.
S. R. schrieb:> Wie hast du den Kernel genau gestartet?
mit bootz und dem dtb als adresse
1
Filename 'tree.dtb'.
2
Load address: 0x80000000
3
Loading: ##
4
239.3 KiB/s
5
done
6
Bytes transferred = 22362 (575a hex)
7
=> tftp 0x80200000 zImage
8
Using FEC device
9
TFTP from server 192.168.30.31; our IP address is 192.168.30.41
S. R. schrieb:> Du solltest in der Konfiguration des Kernels suchen, nicht in der> Konfiguration von Buildroot. Das sind verschiedene Dinge, Stichwort> "make kernel-menuconfig".
Danke für den Hinweis. Hat geklappt.
So, u-boot neu erstellt mit CONFIG_OF_LIBFDT und siehe da...
Der Kernel LEEEEBT :)
1
[ 3.007736] (driver?)
2
[ 3.014052] Kernel panic - not syncing: VFS: Unable to mount root fs on unkno wn-block(0,0)
3
[ 3.022651] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
Hier der gesamte Output: https://pastebin.com/0sA2grTY
Er hat aber Panik bekommen ^^
Wohl ddeshalb, weil kein rootfs vorhanden ist.
Nun kopier ich das rootfs mal auf eine SD-Karte...
Gibts hierbei auch noch was zu beachten?
U-Boot erkannte die SD zu einem früheren Zeitpunkt bereits einmal.
Holger K. schrieb:> Er hat aber Panik bekommen ^^> Wohl ddeshalb, weil kein rootfs vorhanden ist.
ja
> Gibts hierbei auch noch was zu beachten?
nicht wirklich
root=/dev/mmcblk0pIrgendwas
Bei einer SD-Karte willst du auch noch rootwait in die bootargs packen.
Holger K. schrieb:> Gibts hierbei auch noch was zu beachten?
Stelle dein Buildroot so ein, dass es dir ein minimales rootfs (mit
Busybox) baut und nutze das als initramfs. Das macht's einfacher.
Daniel schrieb:> nicht wirklich> root=/dev/mmcblk0pIrgendwas> Bei einer SD-Karte willst du auch noch rootwait in die bootargs packen.
Danke. Werde ich versuchen.
S. R. schrieb:> Stelle dein Buildroot so ein, dass es dir ein minimales rootfs (mit> Busybox) baut und nutze das als initramfs. Das macht's einfacher.
Danke. Buildroot erzeugt mir bereits ein rootfs. Lade ich das dann auch
über tftp an eine mehr oder weniger beliebige adresse und übergebe dies
als zweiten parameter an bootz?
Wenn ja, ich hab ein rootfs.ext4 und .ext2
Ist es relevant, welches davon ich kopiere?
Und, muss ich bei den bootargumenten noch etwas ergänzen, wenn ich das
rootfs entsprechend an bootz übergebe?
Danke :)
Holger K. schrieb:> Wenn ja, ich hab ein rootfs.ext4 und .ext2> Ist es relevant, welches davon ich kopiere?
Wenn der Kernel beides kann, nein.
Du könntest in deiner Konfiguration das ext2 auch weglassen.
Holger K. schrieb:> Und, muss ich bei den bootargumenten noch etwas ergänzen,> wenn ich das rootfs entsprechend an bootz übergebe?
Eigentlich nicht. Das "root=..." gilt nicht für initramfs.
Schau aber nach, ob in deinem rootfs auch eine Datei namens "/init"
gibt. Sonst gibt es wieder ein Panic.
S. R. schrieb:> und nutze das als initramfs. Das macht's einfacher.
Ansichtssache. Bei initramfs und initrd muss man beachten, dass
CONFIG_DEVTMPFS_MOUNT keine Wirkung hat und, dass der Kernel nicht
/sbin/init, sondern /init bzw. /linuxrc ausführt.
Holger K. schrieb:> Wenn ja, ich hab ein rootfs.ext4 und .ext2
Damit wäre das eine initrd und keine initramfs. Also muss /linuxrc
existieren, wenn du es nicht auf die SD-Karte spielen willst.
Daniel schrieb:> Damit wäre das eine initrd
Stimmt, ein initramfs ist ein komprimiertes CPIO-Archiv und hat kein
Dateisystem. Du hast vollkommen recht, mein Fehler.
@Holger: Lass dir von buildroot ein initramfs erzeugen. Der kann das.
Danke für eure Antworten
S. R. schrieb:> @Holger: Lass dir von buildroot ein initramfs erzeugen. Der kann das.
Buildroot hat mir ein rootfs.cpio erzeugt.
Leider sagt u-boot immer
Wenn U-Boot mit CONFIG_SUPPORT_RAW_INITRD gebaut wurde, geht es auch
ohne uImage indem man bootz direkt hinter die Adresse der Ramdisk mit
Doppelpunkt davon getrennt (kein Leerzeichen) die Länge der Ramdisk als
hexdezimale Zahl schreibt.
Daniel schrieb:> Wenn U-Boot mit CONFIG_SUPPORT_RAW_INITRD gebaut wurde, geht es auch> ohne uImage indem man bootz direkt hinter die Adresse der Ramdisk mit> Doppelpunkt davon getrennt (kein Leerzeichen) die Länge der Ramdisk als> hexdezimale Zahl schreibt.
Ihr seid echt Experten!
Vielen Dank für deine Erklärung.
Wo lernt man sowas?
Gibts ein gutes Buch dafür?
Hab mir mal dieses hier gekauft:
https://www.amazon.de/Embedded-Linux-Raspberry-mitp-Professional/dp/395845061X
Leider geht dieses nicht annähernd in diese Tiefe.
Wobei aber vieles angeschnitten wird.
Für den Einstieg echt super!
Habs geschafft :)
Hab im Buildroot
Filesystem->cpio the rootfs und create u-boot image aktiviert.
nun das image mit tftp kopiert und siehe da... Linux bootet und lässt
mich mich einloggen :)
Nun ist das ganze ein riesen gebastel...
Aktuell lade ich alle DDR-Register Werte noch mittels JTAG in den imx.
dann wird mit GDB das elf file von u-boot geladen und gestartet. Nun
wird mittels tftp das image gezogen und gestartet...
Eigentlich müsste ich nun die FUSES des imx brennen, damit er
automatisch von der SD-Karte bootet.
Dann müsste ich wohl U-Boot noch in einen SPL aufteilen, welcher dann
das RAM konfiguriert und U-Boot nachlädt.
Im jetzigen Linux wird in der Busybox leider noch kein Ethernet
angezeigt.
Aber hey... Linux läuft schonmal :)
Danke vielmals für alle eure Unterstützung!
Sven B. schrieb:> Also beim imx7 geht das auch ohne Fuses, da kann man an das u-Boot-Image> so eine "Device Configuration Data"-Datei prependen die der ROM dann> lädt.
Stimmt. DCD. Davon hab ich auch schon gelesen.
Meinst du damit, dass der DCD anstelle des SPL die RAM init übernimmt?
Beim i.MX6 konfiguriert man das RAM normalerweise nicht mit dem SPL,
sondern über DCD Werte (siehe Abschnitt 8.7.2 im Reference Manual).
Schau dir mal die *.cfg Dateien an, die bei den anderen i.MX6 Boards im
U-Boot Sourcecode liegen.
Daniel schrieb:> *.cfg Dateien an, die bei den anderen i.MX6 Boards im> U-Boot Sourcecode liegen.
Danke für den Hinweis
Die *.cfg Datei hatte ich bereits für mein Board angepasst und in den
entsprechenden Ordner abgelegt :)
Thread beobachten
Seitenaufteilung abschalten