[andreasz]

Ich starte hier dann mal
Aktueller Stand : Kernel.img startet nicht

[orgel]

Herzlich Wilkommen im Forum,

Du bist einer der Glücklichen die ein Rb PI bekommen haben und es testen können. Claus und ich konnten das bisher nur in einer VM Testen. Könntest Du uns auch mitteilen was für Fehlermeldungen beim Start kommen, evtl. ein Foto machen und hier posten. Wenn Du an die Logs kommen würdest wäre das noch besser oder kommt er gar nicht soweit beim starten ?

Gruß
Orgel

[fabian]

Hallo zusammen!

Ich häng mich hier mal dran, da ich auch ein RPi zur Verfügung habe und jetzt auch MLD darauf testen wollte. Wie andreasz schon schrieb startet das angebote Image von der Webseite nicht. Der Bildschirm bleibt einfach schwarz.

Sobald der Bildschirm beim RPI-Boot schwarz bleibt heißt es in der Regel das der Kernel nicht geladen werden kann, d.h. das kernel.img fehlerhaft ist.

Da ich eine funktionierende Openembedded-Umgebung für den RPi hier in Verwendung habe (für diverse andere Programme und u.a. auch OpenPli), konnte ich mittlerweile auch schon diverse funktionierende Kernel-Images bauen. Im wesentlichen basiert halt alles auf den angebotenen RPi-Kernel-Sourcen (https://github.com/raspberrypi/linux) und den aktuellen (wichtig!) Bootloader/Firmware-Files von hier: https://github.com/raspberrypi/firmware/tre...ree/master/boot - Mit diesen muss man keinen "voodoo" mehr beim kernel.img machen, sondern kann einfach die unkomprimierte Kernel-Variante nehmen, die nach dem Kernel-Kompilieren unter ./arch/arm/boot/Image zur Verfügung steht.

Wenn ihr wollt kann ich euch eine funktionierende Kernel-Config von mir zur Verfügung stellen, die ihr dann entsprechend für MLD anpassen könnt. Für die weiteren Tests auf dem RPi stelle ich mich natürlich gerne zur Verfügung.

Gruß
Fabian

[clausmuus]

Hi,

ich bin schon seit einigen Tagen per EMail mit andreasz in Kontackt. Er hat schon einige Kernel für mich getestet, jedoch immer mit dem selben Ergebnis, das die nicht wollen. Ersetzt er hingegen den MLD Kernel gegen den von Debian, so klappt das Starten des Kernels. Es liegt z.Z. also definitiv am Kernel.
Beim letzten Versuch hatte ich die original RPI Sourcen und wie beschrieben die ARM bcmrpi_cutdown_defconfig verwedet. Einzige Abweichung war der hinzugefügte aufs Patch, der jedochnicht aktiviert war. Kompiliert habe ich unter ARM Debian in ner qemu Umgebung.

@fabian,

Du schreibst, es muss der unkomprimierte Kernel genommen werden. Das hatte ich bisher nicht gemacht. Steht das irgendwo beschrieben und ich hab das einfach nur übersehen, oder ist diese Info einfach gut versteckt?

Claus

[clausmuus]

@andreasz,

ich werde gleich den unkomprimierten Kernel unter http://www.minidvblinux.de/download.php?fi....1.9.113_116.gz bereitstellen (die .gz Endung hat nichts zu bedeuten). Magst Du das bitte mit dem Testen.

@fabian,
Du darfst den natürlich auch gerne testen. Die Datei muss lediglich in kernel.img umbenannt werden. Es geht erst mal nur da drumm, ob der Kernel überhaupt akzeptiert wird. Das System wird damit nicht funktionieren und mit ner Kernelparnik enden.

Claus

[fabian]

@clausmuus

Das mit dem umkomprimierten Kernel ist jetzt kein unbedingtes Muss, allerdings hatte ich damit in meiner Umgebung immer wieder Probleme bis ich auf das hier gestoßen bin:

http://elinux.org/RPi_Kernel_Compilation:

Image Generation For Latest Firmware

With the latest firmware (available from https://github.com/raspberrypi/firmware), you no longer need to create an explicit kernel image; you can directly use Image or zImage from the kernel build process as /boot/kernel.img.

Und mit der neuen Firmware klappt es bei mir jedenfalls fast immer mit dem unkomprimierten Kernel-Image.


Ich werde gleich mal deinen neuen Kernel testen mit der neuen Firmware testen und dann berichten...

[fabian]

Juhu  :applaus

Der neue Kernel von dir Claus in Verbindung mit der Firmware aus dem Git funktioniert und bootet! Dann freue ich mich jetzt schon mal auf ein erstes Test-Image

[clausmuus]

Hi,

Danke für die schnelle Antwort. Dann baue ich nun mal den MLD Kernel. Das kann ein/zwei Stunden dauern, je nachdem wie viel neu kompiliert werden muss. Ich sag dann Bescheid sobald der Kernel online steht. Sollte auch der funktionieren, baue ich dann nen neues Image zusammen. Du kannst aber auch einfach das Image von der Website nehmen und brauchst da lediglich den Kernel auszutauschen.

Claus

[clausmuus]

Unter http://www.minidvblinux.de/download.php?fi....1.9.113_117.gz gibt's nun den MLD Kernel. Magst Du den bitte testen. Und magst Du bitte auch noch den http://www.minidvblinux.de/download.php?fi....1.9.113_114.gz Kernel mit der aktuellsten Firmware testen. Ich bin grad nicht ganz sicher welche Firmware ich dazu gepackt habe.

Claus

[fabian]

Habe die Kernel jetzt getestet, leider bislang ohne Erfolg:

  MLD-3.0.1-arm_standard-2012.04.06_46.tgz
  MLD-3.0.1-arm_kernel-3.1.9.113_116.gz
= Blackscreen

  MLD-3.0.1-arm_standard-2012.04.06_46.tgz
  MLD-3.0.1-arm_kernel-3.1.9.113_116.gz
+ aktuelle Git-Firmware
= Kernel-Panic:
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: cannot open root device "(null)" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

  MLD-3.0.1-arm_standard-2012.04.06_46.tgz
  MLD-3.0.1-arm_kernel-3.1.9.113_114.gz
+ aktuelle Git-Firmware
= RPi Farben-Testscreen // kein Boot

  MLD-3.0.1-arm_standard-2012.04.06_46.tgz
  MLD-3.0.1-arm_kernel-3.1.9.113_117.gz
+ aktuelle Git-Firmware
= RPi Farben-Testscreen // kein Boot


Was mir auch nicht klar ist, warum du in der cmdline.txt u.a. "initrd=/boot/initrd" angibst; wo soll die herkommen? Aber auch ohne die cmdline.txt bleiben die Ergebnisse wie oben gleich.

Kann ich noch was testen für dich?
 

[clausmuus]

Hi,

die initrd Angabe wird wohl nicht benötigt, weil die vom rpi nicht ausgewertet wird (soweit ich weiß). Desshalb ist im MLD Kernel die initrd enthalten (einkompiliert).
Die Kernel Panik muss kommen, da beim Debian (oder rpi standart Kernel) Kernel kein Root filesystem vorhanden ist.

Das mit dem RPI Testscreen ist mir nicht ganz klar. Unter welchen Bedingungen wird der angezeigt?

Deine Tests haben auf jedenfall schon mal gezeigt, das die ältere Firmware (vom 1.4.) die ich genommen hatte nicht funktioniert. Da kann man dann ja auch lange fehler suchen, wenn ne defekte Firmware verteilt wird, und das zu ner Zeit, als der RPI schon bei den ersten Usern angekommen sein sollte,...

Ich werd erst heute Abend weiter machen. Nun gehe ich erst mal raus in den Garten.

Claus

[fabian]

Also dieser Farben-Test-Screen kommt beim RaspberryPi-Boot auch wenn z.B. gar kein Kernel vorhanden ist, also d.h. nichts geladen werden kann. Ich glaube das ist seit der neuen Firmware so.

Am "besten" war quasi bislang der Kernel 116, auch wenn dieser nachher logischerweise sein RootFS nicht laden kann. Vielleicht stört irgendeine Kernel-Option in den Versionen 114/117 wieder den Boot.

Ist natürlich schwer rauszubekommen was es jetzt genau ist, da die Debug-Möglichkeiten beim Boot quasi gleich 0 sind .

[clausmuus]

Ich werd als nächstes den 116'er Kernel mit integrierter initrd bauen, aber erst heute Abend.

Claus

[clausmuus]

Ich hab nun mal wieder nen kleines Problem. Ich hab die 116'er und 117'er configs verglichen und musste feststellen, das die sich kaum unterscheiden. Haupt Unterschied ist, dass die 117'er die Initramfs mit einbindet. Aber das sollte doch nicht beim Laden und starten des Kernels stören. Gibt's eventuell ne Begrenzung wie groß der Kernel sein darf?
Könntest Du den Test mit dem 117'er Kernel und der aktuellen Firmware noch einmal wiederholen. Eventuell ist Dir ja auch nur nen Fehler unterlaufen. Andernfalls müsste ich mich in ganz kleinen Schritten an die Fehlerquelle heran tasten,...

Claus

[andreasz]

Ich sollte das Thema hier abonnieren, damit ich in Zukunft auch ne Mail erhalte, wenn hier jemand schreibt :wand