Ein kurzer Blick auf das Speicherabbild der ICOP eBox-4300
Mit Hilfe der Dateien config.bib, boot.bib und startup.asm kann man sich einen Überblick über das Speicherabbild einer Plattform verschaffen.
In der Binary Image Builder-Datei config.bib werden die Speicherbereiche des Kernels konfiguriert. In der boot.bib werden die Speicherbereiche des Bootloaders definiert. Und in der startup.asm wird festgelegt, wie physikalische Adressen auf virtuelle Adressen abgebildet werden.
Bei den MIPS- und SHx-Prozessoren erfolgt das Mapping zwischen physikalischen und virtuellen Adressen durch die CPU und den Kernel, bei den x86- und ARM-Prozessoren durch Einträge in die Tabelle OEMAddressTable:
Für jeden Eintrag erzeugt der Kernel zwei virtuelle Adressbereiche. Im Falle des ICOP eBox4300 BSP wird der physikalische Adressbereich 0x00000000 bis 0x1FFFFFFF (512 MB) jeweils auf die virtuellen Kernel-Adressbereiche 0x80000000 bis 0x9FFFFFFF (cached) und 0xA0000000 bis 0xBFFFFFFF (non-cached) abgebildet. Achtung: Bei einer x86 CPU wird die Größe des Adressbereichs in Byte angegeben, bei einer ARM CPU hingegen in MB.
Die Datei config.bib definiert den Verwendungszweck der verschiedenen Speicherregionen einer Plattform. So kann man bestimmen, wie viel Speicher für das Betriebssystem verfügbar ist (RAMIMAGE), wieviel Speicher als Hauptspeicher zur Verfügung gestellt wird (RAM) und welche Speicherbereiche für spezielle Anwendungen reserviert werden (RESERVED).
Hier wurde ab virtueller Adresse 0x80220000 (bzw. physikalischer Adresse 0x220000) 9,875 MB Speicher für das Betriebssystemabbild (nk.bin) festgelegt und diese Region als "NK" benannt. Der frei verfügbare Hauptspeicher "RAM" folgt ohne Lücke ab 0x80C00000 und ist 432 MB groß.
Um Flexibilität zu erhalten und den freien Speicher zu maximieren, kann die Grenze zwischen RAMIMAGE und RAM mit Hilfe des Schalters AUTOSIZE=ON automatisch an die Größe des Betriebssystemabbilds angepaßt werden. Der Hauptspeicher verringert sich dann bei größerem Betriebssystemabbild und umgekehrt.
Falls man die Größe des Hauptspeichers (hier 0x1B000000 = 432 MB) zu klein gewählt hat, könnte dennoch freies RAM ungenutzt bleiben. Diese Lücke nach oben ermittelt jedoch eine Funktion in der Datei %_TARGETPLATROOT%\SRC\X86\COMMON\MEMORY\memory.c und paßt die obere Speichergrenze entsprechend an. In der Debugausgabe wird dies wie folgt angezeigt:
Auf die Speicherbereiche außerhalb von RAMIMAGE und RAM greift der Kernel nicht zu. Dennoch steht das Schlüsselwort RESERVED zur Verfügung, mit dem man zusätzliche Speicherbereiche definieren und somit organisieren kann. So kann z.B. vermieden werden, daß der gleiche Adressbereich für zwei verschiedene Anwendungen verwendet wird.
Im Beispiel oben werden für Native DMA 192 KB, für die Anwendung HDDRegSave 72 KB, für die Boot-Parameter 256 Byte und für den Ethernet DMA-Puffer 128 KB Speicher reserviert.
Für den Bootloader gibt es eine eigene Datei boot.bib.
Da der Bootloader beim x86-Prozessor im Realmodus startet, werden hier physikalische Adressen verwendet. Der Aufbau und die Funktion der Datei ist darüber hinaus identisch mit der config.bib.
Um einen Gesamtüberblick zu erhalten, habe ich beide Speicherabbilder zusammengefügt:
Wie man sieht, wurde der DMA-Puffer für den Ethernet-Controller in beiden BIB-Dateien an gleicher Adresse und mit gleicher Größe reserviert.
Die BOOTARGS-Region ist ein Speicherbereich, der für die Datenübertragung zwischen Bootloader und Kernel dient. Daher hätte ich ihn nicht nur in der config.bib eingetragen, sondern auch in der boot.bib.
Als nächstes fällt auf, daß sich der Speicherbereich für das VIA-Tool HddRegSave mit dem Bootloader RAM überschneidet. Würde man diese Komponente mit in das OS Design aufnehmen, müßte man prüfen, ob diese Überlappung wirklich so gewollt ist, unkritisch oder problematisch ist.
Die ersten 1024 KB von 0x80000000 bis 0x80100000 wurden nicht verplant.
Graphisch sieht die Memory Map so aus:
Mit diesen Informationen kann man das Speicherabbild optimieren, ein BSP von VIA portieren oder auch den in der Systemsteuerung angezeigten freien Hauptspeicher nachrechnen.
Beispiel: Zieht man von den 512 MB DDR2 RAM auf der Hauptplatine die 64 MB Bildschirmspeicher ab, erhält man die 448 MB Systemspeicher gemäß BIOS. Subtrahiert man davon die 2,125 MB (0x00000000-0x0021FFFF) für den Bootloader und den reservierten Speicherbereichen, verbleiben 445,875 MB für das Betriebssystemabbild und den freien Hauptspeicher. Bei einer nk.bin von z.B. 29,875 MB Größe würden dann 416 MB Hauptspeicher zur Aufteilung in Programm- und Objektspeicher mittels FSRAMPERCENT zur Verfügung stehen.
%_TARGETPLATROOT%\FILES\config.bib
%_TARGETPLATROOT%\SRC\BOOTLOADER\EBOOT\boot.bib
%_TARGETPLATROOT%\SRC\X86\COMMON\STARTUP\startup.asmIn der Binary Image Builder-Datei config.bib werden die Speicherbereiche des Kernels konfiguriert. In der boot.bib werden die Speicherbereiche des Bootloaders definiert. Und in der startup.asm wird festgelegt, wie physikalische Adressen auf virtuelle Adressen abgebildet werden.
Bei den MIPS- und SHx-Prozessoren erfolgt das Mapping zwischen physikalischen und virtuellen Adressen durch die CPU und den Kernel, bei den x86- und ARM-Prozessoren durch Einträge in die Tabelle OEMAddressTable:
_OEMAddressTable:
dd 80000000h, 0 ; Mapping from 0x80000000 -> 0x00000000
dd 20000000h ; Size 512 MB
dd 0, 0, 0 ; Last entry, all zerosFür jeden Eintrag erzeugt der Kernel zwei virtuelle Adressbereiche. Im Falle des ICOP eBox4300 BSP wird der physikalische Adressbereich 0x00000000 bis 0x1FFFFFFF (512 MB) jeweils auf die virtuellen Kernel-Adressbereiche 0x80000000 bis 0x9FFFFFFF (cached) und 0xA0000000 bis 0xBFFFFFFF (non-cached) abgebildet. Achtung: Bei einer x86 CPU wird die Größe des Adressbereichs in Byte angegeben, bei einer ARM CPU hingegen in MB.
Die Datei config.bib definiert den Verwendungszweck der verschiedenen Speicherregionen einer Plattform. So kann man bestimmen, wie viel Speicher für das Betriebssystem verfügbar ist (RAMIMAGE), wieviel Speicher als Hauptspeicher zur Verfügung gestellt wird (RAM) und welche Speicherbereiche für spezielle Anwendungen reserviert werden (RESERVED).
MEMORY
; Name Start Größe Typ
; ------- -------- -------- --------
RAM 80C00000 1B000000 RAM ; Hauptspeicher
NK 80220000 009E0000 RAMIMAGE ; Betriebssystemabbild
EDBG_DMA 80200000 00020000 RESERVED ; Ethernet DMA-Puffer
BOOTARGS 801FFF00 00000100 RESERVED ; Bootparameter
REGRW 80150000 00012000 RESERVED ; HDDREGSAVE
DMA 80100000 00030000 RESERVED ; Native DMA
CONFIG
AUTOSIZE=ONHier wurde ab virtueller Adresse 0x80220000 (bzw. physikalischer Adresse 0x220000) 9,875 MB Speicher für das Betriebssystemabbild (nk.bin) festgelegt und diese Region als "NK" benannt. Der frei verfügbare Hauptspeicher "RAM" folgt ohne Lücke ab 0x80C00000 und ist 432 MB groß.
Um Flexibilität zu erhalten und den freien Speicher zu maximieren, kann die Grenze zwischen RAMIMAGE und RAM mit Hilfe des Schalters AUTOSIZE=ON automatisch an die Größe des Betriebssystemabbilds angepaßt werden. Der Hauptspeicher verringert sich dann bei größerem Betriebssystemabbild und umgekehrt.
Falls man die Größe des Hauptspeichers (hier 0x1B000000 = 432 MB) zu klein gewählt hat, könnte dennoch freies RAM ungenutzt bleiben. Diese Lücke nach oben ermittelt jedoch eine Funktion in der Datei %_TARGETPLATROOT%\SRC\X86\COMMON\MEMORY\memory.c und paßt die obere Speichergrenze entsprechend an. In der Debugausgabe wird dies wie folgt angezeigt:
OEM Extra DRAM Detected @ base = xBBC00000, size=4 MB
MainMemoryEndAddress = 0x9c000000Auf die Speicherbereiche außerhalb von RAMIMAGE und RAM greift der Kernel nicht zu. Dennoch steht das Schlüsselwort RESERVED zur Verfügung, mit dem man zusätzliche Speicherbereiche definieren und somit organisieren kann. So kann z.B. vermieden werden, daß der gleiche Adressbereich für zwei verschiedene Anwendungen verwendet wird.
Im Beispiel oben werden für Native DMA 192 KB, für die Anwendung HDDRegSave 72 KB, für die Boot-Parameter 256 Byte und für den Ethernet DMA-Puffer 128 KB Speicher reserviert.
Für den Bootloader gibt es eine eigene Datei boot.bib.
MEMORY
; Name Start Größe Typ
; ------- -------- -------- --------
ETHDMA 00200000 00020000 RESERVED ; Ethernet-Controller
RAM 00150000 00070000 RAM ; Bootloader RAM
EBOOT 00130000 00020000 RAMIMAGE ; Bootloaderabbild
; Total reserved area, which equals offset of the NK region in RAM
dwReservedArea 00000000 00220000 FIXUPVARDa der Bootloader beim x86-Prozessor im Realmodus startet, werden hier physikalische Adressen verwendet. Der Aufbau und die Funktion der Datei ist darüber hinaus identisch mit der config.bib.
Um einen Gesamtüberblick zu erhalten, habe ich beide Speicherabbilder zusammengefügt:
Name Start Größe Typ
------- -------- -------- --------
RAM 80C00000 1B000000 RAM ; Hauptspeicher
NK 80220000 009E0000 RAMIMAGE ; Betriebssystemabbild
EDBG_DMA 80200000 00020000 RESERVED ; Ethernet DMA-Puffer
ETHDMA 80200000 00020000 RESERVED ; Ethernet-Controller
BOOTARGS 801FFF00 00000100 RESERVED ; Bootparameter
REGRW 80150000 00012000 RESERVED ; HDDREGSAVE
RAM 80150000 00070000 RAM ; Bootloader RAM
EBOOT 80130000 00020000 RAMIMAGE ; Bootloaderabbild
DMA 80100000 00030000 RESERVED ; Native DMAWie man sieht, wurde der DMA-Puffer für den Ethernet-Controller in beiden BIB-Dateien an gleicher Adresse und mit gleicher Größe reserviert.
Die BOOTARGS-Region ist ein Speicherbereich, der für die Datenübertragung zwischen Bootloader und Kernel dient. Daher hätte ich ihn nicht nur in der config.bib eingetragen, sondern auch in der boot.bib.
Als nächstes fällt auf, daß sich der Speicherbereich für das VIA-Tool HddRegSave mit dem Bootloader RAM überschneidet. Würde man diese Komponente mit in das OS Design aufnehmen, müßte man prüfen, ob diese Überlappung wirklich so gewollt ist, unkritisch oder problematisch ist.
Die ersten 1024 KB von 0x80000000 bis 0x80100000 wurden nicht verplant.
Graphisch sieht die Memory Map so aus:
9BC0.0000 -+- 444 MB
|
| Hauptspeicher (432 MB)
|
80C0.0000 -+ *auto-size*
|
| Betriebssystemabbild (10 MB)
|
8022.0000 -+
| Ethernet DMA-Puffer (128 KB)
8020.0000 -+
| Bootparameter (256 B)
801F.FF00 -+
| Bootloader RAM (448 KB)
8015.0000 -+
| Bootloaderabbild (128 KB)
8013.0000 -+
| Native DMA (192 KB)
8010.0000 -+
|
8000.0000 -+- 0 MBMit diesen Informationen kann man das Speicherabbild optimieren, ein BSP von VIA portieren oder auch den in der Systemsteuerung angezeigten freien Hauptspeicher nachrechnen.
Beispiel: Zieht man von den 512 MB DDR2 RAM auf der Hauptplatine die 64 MB Bildschirmspeicher ab, erhält man die 448 MB Systemspeicher gemäß BIOS. Subtrahiert man davon die 2,125 MB (0x00000000-0x0021FFFF) für den Bootloader und den reservierten Speicherbereichen, verbleiben 445,875 MB für das Betriebssystemabbild und den freien Hauptspeicher. Bei einer nk.bin von z.B. 29,875 MB Größe würden dann 416 MB Hauptspeicher zur Aufteilung in Programm- und Objektspeicher mittels FSRAMPERCENT zur Verfügung stehen.
Comments
Noch keine Kommentare