This page describe the memory map for the DragonEngine board but most
of the informations here are valid for other m68knommu platforms as well,
check the linker script and the crt0_xxx.S for your platform
to see the differences.
The uClinux build system is building first the linux kernel, then the user applications and the root filesystem. The last step is usually to extract the text, data and init segments, to convert them in a flat binary file and to add the root file system at the end. This will give you the image.bin file, below is the organisation of this file.
| .text segment | beginning of file | |
| .data segment | ||
| .init segment | optional (1) | |
| rootfs | cat'd from romfs.img | |
(1) check the .ld linker script used by the build model (RAM/ROM/HIMEM) |
||
The crt0_xxx.S file is responsible of sections initialisation. The image.bin file is downloaded (or stored) into the board at his start address so the text section does not need to be moved.
The data section should be moved from the end of the text section to its final place in memory, unless the memory model is RAM, in which case the data section is already at its final place
The init section is present only in the RAM model and it is also loaded at its final place. After boot, the init section is usually freed back into the usable memory pool. This freeing can not be done if the init section is merged into the data section.
The rootfs section needs to be moved in the RAM model, to make room for the bss section. In the HIMEM or ROM model it can stay where it was loaded. The rootfs could be directly stored in ROM (and not present in the image file). Some platforms do this (and use XIP) to greatly reduce their RAM requirements.
The bss section needs to be created and initialised with 0's
| _stext, _etext | start/end of the .text section, set by the linker |
| _sdata, _edata | start/end of the .data section, set by the linker |
| _sbss, _ebss | start/end of the .bss section, set by the linker |
| __init_begin, __init_end | start/end of the .init section, set by the linker |
| _rambase | start of physical ram, set by the crt0_xxx.S |
| _ramstart | start of kernel usable ram, set by the crt0_xxx.S |
| _ramend | end of kernel usable ram, set by the crt0_xxx.S |
This is the final memory map, when crt0_ram.S has finished the initialisation.
| start of physical ram | _rambase | |
| .text segment | _stext | |
| .data segment | _etext, _sdata | |
| .init segment | _edata, __init_begin | |
| .bss segment | __init_end, _sbss | |
| rootfs | _ebss | |
| start of kernel usable ram | _ramstart | |
| end of kernel usable ram | _ramend |
This is the final memory map, in the ROM model, the image.bin is stored in the flash device while in the HIMEM model it is stored in an area reserved at the top of the ram. IMHO, while the ROM model save some ram, the HIMEM model is pretty useless, it can be replaced easily by the RAM model, saving more ram space as it does not need to reserve a ram area. The ROM model can be replaced by compressing the RAM image.bin and storing it in flash. At runtime, the image is decompresssed and stored in ram.
| start of physical ram | _rambase | ram | |
| .data segment | _sdata | ||
| .bss segment | _edata, _sbss | ||
| start of kernel usable ram | _ebss, _ramstart | ||
| end of kernel usable ram | _ramend | ||
| .text and .init segments | _stext | rom or ram | |
| copy of the .data segment | _etext | ||
| rootfs | _etext + size of .data |