Embedded Linux Boot-Problem

[... (Gast)]

Ich bin im Moment dabei, mir ein Linux From Scratch für ein ARM9 Board 
zu compilieren. U-Boot schient soweit zu funktionieren. Das rootfs liegt 
im NAND flash und der Kernel auch. Das ist die Ausgabe während des 
Bootvorgangs:

U-Boot 2011.12 (Feb 18 2012 - 23:28:44)<\r><\n>
<\r><\n>
CPU: AT91SAM9G20<\r><\n>
Crystal frequency:   18.432 MHz<\r><\n>
CPU clock        :  396.288 MHz<\r><\n>
Master clock     :  132.096 MHz<\r><\n>
DRAM:  64 MiB<\r><\n>
WARNING: Caches not enabled<\r><\n>
NAND:  128 MiB<\r><\n>
*** Warning - bad CRC, using default environment<\r><\n>
<\r><\n>
In:    serial<\r><\n>
Out:   serial<\r><\n>
Err:   serial<\r><\n>
Net:   macb0<\r><\n>
Warning: failed to set MAC address<\r><\n>
<\r><\n>
Hit any key to stop autoboot:  3 <\b><\b><\b> 2 <\b><\b><\b> 1 <\b><\b><\b> 0 <\r><\n>
<\r><\n>
NAND read: device 0 offset 0xa0000, size 0x400000<\r><\n>
 4194304 bytes read: OK<\r><\n>
## Booting kernel from Legacy Image at 22000000 ...<\r><\n>
   Image Name:   Linux-3.2.4<\r><\n>
   Image Type:   ARM Linux Kernel Image (uncompressed)<\r><\n>
   Data Size:    3782744 Bytes = 3.6 MiB<\r><\n>
   Load Address: 20008000<\r><\n>
   Entry Point:  20008000<\r><\n>
   Verifying Checksum ... OK<\r><\n>
   Loading Kernel Image ... OK<\r><\n>
OK<\r><\n>
<\r><\n>
Starting kernel ...<\r><\n>
<\r><\n>
Uncompressing Linux... done, booting the kernel.<\r><\n>

Weiter geht es nicht. Was kann der Grund sein, das es beim Booten nicht 
mehr weiter geht? Wie kann man das am besten debuggen?

[Oliver J. (skriptkiddy)]

Zeig mal dein Uboot Environment.
Glaube man musste in den bootargs console auf ttyS0 setzen, damit man 
sieht was der Kernel tut.

Gruß Oliver

[... (Gast)]

Das sind die Boot-Optionen:

console=ttyS0,115200
root=/dev/mtdblock5
mtdparts=atmel_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,4M(linux),-(root) rw rootfstype=ubifs

Es könnte vielleicht sein, das ttyS0 nicht der USART ist, wo ich die 
Ausgabe erwarte. Das werde ich noch mal prüfen.

[O. D. (odbs)]

Könnte sein, dass der Kernel seine Meldungen woanders hinschreibt. Mach 
mal printenv in u-boot und poste das Ergebnis. Prüfe auch, ob evtl. eine 
command line fest im Kernel eincompiliert ist.

Ansonsten: Maschinennummer richtig gesetzt? Die ist im Bootloader 
eincompiliert und wird für den Kernel an eine bestimmte Speicherstelle 
geschrieben, wo dieser sie als eine der ersten Aktionen ausliest. Wenn 
die Nummern von Kernel und Bootloader nicht übereinstimmen, hängt es an 
dieser Stelle.

[O. D. (odbs)]

Poste mal die vollständige Ausgabe von printenv. Da oben fehlt noch die 
Zeile, wo die Umgebung tatsächlich an den Kernel weitergegeben wird.

[Werner B. (werner-b)]

Wenn sich ein Linux 3.1-er Kernel booten lässt aber ein 3.2-er nicht, 
könnte es daran liegen, dass schon u-boot den (Level-2) Cache aktiviert. 
Das mögen die 3.2-er Kernel überhaupt nicht, da der Kernel beim Laden 
(also zur Laufzeit) gepatched wird. Das funktioniert bei eingeschaltetem 
Cache nicht.

