| R/W | Contains uninitialized data larger than 64KB | ||
| .data | 512KB | R/W | Contains initialized data larger than 64KB |
| _monitor | 54KB | RD | Contains the monitor code |
| .text | 512KB | RD | Contains other program code |
One possible allocation is shown in Listing 2.5; it considers why an embedded engineer might want greater section allocation control.
Listing 2.5: Possible section allocation.
MEMORY {
ROM: origin = 0x00000h, length = 0x000100h
FLASH: origin = 0x00110h, length = 0x004000h
RAMB0: origin = 0x05000h, length = 0x020000h
RAMB1: origin = 0x25000h, length = 0x200000h
}
SECTION {
.rodata: › ROM
_loader: › FLASH
_wflash: › FLASH
_monitor: › RAMB0
.sbss (ALIGN 4): › RAMB0
.sdata (ALIGN 4): › RAMB0
.text: › RAMB1
.bss (ALIGN 4): › RAMB1
.data (ALIGN 4): › RAMB1
}
This program allocation is shown in Figure 2.8. The section allocation strategies applied include the following:
· The .rodata section contains system initialization parameters. Most likely these default values never change; therefore, allocate this section to ROM.
· The loader program is usually part of the system program that executes at startup. The _loader and the _wflash sections are allocated into flash memory because the loader code can be updated with new versions that understand more object formats. You need the flash memory programmer for this purpose, which can also be updated. Therefore, section _wflash is allocated into the flash memory as well.
· The embedded programmer interacts with the monitor program to probe system execution states and help debug application code; therefore, it should be responsive to user commands. SDRAM is faster than DRAM, with shorter access time. Therefore, section _monitor is allocated into RAMB0.
· RAMB0 still has space left to accommodate both sections.sbss and.sdata. The allocation strategy for these two sections is to use the leftover fast memory fully.
· The remaining sections (.text, .bss, and .data) are allocated into RAMB1, which is the only memory that can accommodate all of these large sections.
Figure 2.8: Mapping an executable image into the target system.
2.5 Points to Remember
Some points to remember include the following:
· The linker performs symbol resolution and symbol relocation.
· An embedded programmer must understand the exact memory layout of the target system towards which development is aimed.
· An executable target image is comprised of multiple program sections.
· The programmer can describe the physical memory, such as its size and its mapping address, to the linker using the linker command file. The programmer can also instruct the linker on combining input sections into output sections and placing the output program sections using the linker command file.
· Each program section can reside in different types of physical memory, based on how the section is used. Program code (or.text section) can stay in ROM, flash, and RAM during execution. Program data (or.data section) must stay in RAM during execution.
Chapter 3: Embedded System Initialization
3.1 Introduction
It takes just minutes for a developer to compile and run a “Hello World!” application on a non-embedded system. On the other hand, for an embedded developer, the task is not so trivial. It might take days before seeing a successful result. This process can be a frustrating experience for a developer new to embedded system development.
Booting the target system, whether a third-party evaluation board or a custom design, can be a mystery to many newcomers. Indeed, it is daunting to pick up a programmer’s reference manual for the target board and pore over tables of memory addresses and registers or to review the hardware component interconnection diagrams, wondering what it all means, what to do with the information (some of which makes little sense), and how to relate the information to running an image on the target system.
Questions to resolve at this stage are
· how to load the image onto the target system,
· where in memory to load the image,
