linux-l: was bedeutet bzImage

[Harald Böhme]

Hi

Die vorherigen Befindlichkeiten mal ausgeklammert.

> > Nun habe ich aber in "Linux Kernelprogrammierung"
> > 5. Auflage gerade auf Seite 11 gelesen:
> >
> > > Falls beim Erstellen von zImage eine Fehlermeldung kommt,
> > > daß der Kern zu groß für ein zImage ist, ruft man
> > > # make bzImasge
> > > auf. Dann wird ein noch stärker komprimierter bootfähiger
> > > Linux-Kern erstellt.
> 
> Schmuh.

Dem muss ich leider zustimmen :-<

 
> ~> make -n  zImage >  zImage.out
> ~> make -n bzImage > bzImage.out
> ~> diff zImage.out bzImage.out
> 634c634
> < make -C arch/i386/boot zImage
> ---
> > make -C arch/i386/boot bzImage

Guter Ansatzt, aber es gibt vile Tricks, die man in der make-Ausgabe
nicht sieht. Also nicht wundern wenn man damit nicht alles findet.
 
> Also nicht sehr viele Unterschiede. Tatsaechlich ist also der kernel
> selbst in beiden Faellen _gleich_. Da "make -C dir" das Makefile im

Na nicht ganz wie du ja untern erklärst:
|| Diese Adressen werden dem Linker ueber die Option -Ttext mitgegeben,
|| denn der Linker muss wissen, wo sich der Code nachher befinden wird,

> Daraus geht hervor, dass zImage "compressed/vmlinux.out" verwendet,
> bzImage dagegen "compressed/bvmlinux.out".

Genau.


> ~> cd compressed
> ~> less Makefile
> 
> Daraus nun geht hervor, dass zImage einen kernel produziert, der an
> Adresse 0x1000 (ZIMAGE_OFFSET) geladen wird, waehrend bzImage einen
> kernel backt, der an Adresse 0x100000 (BZIMAGE_OFFSET) geladen wird.
> Diese Adressen werden dem Linker ueber die Option -Ttext mitgegeben,
> denn der Linker muss wissen, wo sich der Code nachher befinden wird,
> wenn er gestartet wird. Lilo kommt dadurch ins Spiel, dass lilo den
> Kernel ja in den Speicher laden muss, und folglich auch wissen muss,
> wohin damit.

Das geht aber auch ohne LILO, der boot-Sektor des Kernel's muss es also 
auch können. Also wer sich den Assembler antun möchte nur zu. Leider 
werden dabei auch C-Makros benutzt, was die Lesbarkeit nicht sonderlich 
erhöht.

> Ich vermute, dass fuer grosse Kernel die Startadresse 0x1000 ein
> Problem darstellt, weil bei 640K dieses bloede Speicher-Fenster mit
> den Erweiterungskarten liegt. Die Groesse von 508KB (DEF_SYSSIZE)
> fuer die Grenze ab der die Fehlermeldung "System is too big"
> erscheint, sieht mir dagegen sehr zufaellig gewaehlt aus.

Na genauso zufällig wie die Entwicklung der PC-Architektur.

> Kann das jemand etwas genauer erklaeren ?

Aber mal im Ernst; Der eigentliche Grund für die Einführung von bZImage
war doch, dass der Kernel im ausgepackten Zustand über mehr als 640k 
erstrecken kann. D.h. in die unteren 640k des pysikalischen Specihers 
passt er damit nicht mehr. Also muss er über 1M liegen. Die Relokation 
wird ihm wie oben gesagt dann für 1M gegeben. Nun muss der LILO bzw. der 
boot-Code das auch umsetzen. Dabei gibt es noch das leidige Problem der
Speichermodelle mit dem Prozessor zu lösen. Der im Anfangs-Mode nicht 
so einfach den Code über die 64K-Grenzen mehr erreichen kann. Das ist 
auch der eigentlich Grund für die Unterschiede im boot-Code.

Hmm für weitergehende Frage muss ich mich dann auch an Michael wenden,
mein x86-Assembler ist nicht so besonders gut.

MvG
		Harald
-- 
       <<<<              Harald Böhme, Berlin 12489          >>>>
      <<<<             Radicke Str. 52                      >>>>
     <<<<            boehme at informatik.hu-berlin.de        >>>>