Ob das beim AT91SAM9G20 auch so ist kann ich nicht sagen. Jedenfalls ist 
es ein Problem bei der Kirkwood Architektur (z.B. Dockstar mit dem 
u-boot von Jeff Doozan)

[... (Gast)]

@Werner
Ich hab bei meinem selbstgeschriebenen ersten Bootloader, der U-Boot vom 
Nand flash liest, den instruction cache aktiviert. Meinst du den 
Instruction oder Data cache?

U-Boot> env print<\r><\n>
baudrate=115200<\r><\n>
bootargs=console=ttyS2,115200 root=/dev/mtdblock5 mtdparts=atmel_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,4M(linux),-(root) rw rootfstype=ubifs<\r><\n>
bootcmd=nand read 0x22000000 0xA0000 0x400000; bootm<\r><\n>
bootdelay=3<\r><\n>
ethact=macb0<\r><\n>
stderr=serial<\r><\n>
stdin=serial<\r><\n>
stdout=serial<\r><\n>
<\r><\n>
Environment size: 318/131067 bytes<\r><\n>
U-Boot>

Das ist die environment von U-Boot. Ich hab bei diesem Versuch mal ttyS2 
probiert, aber da kommt auch keine weitere Ausgabe. Ich hab das serielle 
Kabel an USART2 angeschlossen. (Zählung beginnt ab 0) Gibts da irgendwo 
eine Zuordnung USART <-> ttySx oder ist ttyS0 immer USART0?
Die Zeile "Uncompressing Linux... done, booting the kernel" gehört doch 
schon zum Linux-Kernel, oder? Es gibt bei der Kernelkonfiguration die 
Möglichkeit, eine frühe Konsole einzuschalten. Das hab ich gemacht. Dort 
kann man auch direkt den USART auswählen. Ich vermute mal, das diese 
Ausgabe über diese frühe Konsole geschickt wird.
Ich hab irgendwo noch gelesen, das die Startadresse des Kernel ab 
Version 3 ein Vielfaches von 16MByte sein soll. Weiß da jemand 
genaueres? Ich hab die Startadresse nicht geändert und standardmäßig ist 
die 0x20008000 eingestellt, also kein Vielfaches von 16MByte. Macht es 
überhaupt Sinn, vorn ein paar Byte freizulassen, wenn ich die gar nicht 
selbst benötige?
Kann man beim Kernel irgendwo mehr Debug-Ausgaben einstellen?

[Omega G. (omega)]

Hast du denn im Kernel den richtigen UART Treiber eingebaut?

[O. D. (odbs)]

Deine frühe Konsole musst du noch mit "earlyprintk" in den bootargs 
aktivieren, in dem geposteten environment ist das nicht dabei.

Ja, die Meldung "Uncompressing..." kommt vom Kernel. Deshalb:

Machine ID überprüft? Der Hänger an der Stelle ist dafür typisch!

Auch typisch wäre falsches Speicherlayout. Probier mal, das dem Kernel 
mit "mem=" in den bootargs mitzugeben.

[... (Gast)]

@Oliver
In der Kernelkonfiguration kann ich genau das Board auswählen welches 
ich habe. Da müsste doch die Machine ID auch richtig sein, oder? Wo kann 
ich die überprüfen? Muss die Machine ID auch bei U-Boot irgendwo 
angegeben werden und muss die gleich sein mit der beim Kernel?
Wenn ich das Board und den richtigen Prozessor auswähle, dann müsste 
doch eigentlich auch das Speicherlayout stimmen, oder nicht?

[O. D. (odbs)]

"Müsste". Das ist das Stichwort, das einen immer die meiste Zeit kostet.

