This chapter describes how to configure your system image to specify the new BSP component. The configuration of the ChorusOS system image depends on a number of configuration files written in ECML but for the purpose of adding a BSP you will mainly need to create and edit the target.xml and target_action.xml files.
On some platforms, target.xml is split into multiple file: drvlist.xml, drivers.xml which are included in target.xml.
"Overview of Creating a System Image" describes a ChorusOS system image and explains how to build it.
"Imported Objects" lists the predefined objects that can be used within your configuration files to specify different conditions.
"Summary of Required Definitions" lists the objects that must be specified in your configuration.
"The target.xml File Structure" describes the content and structure of the target.xml file.
"The mkimage System Image" describes the content of the system image created by mkimage.
This section explains what the system image is and how to create it using the tools and configuration files provided.
The system image is the initial state of the target board's physical memory. It contains a set of files that are organized into one or more memory banks. For more information on the complete set of ChorusOS configuration files see "Configuration Files" in ChorusOS 5.0 System Administrator's Guide.
When the target system is deployed, some of the system image memory banks are burnt into non-volatile physical memory. The rest can be downloaded from a local device or from the network by the initial loader (boot monitor or firmware).
To build the system image, you use an XML-based system. This system has two components:
The ChorusOS operating system configuration tools, ews and configurator, enable you to create, view, and modify a system image's configuration files, which are defined using EMCL (based on XML). You can also modify the configuration files directly. In fact when you create the system image for a new target board, you will need to create the target configuration files using a text editor before being able to use these tools.
The mkimage tool creates the system image as defined in the configuration files.
The board-specific configuration must be stored in the board BSP directory: source_dir/nucleus/bsp/family/board. For example, the board-specific configuration files for the SBC8260 board are stored in source_dir/nucleus/bsp/powerpc/sbc8260, and those for the PC/AT are stored in source_dir/nucleus/bsp/x86/i386at.
There are two configuration files that define the BSP and driver configuration of the system image:
target.xml specifies the main board-specific configuration
target_action.xml specifies the board-specific system image reshaping procedure
The configuration must specify the list of memory banks and, for each particular bank, a symbolic name, a base address, and a size limit. Also, the configuration can request mkimage to organize any particular memory bank as a file system volume. The current ChorusOS operating system release supports FAT MS-DOS format only.
The configuration must also specify a list of files to be included in the system image and, for each particular file, the bank where the file must be stored. In addition, for relocatable ELF files, the configuration can specify how the file must be relocated when stored in the memory bank.
Most of the examples in this chapter use the SBC8260 board. To understand the examples, the following information about the SBC8260 board is useful:
CPU: EC603e
Physical memory map: The power-up initialization code programs the chipset memory map decoder registers in such a way that in the processor's physical address space, all available RAM is contiguously mapped to (physical) address 0x0, and at least 1M of NOR flash memory is contiguously mapped to the end of the physical address space (that is, to the physical address 0xfff00000).
Deployment: The ChorusOS configuration supports two deployment schemes:
The following objects are predefined and can be used within the board-specific configuration files. They can be used to specify conditions that enable different configurations to be set up for different situations, for example you can set up two different configurations for the two deployment schemes, that would depend on the object BOOT_MODE:
SYSTEM specifies the kind of ChorusOS operating system currently built and is an enumeration. The possible values of SYSTEM are:
kernonly: the system image will contain the microkernel, built-in drivers and possibly built-in application actors
chorus: the system image will contain the microkernel, built-in drivers, the POSIX personality and possibly built-in application actors
uartTest or flashTest: the system image will contain the corresponding device driver (UART or flash memory) test program
kts or ktu: the system image will contain the general purpose microkernel test suite to be run in the supervisor (kts) or the user (ktu) mode
benchs or benchu: the system image will contain the microkernel benchmark program to be run in the supervisor (benchs) or the user (benchu) mode
BOOT_MODE specifies how the generated system image will be deployed on the target board, and is an enumeration. The possible values for BOOT_MODE are:
ROM: the system image will be deployed (burned, flashed) in ROM or Flash
RAM: the system image will be downloaded in RAM from a local device or the network
BUILD_DIR is a string specifying the build directory prepared by the configure utility during the ChorusOS operating system installation.
BSP_DIR is a string specifying the installation directory of the BSP configuration and bootstrap package.
DRV_DIR is a string specifying the installation directory of the family-specific and generic drivers package.
A board-specific configuration must define the following objects. They are defined in the ECML target.xml file using variables and folders. More information on how to define these objects is given in the following sections:
IMAGE_DIR which specifies the mkimage tool output repository (Global variables folder).
sys_bank which specifies the default system image memory bank (Banks folder).
banks which specifies the list of system image memory banks (Misc folder).
ram_area which specifies the default system image linking area--only used for bss. (Areas folder).
supervisor_context_area_ref which specifies a reference to the address range where global system control blocks must be allocated (Areas folder).
user_context_area_ref which specifies a reference to the address range where user software registers must be allocated (Areas folder).
BSP_files which specifies the list of BSP files that must be added to the system image. The full paths of these files are specified in the Files folder (System image folder).
env_file which specifies the path of the generated file containing the initial state of the system environment variables. It is defined in the Auto-generated files folder.
symb which specifies the path of the generated file containing the kernel debugger symbols (Auto-generated files folder).
bootconf which specifies the path of the bootconf application (Auto-generated files folder).
heap_size which specifies the bootconf heap size (Misc folder).
ksp which specifies the microkernel address space configuration (Kernel address space folder).
space_barrier which must be defined for x86 and MPC860 based platforms.
This section describes the content and structure of the target.xml file. The main folders and the variables that they contain are shown in examples.
A target.xml file contains a number of hierarchical folders. The top level of folders is the following:
Global variables
Banks
Areas
Kernel address space
Link-edit models
Files
System image, which contains the following folders:
Files
Auto-generated files
Miscellaneous
The Global variables folder contains definitions of global system image configuration variables.
Some of them are board-specific and used within the board-specific configuration files only. For example, a configuration for a PC/AT target defines the LOADER configuration variable, with a value specifying which of the two initial loaders (SVR4 boot and Linux LILO boot) will be used to load the system image. The format of the system image is tailored to match the requirements of the initial loader specified by LOADER.
There is one mandatory global variable, IMAGE_DIR. This variable specifies the working directory to be used by the mkimage tool to store the files created during the generation of the ChorusOS system image.
Example 7-1 is an extract of the SBC8260 board-specific configuration file, and defines two global configuration variables, IMAGE_DIR and RESULT.
<definition name='IMAGE_DIR'> <description>'mkimage' tool output repository</description> <string/> <vstring>${BUILD_DIR}/image/${BOOT_MODE}/${SYSTEM}</vstring> </definition> <definition name='RESULT'> <description>the resulting system image file pathname</description> <string/> <vstring>${BUILD_DIR}/${SYSTEM}.${BOOT_MODE}</vstring> </definition>
The value of IMAGE_DIR specifies the mkimage working directory as a function of the BOOT_MODE and SYSTEM configuration variables. For example, the working directory for RAM-based chorus system image generation is ${BUILD_DIR}/image/RAM/chorus.
The value of RESULT specifies the filename of the resulting (bootable) system image file. The filename also depends on the BOOT_MODE and SYSTEM configuration variables. For example, the bootable RAM-based chorus system image file will be stored in ${BUILD_DIR}/chorus.RAM.
The Banks folder contains definitions of the system image memory banks.
A system image memory bank is specified by an object of the type Bank. The following fields of a Bank object must be defined in the target.xml file in order to define the properties of each bank:
addr is an integer that specifies the address at which the memory bank must be installed (burned or downloaded) during the system deployment process. Usually the address is physical on PowerPC and x86 systems and virtual in UltraSPARC systems.
size is an integer specifying the maximum size of the memory bank.
ram is a boolean specifying whether the bank occupies RAM at installation.
If the value of ram is true, mkimage determines the portion of the system RAM that the memory bank image will occupy after installation, and tags that RAM as PH_ALLOCATED in the initial state of the RAM allocator.
If the value of ram is false, the bank has no impact on the initial state of the RAM. For example, the value of ram must be false if the memory bank is to be burned in ROM.
The default value of ram is true.
The board-specific configuration can define any number of memory banks. A board-specific configuration must define a Bank object named sys_bank.
For example, the SBC8260 board-specific configuration defines two memory banks trampoline_bank and sys_bank.
The trampoline_bank memory bank will contain the power-up initialization (trampoline) program (see "Power-up Program Implementation"). The sys_bank memory bank will contain the remains of the system image.
Code Example 7-2 is an extract of the SBC8260 board-specific configuration file, and defines the trampoline_bank and sys_bank objects.
<folder name='Banks'> <description>system image memory banks</description> <definition name='sys_bank'> <description>default system image memory bank</description> <condition> <equal><var name='BOOT_MODE' /><const>RAM</const></equal> </condition> <type name='Bank' /> <value field='ram'><true /></value> <value field='addr'><const>0x00100000</const></value> <value field='size'><const>0x00f00000</const></value> </definition> <definition name='trampoline_bank'> <description>memory bank for a 'trampoline' (eg. power-up) binary</description> <condition> <equal><var name='BOOT_MODE' /><const>ROM</const></equal> </condition> <type name='Bank' /> <value field='ram'><false /></value> <value field='addr'><const>0xfff00000</const></value> <value field='size'><const>0x00001000</const></value> </definition> <definition name='sys_bank'> <description>default system image memory bank</description> <condition> <equal><var name='BOOT_MODE' /><const>ROM</const></equal> </condition> <type name='Bank' /> <value field='ram'><false /></value> <value field='addr'><const>0xfff01000</const></value> <value field='size'><const>0x000ff000</const></value> </definition> </folder>
Two bank configurations are provided. The first configuration is used when the system is configured to boot from ROM. This configuration is selected when the value of the BOOT_MODE configuration variable is set to ROM. In this case, trampoline_bank will start at the address 0xfff00000 and can contain up to 4K bytes, sufficient for the trampoline program to run. sys_bank starts immediately after trampoline_bank at the address 0xfff01000 and it can contain up to 0xff000 bytes.
The second configuration is used when the system is configured to boot from RAM. In this case, trampoline_bank is not defined. sys_bank starts at the address 0x00100000 and it can contain up to 0xf00000 bytes. The RAM occupied by the bank will be tagged as allocated when the initial state of the RAM allocator is generated, because the value of the ram field is true.
For more information on the resulting system image bank description structure see "Banks".
This folder contains definitions of the linking areas used during system image link-edit. A linking area is specified by an object of the type Area which defines the following fields:
addr is an integer specifying the starting address of the linking area. The address can be physical or virtual on PowerPC and x86 based systems and is usually virtual on UltraSPARC based systems.
size is an integer specifying the size of the linking area.
virtual is a boolean specifying whether the linking area occupies virtual address space. If the value of virtual is false, mkimage determines the portion of the system RAM that the segments link-edited into this area will occupy and tags the RAM as PH_ALLOCATED in the initial state of the RAM allocator.
If the value of virtual is true, the area will not impact the initial state of the RAM allocator. For example, the value of virtual must be true when the area object corresponds to a portion of a user virtual address space.
private is a boolean specifying whether or not the linking area is shared. If the value of private is false, the linking area is shared by all binaries that use it. This means that any two segments link-edited into this area will not overlap. These types of linking areas are typically used to link-edit supervisor address space binaries.
If the value of private is true, one instance of the linking area is created for each binary that uses it. This means that two segments link-edited into this area overlap if, and only if, they belong to two different binaries. These types of linking areas are typically used to link user address space actors.
The board-specific configuration can define any number of linking areas. A board-specific configuration must define an Area object named ram_area.
For example, the SBC8260 board-specific configuration defines three linking areas: ram_area, supervisor_actor_area, and user_actor_area.
When the microkernel is configured with the memory management module implementing the flat memory model (that is, when the value of the VIRTUAL_ADDRESS_SPACE configuration variable is false), only ram_area is defined. It is used to link-edit all non-XIP data segments.
Code Example 7-3 is an extract of the SBC8260 board-specific configuration file, and defines the ram_area object.
<definition name='ram_area'> <description>default system image linking area (used for bss only)</description> <condition> <equal><var name='BOOT_MODE' /><const>RAM</const></equal> </condition> <type name='Area' /> <value field='addr'><const>0x00004000</const></value> <value field='size'><const>0x000fc000</const></value> <value field='private'><false/></value> <value field='virtual'><false/></value> </definition> <definition name='ram_area'> <description>default system image linking area (used for data segments)</description> <condition> <equal><var name='BOOT_MODE' /><const>ROM</const></equal> </condition> <type name='Area' /> <value field='addr'><const>0x00004000</const></value> <value field='size'><const>0x00ffc000</const></value> <value field='private'><false/></value> <value field='virtual'><false/></value> </definition>
When the microkernel is configured with one of the memory management modules implementing the virtual memory model (that is, when the value of the VIRTUAL_ADDRESS_SPACE configuration variable is true), three linking areas are defined:
ram_area has the same definition as described above but is used to link-edit BIN_STANDALONE binaries, such as bootconf and bootstrap programs, the debug agent and the microkernel only
supervisor_actor_area is used to link-edit all built-in drivers and supervisor actors
user_actor_area is used to link-edit all user actors
Code Example 7-4 is an extract of the SBC2860 board-specific configuration file, and defines the supervisor_actor_area and user_actor_area objects.
<definition name='supervisor_actor_area'> <description>linking area for supervisor actors</description> <condition><var name='VIRTUAL_ADDRESS_SPACE' /></condition> <type name='Area' /> <value field='virtual'><true /></value> <value field='private'><false /></value> <value field='addr'><const>0xa0000000</const></value> <value field='size'><const>0x40000000</const></value> </definition> <definition name='user_actor_area'> <description>linking area for user actors</description> <condition><var name='VIRTUAL_ADDRESS_SPACE' /></condition> <type name='Area' /> <value field='virtual'><true /></value> <value field='private'><true /></value> <value field='addr'><const>0x00000000</const></value> <value field='size'><const>0x80000000</const></value> </definition>
A board-specific configuration must define two references to linking area objects where global system control blocks are allocated:
supervisor_context_area_ref specifies the area where supervisor address space global control blocks will be allocated
user_context_area_ref specifies the area where the memory for user thread private data will be allocated
For example, the SBC8260 board-specific configuration defines supervisor_context_area_ref as a reference to ram_area:
<definition name='supervisor_context_area_ref'> <description>reference to the address range where global system control blocks must be allocated</description> <type name='Area' ref-only='yes' /> <ref name='ram_area' /> </definition>
The mkimage tool will allocate an address range for supervisor address space control blocks in ram_area (as well as the address ranges for all segments link-edited into it).
Two configurations for user_context_area_ref are defined for the SBC8260 board.
When the microkernel is configured with the memory management module implementing the flat memory model (that is, when the value of the VIRTUAL_ADDRESS_SPACE configuration variable is false), user_context_area_ref is defined as a reference to ram_area:
<definition name='user_context_area_ref'> <description>reference to the address range where user software registers must be allocated</description> <condition><not><var name='VIRTUAL_ADDRESS_SPACE' /></not> </condition> <type name='Area' ref-only='yes' /> <ref name='ram_area' /> </definition>
mkimage allocates user thread private data in ram_area.
When the microkernel is configured with one of memory management modules implementing the virtual memory model (that is, when the value of the VIRTUAL_ADDRESS_SPACE configuration variable is true), user_context_area_ref defines a specific address range (linking area) in the user virtual address space:
<definition name='user_context_area'> <description>address range where user software registers must be allocated</description> <condition><var name='VIRTUAL_ADDRESS_SPACE' /></condition> <type name='Area' /> <value field='virtual'><true /></value> <value field='private'><false /></value> <value field='addr'><const>0xeffff000</const>></value> <value field='size'><const>0x00001000</const></value> </definition> <definition name='user_context_area_ref'> <description>reference to the address range where user software registers must be allocated</description> <condition><var name='VIRTUAL_ADDRESS_SPACE' /></condition> <type name='Area' ref-only='yes' /> <ref name='user_context_area' /> </definition>
A board-specific configuration can specify the initial microkernel address space layout. If specified, the object that defines it must be named ksp and is usually contained in the folder named KSP. The exact semantics and requirements for the initial microkernel address space specifications are family dependent. For more information on the resulting system image data see "The Initial Address Space"
An MPC60x family-dependent configuration must specify the initial microkernel address space layout.
The SBC8260 board-dependent configuration specifies the initial microkernel address space as follows:
<folder name='Kernel address SPace'> <description>kernel address space configurations</description> <definition name='ksp'> <description>flat memory management: system address space layout virtual memory management: see PPC 60x BKI</description> <type name='AddrSpaceMap' /> <!-- PowerPC 60x bus SDRAM: 0x00000000 .. 0x00ffffff --> <value index='size'> <value field='vaddr'><const>0x00000000</const></value> <value field='valid'><true/></value> <value field='paddr'><const>0x00000000</const></value> <value field='attr'> <const>KSP_PPC60x_BAT|KSP_PPC60x_M|KSP_PPC60x_RW</const> </value> </value> <!-- Local bus 32-bit SDRAM: 0x01000000 .. 0x0effffff --> <value index='size'> <value field='vaddr'><const>0x01000000</const></value> <value field='valid'><false/></value> </value> <!-- 8260 internal memory map (IMMR): 0x0f000000 .. 0x0f01ffff --> <value index='size'> <value field='vaddr'><const>0x0f000000</const></value> <value field='valid'><true/></value> <value field='paddr'><const>0x0f000000</const></value> <value field='attr'> <const>KSP_PPC60x_BAT|KSP_PPC60x_G|KSP_PPC60x_I|KSP_PPC60x_RW </const> </value> </value> <value index='size'> <value field='vaddr'><const>0x0f020000</const></value> <value field='valid'><false/></value> </value> <!-- 8-bits general purpose FLASH memory: 0xe0000000 .. 0xe0ffffff --> <!-- 32-bits general purpose FLASH memory. expandable : 0xfc000000 .. 0xfcffffff boot : 0xfe000000 .. 0xffffffff --> <value index='size'> <value field='vaddr'><const>0xfc000000</const></value> <value field='valid'><true/></value> <value field='paddr'><const>0xfc000000</const></value> <value field='attr'> <const>KSP_PPC60x_BAT|KSP_PPC60x_RO</const></value> </value> </definition> </folder>
According to this definition, the microkernel will initially map the RAM space from physical address 0 to 0x01000000, to the virtual address 0, using one pair of BATs. It will also map the flash memory space from physical address 0xfc000000 to 0xffffffff, to the virtual address 0xfc000000 using another pair of BATs. Finally, the microkernel will map 0x00020000 bytes of 8260 Internal Memory Mapped Registers based at the physical address 0x0f000000 to the virtual address 0x0f000000. The rest of the virtual address space will be invalid.
The link-edit models folder contains a set of link-edit models, each one describing how to link-edit a particular type of binary file.
The models.xml file contains the standard set of link-edit models:
bootconf_model specifies the default link-edit model for bootconf programs
bootstrap_model specifies the default link-edit model for bootstrap programs
debug_driver_model specifies the default link-edit model for debug agent drivers
debug_agent_model specifies the default link-edit model for debug agents
microkernel_model specifies the default link-edit model for the microkernel
driver_model specifies the default link-edit model for built-in drivers
supervisor_actor_model specifies the default link-edit model for supervisor actors
user_actor_model specifies the default link-edit model for user actors
reboot_model specifies the default link-edit model for reboot programs
Usually, the board-specific configuration includes the models defined in model.xml and defines a small number of board-specific models.
A link-edit model is specified by an object of type Binary
which defines the following fields:
type is an enumeration specifying how the resulting program will be activated by the ChorusOS operating system boot process.
If a type value is not specified, the program will be activated by a specific procedure such as processor hardware reset or ChorusOS operating system afexec.
ro is an optional field specifying link-edit instructions for read-only sections (such as text and initialized read-only data). If the field is not specified, read-only sections will be link-edited using instructions for read-write sections.
rw is an optional field specifying link-edit instructions for read-write data sections. If the field is not specified, the program must not contain read-write data sections.
bss is an optional field specifying link-edit instructions for zero initialized read-write data sections.If the field is not specified, zero-initialized read-write sections will be link-edited using instructions for read-write sections.
strip is an enumeration specifying whether or not ELF headers, symbols and debug information must be included in the resulting program image.
If the value of strip is NOTHING, the resulting image will contain all ELF headers, symbol tables and debug information.
If the value of strip is ALL, the resulting image will contain program segment images only.
If the value of strip is SYMBOLS, the resulting image will contain program segment images and ELF file and segment headers.
The values of the ro, rw, and bss fields are objects of the type Segment. A Segment object specifies link-edit instructions for the set of sections held by the segment and instructions for the segment loading for execution. In the Segment object:
The optional area field is a reference to an Area object. If the field is defined, each section must be link-edited into an address range dynamically allocated in the linking area, whereas if the field is not defined, each section must be link-edited at the address equal to the section's image start in the memory bank.
If the value of the boolean xip is true, the segment must be executed at its place in the memory bank. If the value of the boolean xip is false the segment image must be copied in RAM for execution.
Therefore, if for a given segment a linking area is not defined (for instance, the segment is to be link-edited at its place in the memory bank) , the xip attribute must be true.
If, for a segment, a linking area is defined, the xip attribute can be either:
True: the linking area must be virtual
False: the linking area can be virtual or physical
Code Example 7-6 is an extract of the SBC8260 board-specific configuration file, and contains the standard link-edit models and the link-edit model definition which contains the trampoline program.
<folder name='Link-edit models'> <description>layouts of executable binary files</description> <folderRef href='model.xml' /> <folder name='Genesis2-specific link-edit models'> <description>layouts of executable binary files</description> <definition name='trampoline_model'> <description>trampoline (eg. power-up) program link-edit model</description> <type name='Binary' /> <value field='ro'> <value field='xip'><true/></value> </value> <value field='strip'><const>ALL</const></value> </definition> </folder> </folder>
The trampoline program does not contain any data and its text section must be link-edited at its place in its memory bank, trampoline_bank.
The Files folder contains the specification of the set of BSP files that can be included in the system image. Each file is specified by an object of the type File which contains the following fields:
path is a character string specifying the pathname of the file.
bank is a reference to the Bank object specifying the memory bank where mkimage will store the file image.
binary is an optional field specifying the link-edit model for the file. If binary is not specified, the file will be processed as a raw data file.
Code Example 7-7 is an extract of the SBC8260 board-specific configuration file, and contains the definitions of the File objects.
<folder name='Files'> <description>files that system image can potentially contain</description> <definition name='powerup'> <description>powerup initialization program</description> <condition> <equal><var name='BOOT_MODE' /><const>ROM</const></equal> </condition> <type name='File' /> <value field='path'> <vstring>${BSP_DIR}/bin/sbc8260/boot/trampoline</vstring> </value> <value field='bank'><ref name='trampoline_bank' /></value> <value field='binary'><ref name='trampoline_model' /></value> </definition> <definition name='bootstrap'> <description>bootstrap program</description> <type name='File' /> <value field='path'> <vstring>${BSP_DIR}/bin/sbc8260/boot/boot</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='bootstrap_model' /></value> </definition> <definition name='debug_driver'> <description>system debug agent driver</description> <type name='File' /> <value field='path'> <vstring>${BSP_DIR}/bin/sbc8260/dbg/dbgBsp</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='debug_driver_model' /></value> </definition> <definition name='debug_agent'> <description>system debug agent</description> <type name='File' /> <value field='path'> <vstring>${BUILD_DIR}/obj/dbg/dbgAgent</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='debug_agent_model' /></value> </definition> <definition name='microkernel'> <description>ChorusOS microkernel</description> <type name='File' /> <value field='path'> <vstring>${BUILD_DIR}/obj/kern/kern</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='microkernel_model' /></value> </definition> <definition name='tbdec'> <description>built-in driver</description> <type name='File' /> <value field='path'> <vstring>${DRV_F_DIR}/bin/drv/timer/tbDec/D_tbDec</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='driver_model' /></value> </definition> <definition name='quicc8260'> <description>built-in driver</description> <type name='File' /> <value field='path'> <vstring>${DRV_F_DIR}/bin/drv/quicc/8260/D_quicc8260</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='driver_model' /></value> </definition> <definition name='fccEther'> <description>built-in driver</description> <type name='File' /> <value field='path'> <vstring>${DRV_DIR}/bin/drv/net/ether/fcc/D_fccEther</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='driver_model' /></value> </definition> <definition name='sccEther'> <description>built-in driver</description> <type name='File' /> <value field='path'> <vstring>${DRV_DIR}/bin/drv/net/ether/scc/D_sccEther</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='driver_model' /></value> </definition> <definition name='quiccMii'> <description>built-in driver</description> <type name='File' /> <value field='path'> <vstring>${DRV_DIR}/bin/drv/mii/quiccMii/D_quiccMii</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='driver_model' /></value> </definition> <definition name='lxt970'> <description>built-in driver</description> <type name='File' /> <value field='path'> <vstring>${DRV_DIR}/bin/drv/phy/lxt970/D_lxt970</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='driver_model' /></value> </definition> <definition name='sccUart'> <description>built-in driver</description> <type name='File' /> <value field='path'> <vstring>${DRV_DIR}/bin/drv/uart/scc/D_sccUart</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='driver_model' /></value> </definition> <definition name='reboot'> <description>reboot program</description> <type name='File' /> <value field='path'> <vstring>${BSP_DIR}/bin/sbc8260/reboot/reboot</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='reboot_model' /></value> </definition> </folder>
The system image folder contains three sub-folders:
Files
Auto-generated files
Misc
The files folder contains the definition of a BSP_files object, which is a list of references to File objects specifying the files that must be included in the system image.
A board-specific configuration must define a BSP_files object.
Code Example 7-8 is an extract of the SBC8260 board-specific configuration file, and contains the BSP_files definition.
<definition name='BSP_files'> <description>system image BSP files</description> <type name='FileList' /> <value index='size'><ref name='debug_driver' /></value> <value index='size'><ref name='debug_agent' /></value> <value index='size'><ref name='bootstrap' /></value> <value index='size'><ref name='reboot' /></value> <value index='size'><ref name='microkernel' /></value> <value index='size'><ref name='tbdec' /></value> <value index='size'><ref name='quicc8260' /></value> <value index='size'><ref name='fccEther' /></value> </definition> <setting name='BSP_files'> <condition> <equal><var name='BOOT_MODE' /><const>ROM</const></equal> </condition> <value index='size'><ref name='powerup' /></value> </setting>
The mkimage tool generates three files:
The bootconf program, ${IMAGE_DIR}/bconf/${SYSTEM}_bconf
A program that stores the kdb symbol tables, ${IMAGE_DIR}/symb/${SYSTEM}_symb
A data file that stores the initial state of the system environment, ${IMAGE_DIR}/environ
The Auto-generated files folder contains definitions of File objects corresponding to these three files. The File objects must be named bootconf, symb, and env_file, respectively.
Code Example 7-9 is an extract of the SBC8260 board-specific configuration file, and contains the Auto-generated files definition.
<folder name='Auto-generated files'> <description>system image files automatically \ generated by 'mkimage' tool</description> <definition name='env_file'> <description>initial state of system environment \ variables</description> <type name='File' /> <value field='path'> <vstring>${IMAGE_DIR}/environ</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> </definition> <definition name='symb'> <description>kernel debuger (kdb) symbols</description> <type name='File' /> <value field='path'> <vstring>${IMAGE_DIR}/symb/${SYSTEM}_symb</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='debug_agent_model' /></value> </definition> <definition name='bootconf'> <description>bootconf program</description> <type name='File' /> <value field='path'> <vstring>${IMAGE_DIR}/bconf/${SYSTEM}_bconf</vstring> </value> <value field='bank'><ref name='sys_bank' /></value> <value field='binary'><ref name='bootconf_model' /></value> </definition> </folder>
The misc folder contains the following:
banks is a list of references to all Bank objects that the system image will contain.
heap_size is an integer specifying the size of the bootconf program heap.
space_barrier is an integer specifying, if required, the highest address of the supervisor address space and the lowest address of the user address space.
Code Example 7-10 is an extract of the SBC8260 board-specific configuration file, and contains the Misc definition.
<folder name='Misc'> <description>Misc configuration variables</description> <definition name='banks'> <description>list of system image banks</description> <type name='BankList'/> </definition> <definition name='heap_size'> <description>bootconf heap size</description> <int/> <const>0x00002000</const> </definition> <setting name='banks'> <condition> <equal><var name='BOOT_MODE' /><const>ROM</const></equal> </condition> <value index='size'><ref name='trampoline_bank' /></value> </setting> <setting name='banks'> <value index='size'><ref name='sys_bank' /></value> </setting> </folder>
This section contains more information on the output from the mkimage tool and the target-specific configuration files that are described in the previous section.
If relocation is specified for a given file, mkimage relocates it and stores the resulting absolute binary file in the memory bank. You can specify how many program segments must contain the resulting binary file and, for each individual segment, how it must be relocated.
A segment can be relocated to a linking area or to the segment image's base address within the memory bank.
A linking area is a named range of addresses specified by an id, a base address, and a size. You can specify a different linking area for each program segment. mkimage relocates a segment to the lowest available range of addresses of a suitable size within the linking area. mkimage guarantees that different segments relocated to the same linking area will never overlap. However, segments relocated to private linking areas can overlap.
For any particular segment you can specify whether the segment must be executed at its place within the memory bank (in this document this segment is refered to as the "XIP segment") or whether it must be copied into the RAM before it is executed.
The mkimage command builds a binary file called bootconf. The bootconf file contains a data structure called BootConf, which describes the system image contents and layout. mkimage includes the bootconf binary file in one of the system image memory banks.
The initial loader boots the ChorusOS operating system, jumping to the entry point of the bootconf binary (see "Overview" for more details).
bootconf is a board-independent program that gets control from the board-specific initial loader and transfers control to the board-specific bootstrap program. In some cases, the initial loader needs to pass a board-dependent parameter to the bootstrap. This parameter can be loaded into a specific CPU register, and bootconf passes the entry value of the register to the bootstrap program as an opaque parameter. The register is:
When the bootconf binary is entered, it sets up a program stack in a stack area within its data segment, finds the descriptor of the bootstrap binary in the BootConf structure, and jumps to this entry point, passing the following parameters:
The address of the BootConf structure
An opaque value from the initial loader
To jump to the bootstrap entry point, bootconf uses the standard C function invocation conventions. The bootstrap entry point is:
typedef void (*BootEntry) (struct BootConf*, void* cookie);
The bootconf file contains an object of type BootConf and all the objects it points to. It describes the structure of the system image in terms of its components.
typedef struct BootConf { unsigned int stamp; /* identification stamp */ PhMap* kernelSpace; /* initial address space descriptor */ VmAddr spaceBarrier; /* frontier between user and supervisor address space */ int numBanks; /* number of system image memory banks */ BankDesc* bankDesc; /* system image memory bank descriptors */ int numBins; /* number of binaries */ BinDesc* binDesc; /* array of binary descriptors */ int numSegs; /* number of segments */ BinSegDesc* segDesc; /* array of segment descriptors */ RamDesc ramAllocator; /* ram occupation */ KnSymbolTable* symbols; /* symbols for kdb */ EnvDesc* env; /* environment descriptor */ void* heapStart; /* memory heap: */ void* heapCur; /* occupied from heapStart to heapCur */ void* heapLimit; /* available from heapCur to heapLimit */ unsigned int siteNumber; /* site number used for remote IPC */ DevNode rootDevice; /* device tree */ IdleFunc idleFunc; /* function to be executed in the idle loop */ DbgBsp dbgBsp; /* bsp for Debug Agent */ DbgOps dbgOps; /* debug Agent interface */ BootConfRebootEntry rebootEntry; /* reboot entry */ RebootDesc* rebootDesc; /* reboot descriptor */ void* f_bootConf; /* a processor-specific descriptor */ } BootConf;
Code Example 7-11 contains an example of a BootConf structure.
The kernelSpace field describes the initial address space. The exact interpretation of this descriptor is architecture dependent:
In some cases, kernelSpace describes the address space which must be established in the hardware when entering the microkernel.
In other cases, kernelSpace describes the address space which must be established by the microkernel's memory management module.
Some architectures do not require kernelSpace at all (for example when there is no MMU).
Other architecture-dependent requirements for the initial address space layout may be specified. See "The Boot-Kernel Interface" for details.
If required, the initial virtual address space is specified by the PhMap structure:
typedef struct PhChunk { PhAddr start; /* chunk physical start address */ PhSize size; /* chunk size in bytes */ unsigned int tag; /* chunk attributes */ } PhChunk; typedef struct PhMap { int numChunks; /* number of items in the array */ PhChunk* chunk; /* array of chunk descriptors */ } PhMap;
PhMap and PhChunk
are declared in source_dir/nucleus/sys/common/src/kern/bki/phMap.h and source_dir/nucleus/sys/common/src/kern/bki/phChunk.h respectively. The PhMap structure is
a series of PhChunk
entries, each entry describing the virtual-to-physical
translation of a contiguous range of virtual addresses. The size field of
a PhChunk
descriptor indicates the size of the range. The starting
address of the range is given by the sum of the size values of the previous
ranges. Therefore, the PhMap structure must describe
the entire virtual address space.
If the tag value in PhChunk
is equal to KSP_INVALID the translation is invalid and
access to any address in the range described by PhChunk
is prohibited.
Otherwise, the start field of a PhChunk
structure gives the starting address of the physical address range
that the virtual address is mapped to. The tag
field of a PhChunk structure specifies the attributes
associated with the mapping. The highest 24 bits of tag are used to store architecture-dependent attribute sets,
such as memory access rights and cache control. See "The Boot-Kernel Interface"
for details of architecture-specific BKI. The lowest 8 bits are reserved for
use by the microkernel, and are set to 0 by mkimage.
The value of the spaceBarrier field may influence the dimensions of the supervisor and the user virtual address spaces. The exact meaning of this field is architecture dependent.
The bankDesc structure points to an array of BankDesc
system image memory
bank descriptors.
typedef struct BankDesc { char* id; /* bank's symbolic name */ BankType type; /* bank's type */ char* fs; /* files system type symbolic name */ VmAddr vaddr; /* address required for the bank's image */ VmSize size; /* bank's size */ } BankDesc;
The bankDesc structure is declared in source_dir/nucleus/sys/common/src/kern/bki/bki.h. A memory bank is specified by vaddr, indicating the starting address within the initial address space, and size.
The type field value is a combination of the bits listed in Table 7-1.
Table 7-1 type Bitstype Bit | Meaning |
---|---|
BANK_KSP | always "1" in this version |
BANK_DEVICE | bank is a memory device |
BANK_DEVICE_READ | data from the memory device can be read |
BANK_DEVICE_WRITE | data from the memory device can be modified |
BANK_DEVICE_EXEC | instructions from the memory device can be executed |
If any of the last three bits is set, the BANK_DEVICE bit must also be set.
Files in a memory bank can be organized as a volume of a file system. In this case, the fs field points to a string containing the name of the file system type (for example, "FAT" stands for MS-DOS FAT file system). Otherwise, fs is 0.
When the initial loader jumps to the bootconf entry point, the memory banks containing the BIN_BOOTCONF and BIN_BOOTSTRAP program binaries must already be installed at the address indicated by vaddr.
When the bootstrap program transfers control to the microkernel, all memory banks must be installed at the address indicated by vaddr.
The binDesc array points to an array of BinDesc
structures. Each structure describes an absolute executable binary
involved in the system deployment procedure, such as a bootconf,
bootstrap, microkernel, or a driver. These binaries are part of the system
image.
typedef struct BinDesc { char* name; /* binary symbolic name */ int firstSeg; /* first segment index */ int lastSeg; /* last segment index */ KnPc entry; /* binary entry point */ BinType type; /* binary type */ BinMode mode; /* binary loading mode */ void* actor; /* private for the u-kernel */ } BinDesc;
Each binary is composed of a set of segments. The firstSeg and lastSeg fields specify the range
of segments within the array of segment descriptors, pointed to by segDesc, that store the binary described by BinDesc
.
The type field specifies the binary's type and is set to one of the binType values listed in Table 7-2.
Table 7-2binType
ValuesBinType Value | Type of Binary |
---|---|
BIN_BOOTCONF | bootconf program |
BIN_BOOTSTRAP | bootstrap program |
BIN_REBOOT | reboot program |
BIN_DBG_AGENT | system debug agent |
BIN_DBG_DRIVER | debug agent communication driver |
BIN_KERNEL | microkernel |
BIN_DRIVER | a ChorusOS device driver |
BIN_SUPERVISOR | a supervisor actor |
BIN_USER | a user actor |
BinType
values are defined in such a way that:
The BIN_STANDALONE bit is 1 in, and only in, BIN_BOOTSTRAP, BIN_DBG_AGENT, and BIN_DBG_DRIVER.
The BIN_ACTOR bit is 1 in, and only in, BIN_DRIVER, BIN_SUPERVISOR, and BIN_USER.
The BIN_KERNEL bit is 1 in, and only in, BIN_KERNEL.
The mode specifies the binary activation mode and can be any combination of the BinMode flags listed in Table 7-3.
Table 7-3BinMode
FlagsBinMode Flag | Meaning |
---|---|
BIN_DEBUGGED | The binary must be launched in debug mode. |
BIN_STOPPED | The binary must be loaded but not started. |
These flags only have meaning for BIN_SUPERVISOR and BIN_USER binaries. The value of mode is ignored for all other binary types.
The numBins field specifies the number of elements in the array pointed to by binDesc.
segDesc points to an array of segment descriptors.
Each item in the array is a SegDesc
data structure and describes
a segment of the system image. SegDesc is declared
in source_dir/nucleus/sys/common/src/kern/bki/bki.h.
typedef struct SegDesc { VmAddr kaddr; /* image address */ VmAddr vaddr; /* execution address (from link editor) */ VmSize ksize; /* image size */ VmSize vsize; /* execution size */ SegType type; /* code or data */ SegSpace space; /* address space type */ } SegDesc;
The descriptor specifies two things:
The location of the segment's image
Where the segment must be installed for execution
The segment image is stored in the memory bank containing the segment's binary. When the memory bank is installed at the required address, as specified in the BankDesc structure, the segment image can be found at kaddr. The ksize field specifies the size of the segment image contained in the memory bank.
When executed, the segment must be installed at the address specified by the vaddr field and its size must be equal to vsize. If vsize is greater than ksize, the memory from vaddr+ksize to vaddr+vsize must be initialized to zero.
The space field indicates whether a segment belongs to the initial address space. It can be set to one of the values listed in Table 7-4.
Table 7-4SegSpace
ValuesSegSpace Value | Meaning |
SEG_KSP | segment belongs to the initial microkernel address space |
SEG_VIRTUAL | segment does not belong to the initial microkernel address space |
Only binaries of the BIN_ACTOR type can hold SEG_VIRTUAL segments.
The value of the type field can be any combination of the bits listed in Table 7-5.
Table 7-5 SegType Bit ValuesSegType Bit | Meaning |
---|---|
SEG_XIP | Segment must be executed at its place in the memory bank |
SEG_EXEC | Segment contains instructions |
SEG_READ | Segment contains read-only data |
SEG_WRITE | Segment contains write data |
If a segment is executable in place (XIP), and belongs to the initial kernel address space (for example, the SEG_XIP bit is set in the type field and the space field is equal to SEG_KSP), the segment's execution address will be the same as the segment's image address and the segment's execution size will be equal the segment's image size. Therefore, when a memory bank is installed at the address specified by its descriptor (BankDesc::vaddr), all XIP KSP segments that belong to the memory bank will have no particular installation procedure and will be ready for execution.
The numSegs field specifies the number of
elements in the array pointed to by SegDesc
.
The ramAllocator field describes RAM occupation by the system image. The mkbootconf tool initializes the ramAllocator state. It tags as allocated the memory dedicated to:
All RAM based system image memory banks (see "Banks").
Global system control blocks (for example CpuContext
and ChorusContext
) that are mapped to non-virtual linking
areas (see "Areas").
All non-XIP segments (XIP segments are contained in memory banks) that are mapped to non-virtual linking areas (see "Areas").
The ChorusOS operating system provides a library of functions to manipulate
the RamDesc
objects (see "RAM Allocator interface"). RamDesc is declared in source_dir/nucleus/sys/common/src/kern/bki/ram.h. These functions allow the bootstrap program to tag any range
of physical addresses with an attribute.
The env field points to an EnvDesc structure. The EnvDesc structure is declared in source_dir/nucleus/sys/common/src/lib/util/env.h.
typedef struct EnvDesc { int envSize; /* current size of environment */ int envMaxSize; /* memory available for environment */ char* envPtr; /* pointer to the environment */ } EnvDesc;
The system image contains a data file with the initial state of the system environment variables. The env field of the BootConf structure references the contents of this file.
The envPtr field points to a sequence of environment variable definitions. Each definition is a concatenation of two strings, envVariable and envValue, where envVariable is the null-terminated string name of an environment variable, and envValue is the null-terminated string value of the environment variable.
The envSize field is the size in bytes of the environment variable definition sequence.
The envMaxSize field is the environment file size. It must not exceed envMaxSize.
The heapStart field points to the beginning of a block of statically allocated memory. The block can be used by the bootstrap program for dynamic memory allocation. For instance, the heap is used by the device tree library memory allocator (see "Initial Device Tree") to build the initial state of the board's device tree.
The heapCur field points to the first byte available for future allocation. The mkbootconf tool sets heapCur to heapStart.
The heapLimit field points to the heap memory limit. The size of the heap memory is equal to heapLimit-heapStart.
The heap is also used for the initial stack. The bootconf start-up procedure initializes the current stack pointer with the heapLimit value.
All other fields of the BootConf structure are initialized dynamically during the system bootstrap.
This section contains an example of a BootConf structure for the SBC8260 PPC8260 EC603e-based board.
#include bki/bki.h #include bki/f_bki.h PhChunk __mkimage__label__kernelSpace[] = { { 0x0, 0x1000000, KSP_PPC60x_BAT|KSP_PPC60x_M|KSP_PPC60x_RW }, { 0x0, 0xe000000, KSP_INVALID }, { 0xf000000, 0x20000, KSP_PPC60x_BAT|KSP_PPC60x_G|KSP_PPC60x_I| KSP_PPC60x_RW }, { 0x0, 0xecfe0000, KSP_INVALID }, { 0xfc000000, 0x4000000, KSP_PPC60x_BAT|KSP_PPC60x_RO } }; BankDesc __mkimage__label__banks[] = { { "sys_bank", BANK_KSP, 0, 0x100000, 0xb3000} }; BinDesc __mkimage__label__binDesc[] = { { "dbgBsp", 0, 0, 0x10042c, BIN_DBG_DRIVER, 0 | 0 }, { "dbgAgent", 1, 1, 0x104494, BIN_DBG_AGENT, 0 | 0 }, { "boot", 2, 2, 0x108000, BIN_BOOTSTRAP, 0 | 0 }, { "reboot", 3, 3, 0x10d27c, BIN_REBOOT, 0 | 0 }, { "kern", 4, 5, 0x125418, BIN_KERNEL, 0 | 0 }, { "D_tbDec", 6, 6, 0x186000, BIN_DRIVER, 0 | 0 }, { "D_quicc8260", 7, 8, 0x188000, BIN_DRIVER, 0 | 0 }, { "D_fccEther", 9, 9, 0x18e000, BIN_DRIVER, 0 | 0 }, { "PD", 10, 11, 0x195000, BIN_SUPERVISOR, 0 | 0 }, { "kernonly_symb", 12, 12, 0x198000, BIN_DBG_AGENT, 0 | 0 }, { "kernonly_bconf", 13, 13, 0x1b0000, BIN_BOOTCONF, 0 | 0 } }; BinSegDesc __mkimage__label__segDesc[] = { { 0x100000, 0x100000, 0x608, 0x608, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x101000, 0x101000, 0x6234, 0x6234, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x108000, 0x108000, 0x4358, 0x4358, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x10d000, 0x10d000, 0x2200, 0x2200, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x110000, 0x110000, 0x75920, 0x75920, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x186000, 0x8000, 0x0, 0x1a000, SEG_READ | SEG_WRITE, SEG_KSP }, { 0x186000, 0x186000, 0x1be4, 0x1be4, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x188000, 0x188000, 0x50dc, 0x50dc, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x18e000, 0x22000, 0x0, 0x10, SEG_READ | SEG_WRITE, SEG_KSP }, { 0x18e000, 0x18e000, 0x6654, 0x6654, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x195000, 0x195000, 0x22c4, 0x22c4, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x198000, 0x23000, 0x0, 0xc04, SEG_READ | SEG_WRITE, SEG_KSP }, { 0x198000, 0x198000, 0x170c8, 0x170c8, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0x1b0000, 0x1b0000, 0x2c10, 0x2c10, SEG_XIP | SEG_EXEC | SEG_READ | SEG_WRITE, SEG_KSP }, { 0, 0, 0, 0, 0, 0 }, { 0, 0, 0, 0, 0, 0 } }; PhChunk __mkimage__label__ramChunks[64] = { { 0x0, 0x4000, PH_RAM_NONEXISTENT }, { 0x4000, 0x20000, PH_RAM_ALLOCATED }, { 0x24000, 0xdc000, PH_RAM_NONEXISTENT }, { 0x100000, 0xb3000, PH_RAM_ALLOCATED }, { 0x1b3000, 0xffe4d000, PH_RAM_NONEXISTENT } }; EnvDesc __mkimage__label__environ = { 0x0, 0x0, (char*) 0x100000}; int heapSize = 0x2000; char heap[0x2000]; BootConf __mkimage__label__bootConf = { 0x38216b39, 0, { 5, __mkimage__label__kernelSpace }, 0x0, 1, __mkimage__label__banks, 11, __mkimage__label__binDesc, 14, __mkimage__label__segDesc, { 64, 5, __mkimage__label__ramChunks }, 0, &__mkimage__label__environ, heap, heap, heap + 8192, }; BootConf* bootConf= &__mkimage__label__bootConf;
The kernelSpace field of the BootConf structure contains the description of the kernel address space that must be established by the microkernel's memory management module.
The descriptor specifies that the first 16M of the physical address space, which corresponds to RAM potentially available on the board, must be mapped to the first 16M of the virtual address space using one Block Address Translation register pairs (IBAT and DBAT). The space must be mapped read/write enforcing memory coherency (that is, the memory control bit M must be set in the BATs).
Another pair of BATs must be used to map to the virtual address range from 0x0f000000 to 0x0f020000. These are the PPC8260 internal memory mapped registers which occupy the physical addresses from 0xf000000 to 0x0f020000. The space must be mapped read-only, bypassing the memory cache.
The system image is stored in one memory bank that must be installed at the address 0x00100000. The size of the bank is 0x00b3000 bytes.
A third pair of BATs must be used to map the last 64M of the physical address space, which corresponds to ROM (FLASH) potentially available on the board. This space must be mapped read-only.
The system image contains 11 binaries:
dbgAgent and dbgBsp are the system level debug agent and its BSP
boot is the bootstrap program
reboot is the reboot program
kern is the microkernel
D_* are the driver binaries
PD is the per-actor/thread data manager system actor
kernonly_symb is the KDB symbol table
kernonly_bconf is the bootconf binary
Some binaries (for example, boot) have just one XIP segment which includes all text and data. Others (for instance, kern) have zero-initialized data (bss), link-edited in a separate segment.
The RAM allocator specifies that the RAM from address 0x00004000 to address 0x00024000 and from address 0x00100000 to address 0x001b3000 is allocated. The memory from 0x00100000 to 0x001b3000 is occupied by the system image memory bank, and the memory from 0x00004000 to 0x00024000 by the system control blocks and bss.