Anfängerfrage: Eigenen Kernel bauen und installieren

  • Moin und Fr.We !

    Ich habe mir spasseshalber mal einen 3.10..... Kernel im Source geholt und diesen ohne weitere Sachkenntnis kompiliert. Dauert ca 5h wie ich merkte auf dem Pi. Auch mal in die Sourcen reingeschaut und gestaunt was manche so draufhaben an Programmierung. Der Pi Kernel scheint mir ein Sammelsurium diverser Firmen zu sein, u,a, finden sich dort Sourcen bekannter Firmen wie der Chipschmiede Broadcom, Sound Blaster, Nvidia usw. Ist schon Wahnsinn!

    Nun weiter mit der Logik eines Ingenieurs, der neu bei Linux ist aber schon den 8051 1987 programmierte:

    1. Ich habe eine Hardware, den Pi: CPU, GBU, IO's. Wie jeder Rechner hat auch dieser eine Memmap, d.h. die Hardware wird an bestimmte Adressen über den Bus gemapped, wurde zumindest vor 10 Jahren noch so gemacht. Es gibt RAM, einen SD Slot usw. Der ARM hat den AMBA Bus (sowas wie die North/South) Bridge bei Intel, er hat einen Thumb Befehlssatz.
    Ich zumindest muss einem Linker alle diese Infos mitteilen, wo liegt das RAM, wo die IO Hardware usw. Woher soll der das auch wissen?

    Hier mal ein Schema eines embedded systems:

    http://www.cnx-software.com/wp-content/upl…y-Map-Large.png

    Kurz: Der GCC Compiler / Linker MUSS die komplette Architektur des Systems kennen, nicht nur die Mnemonics des Maschinen codes. GCC kann für dverse CPUs Code erzeugen.

    Nun meine Fragen:

    1. Ist der Kernel des RPI speziell für diesen erstellt worden, d.h findet sich darin anderer Sourcecode als in der der offiziellen Linuxversion, die maschinenunabhängig ist? Wenn ja ,muss sich ja jemand der Origkernel genommen haben, der absolut Ahnug hat und diesen auf den RPI angepasst haben. Hätte der RPI 2 Gigs RAM müsste das ja irgendwo stehen, es sei denn Linux findet sowas selbst heraus. Treiber sind einfacher, es gibt nur Block und Zeichentreiber mit genormter Schnittstelle, alles dahinter muss nicht bekannt sein, eine Harddisk wird wie eine SD karte angesprochen aus Sicht des PI, ein UMTS Stick oder ein klappriges Analogmodem..... kein Unterschied. AT Befehle haben sie alle. Das erledigt der spezielle Treiber.

    2. Wenn das RPI Projekt eingestellt wird, weil es morgen etwas schnelleres, besseres usw gibt, ist dann logischerweise auch der Support durch apt-get update und upgrade am Ende?

    3. Wo steht es beschrieben, was die tausend Fragen bedeuten, die während der Kernelkonfiguration gestellt werden? Es funktioniert nicht die alte config.gz einfach in .config auszupacken und umzubenennen, es werden bei make und auch make oldconfig trotzdem alle Fragen nochmal gestellt, die ich einfach mit Return bestätigt habe, keine Ahnung was dann passiert. Er kompiliert durch und eine vmlinuz entsteht nach 5h.

    4. Was passiert bei make oldconfig? Ich möchte eigentlich die aktuelle Konfigration verwenden, weil diese ja passt? Wieso dann wieder die tausend Fragen?

    Vielleicht ha ja mal jemand Zeit etwas darüber zu schreiben, so dass die Basics verständlicher werden und ich vielleicht irgendwann in der Lage bin einen ganz eigenen Kernel zu bauen.

    PS: Übrigens habe ich es geschafft einen Huwai UMTS Stick am PI zum Laufen zu kriegen, mobiles Surfen mit Browser ist möglich.

    Gruss,
    Christian

    Einmal editiert, zuletzt von Superhobel (25. Dezember 2013 um 12:06)

  • Anfängerfrage: Eigenen Kernel bauen und installieren? Schau mal ob du hier fündig wirst!

  • Hallo Christian,

    frohe Weihnachten auch.
    Zunächst mal Hut ab dafür, dass du neu bei Linux bist und mal direkt einen Kernel kompiliert hast. Weiter so!

    Ich kann dir leider nicht auf alle deine Fragen ausreichende Antworten geben, aber zumindest teilweise kann ich es versuchen.
    zu 1.) Es gibt den offiziellen Linuxkernel von Kernel.org. Dort gibts Doku und jede Menge Infos zu der Kernelentwicklung. Es gibt eine Mailingliste, über die sich die Kernelentwickler austauschen und bei der man allerhand über den Weg des Kernels vorab lesen kann. ABER: Das ist der offizielle Kernel von kernel.org. Jede Linux Distribution, egal ob Suse, Arch, Fedora, Centos bringt mehrere eigene Kernelversionen mit, die für verschiedene Szenarien "voroptimiert" sind. Dies bedeutet, dass der Sourcecode von kernel.org evtl. mit Distributions-eigenen Dingen erweitert wurde bzw. evtl auch gekürzt wurde und kompiliert wurde. Somit: ja, der Kernel des RPI ist für diesen gemacht worden, von jemand, der Ahnung hat. Die RAM Informationen sind nicht im Kernel verankert, die erkennt Linux von selbst.
    zu 2.) apt-get und Konsorten sind Befehle, die von dem Paketmanagement deiner Distribution kommen. Vermutlich nutzt du Raspbian. apt-get stammt aus der Debian Welt, Raspbian ist wie z.B. Ubuntu auch ein Kind davon. Andere Distributionen nutzen andere Mechanismen (Arch z.B. pacman, Suse ist rpm basiert...). Somit ist es egal, was mit dem RPI Projekt passiert, es kommt nur darauf an, eine Distribution zu finden, die hinreichend lange weitergeführt für den RPI auch wenn es mal keine RPIs mehr geben sollte.
    zu 3.) findest du auf kernel.org, evtl auch auf kernelnewbies.org
    zu 4.) keine Ahnung, aber vermutlich führt 3.) dich zur Antwort.

    In diesem Sinne frohe Weihnachten und fröhliches Kompilieren
    Steffen

  • Hallo,

    ich habe mich heute den Tag über etwas in die Materie eingelesen, bevor die Arbeit bald wieder ruft und die zeit knapp
    wird. Da ich nur 5h-6h schlafen muss ist das ganz praktisch auch nachts zu arbeiten :)

    Kernels and Hardware anpassen ist nur etwas für "Kernel-Hacker" und davon gibt es nicht viele und die meisten sind das
    auch hauptberuflich bei irgendwelchen Distributoren. An der Uni wo der RP entwickelt wurde sind genug Experten zusammen
    die das können. Den Kernel von kernel. org braucht man gar nicht erst anzufassen für den RP, funktioniert nicht, zumindest
    nicht ohne tausend Einstellungen. Die Raspberry CPU ist j keine reine ARM CPU, die gibt es nämlich gar nicht. sondern der ARM
    ist nur ein Softcore der lizensiert wird und meist wird er an etwas drangepappt, hier zb die GBU, die von Broadcom entwickelt wurde
    und deren Leistungsfähigkeit weit über der des ARM liegt. Die würde sogar reichen um Bitcoins zu minen :)
    Dazu noch I2C Interfaces, SPI, Timer, IRQ Controller, L1, L2 Cache usw. usw. Erst so entsteht ein SoC System. Nur muss der Kernel es ja
    wissen, womit er zusammen arbeiten muss. Wo liegt die I2C Schnittstelle, welches sind ihre Register usw usw.

    Was bleibt und was machbar ist, ist den RP Kernel neu zu komplieren und durch die vielen Fragen Funktionen zu entfernen
    oder dazu zu basteln. Zb ein Touchdisplay. Dazu gibt es kernel Konfiguratoren mit GUI. Auch das Kompiliren auf einem PC
    ist keine Hexerei, wenn man weiss wie man die Einstellungen für den Cross Compiler machen muss. Ich installiere bisher mit
    modprobe das nach was ich brauche aber es wird eben dann erst geladen und ist nicht im Kernel mit drin. Funktionen wie
    I2Cdetect (ein I2C Sniffer) können so einfach mit dazu kommen, mit modprobe [font="Helvetica Neue, Arial, sans-serif"]i2c-bcm2708 installiert man den Low Level
    Treiber für den ARM Core in den Kernel und der Kernel erzeugt dann die /dev's.[/font]

    Belassen wir es also bei dem was zur Verfügung gestellt wird, ändern es ab, benutzen es. Das ist schon komplex genug.

    Im Übrigen lief der kompilierte Kernel bis zu einer gewissen Stelle, dann hängte er sich auf. Für das allererste Mal immerhin
    hat er gebootet, bevor ich die SD karte wie mit dem Backup-Image plattgemacht habe.

    Einmal editiert, zuletzt von Superhobel (26. Dezember 2013 um 02:25)

  • Also einen eigenen Kernel für den Pi wäre schon eine tolle Bastelarbeit für ein verregnetes Wochenende. Auf meinem PC backe ich mir meine Kernel auch stets selber aus den Vanilla-Kernelquellen. Klar, wie der/die Vorredner schon sagten: das geht beim Pi ja nun leider nicht, weil eben wichtige Teile für diese spezielle Hardware fehlen. Aber worin ich ganz klar den Vorteil sehe, ist die individuelle Anpassung des Kernel, bzw die Optimierung auf Größe, indem man alles weglässt, was man nicht braucht.

    Ich glaube, ich weiß schon, was ich während des nächsten Tiefdruckgebietes machen werde. :)


  • ...
    Klar, wie der/die Vorredner schon sagten: das geht beim Pi ja nun leider nicht, weil eben wichtige Teile für diese spezielle Hardware fehlen.
    ...

    Moin,
    wie kommst Du drauf, dass da was fehlt?
    Ich hab erst kürzlich den aktuellen Source mit den Framebuffer-Patches übrsetzt ... das dürfte nach Deiner Theorie ja dann nicht funktioieren.
    Andere hier haben ihre Kernel auf andere LCDs bzw. TFT-Displays angepasst.
    Also von wegen, da fehlt was: zieh' Dir einen branch von github und git ist ... äh gut ist ;) ...

    cu,
    -ds-

  • Oh, dann habe ich das falsch verstanden. :blush:

    Ich habe die Aussagen so interpretiert, daß der Vanilla-Kernel von kernel.org nicht laufen wird, weil die Harware des Pi ein wenig exotisch ist und der Hersteller Anpassungen an dem Kernel gemacht hat, damit Linux auf dem Pi läuft.

    Das war dann wohl irgend wie falsch aufgeschnappt...


  • Also von wegen, da fehlt was: zieh' Dir einen branch von github und git ist ... äh gut ist ;) ...

    Dazu muss ich Dich noch mal löchern: was genau meinst Du damit? Kriege ich von github einen speziellen Pi-Kernel oder auch die Original-Quellen des aktuellen Kernel? Im Moment also 3.14.

    Oder kann ich auch einfach die Quellen zu 3.14 von kernel.org nehmen, und wie in den einschlägigen Anleitungen beschrieben den Kernel auf meinem Arbeitsrechner übersetzen? Also "Cross-Compile", denn auf dem Pi selber übersetzen, dauert mir dann doch zu lange.

  • Hi,

    Auf elinux.org findet man folgende Aussage dazu:

    Zitat


    Get the kernel source

    The kernel source should be downloaded from the RPI linux section on GitHub. Although you could just compile the vanilla kernel from Kernel.org, it will not have the necessary drivers and modules for the Broadcom SoC on the RPi. You can however apply patches from the vanilla kernel to the RPi one - be prepared for potential compiler grumbles though!

    Ich schätze, der Aufwand geht weit über die Abarbeitung der üblichen howtos hinaus. -Zumal die aus meiner Sicht sowieso sehr wenig Hintergrundwissen vermitteln.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!