Wenn du ein Board von der Stange hast und dieses explizit im Kernel 
unterstützt wird, sollte die Mach ID stimmen. Im U-Boot ist sie auch 
eincompiliert, wenn du es für genau dieses Board konfiguriert und gebaut 
hast. Wenn es ein generischer Build für den Controller, nicht aber für 
das Board war, vielleicht nicht.

Das gilt beides auch entsprechend für das Speicherlayout.

Probier trotzdem mal "mem=", kostet dich ein paar Sekunden, vielleicht 
hilft's.

[... (Gast)]

Bei U-Boot gibts ein "MACH_TYPE_xxx". Muss das gleich sein mit der 
Machine ID beim Kernel? U-Boot hab ich selbst angepasst, da waren nur 
paar kleine Änderungen zu einem bestehenden Board nötig. Der Kernel 
unterstützt das Board direkt.

[O. D. (odbs)]

U-Boot übergibt die Maschinen-ID an den Kernel und der vergleicht es mit 
seinen eincompilierten IDs (können mehrere sein). Wenn der Kernel das 
Board nicht kennt, macht er... nichts.

Sollte dein Problem beheben.

[... (Gast)]

Ich hab die ID bei U-Boot zufällig gewählt. Ja das wär dann vermutlich 
das Problem. Danke.

[... (Gast)]

Also der Kernel bootet jetzt ein Stück weiter und ich seh die Ausgaben, 
habe aber noch ein Problem:

[    0.660000] atmel_nand atmel_nand: No DMA support for NAND access.<\r><\n>
[    0.660000] ONFI flash detected<\r><\n>
[    0.660000] ONFI param page 0 valid<\r><\n>
[    0.670000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron MT29F1G08ABC)<\r><\n>
[    0.680000] Scanning device for bad blocks<\r><\n>
[    0.690000] Bad eraseblock 193 at 0x000001820000<\r><\n>
[    0.740000] 6 cmdlinepart partitions found on MTD device atmel_nand<\r><\n>
[    0.750000] Creating 6 MTD partitions on "atmel_nand":<\r><\n>
[    0.750000] 0x000000000000-0x000000020000 : "bootstrap"<\r><\n>
[    0.760000] ftl_cs: FTL header not found.<\r><\n>
[    0.770000] 0x000000020000-0x000000060000 : "uboot"<\r><\n>
[    0.770000] ftl_cs: FTL header not found.<\r><\n>
[    0.780000] 0x000000060000-0x000000080000 : "env1"<\r><\n>
[    0.780000] ftl_cs: FTL header not found.<\r><\n>
[    0.790000] 0x000000080000-0x0000000a0000 : "env2"<\r><\n>
[    0.790000] ftl_cs: FTL header not found.<\r><\n>
[    0.800000] 0x0000000a0000-0x0000004a0000 : "linux"<\r><\n>
[    0.810000] ftl_cs: FTL header not found.<\r><\n>
[    0.810000] 0x0000004a0000-0x000008000000 : "root"<\r><\n>
[    0.820000] ftl_cs: FTL header not found.<\r><\n>

...

[    1.110000] List of all partitions:<\r><\n>
[    1.120000] 1f00             128 mtdblock0  (driver?)<\r><\n>
[    1.120000] 1f01             256 mtdblock1  (driver?)<\r><\n>
[    1.130000] 1f02             128 mtdblock2  (driver?)<\r><\n>
[    1.130000] 1f03             128 mtdblock3  (driver?)<\r><\n>
[    1.140000] 1f04            4096 mtdblock4  (driver?)<\r><\n>
[    1.140000] 1f05          126336 mtdblock5  (driver?)<\r><\n>
[    1.150000] No filesystem could mount root, tried:  ubifs<\r><\n>
[    1.150000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,5)<\r><\n>

Kann mir jemand sagen, was das mit dem FTL header zu bedeuten hat? Der 
NAND flash wird ja richtig erkannt, also funktioniert der Treiber 
richtig aber bei den Partitionen steht (driver?), das ist doch 
eigentlich nicht gut,oder?