The GNU toolchain and ARM toolchain have different approaches for handling the program's linking and loading.
A program have several sections for code and data. Normally in ARM embedded system, before invoking a program's "main" function, code/data sections needs to be located at exact position of the memory as specified in the linking time.
An simple example explaining what is happening at the early phase of program running
- A program image is loaded in to DRAM, each sections in the image are in their loading address now. The ARM toolchain call it loading address, GNU toolchain call it LMA(loading memory address), I will call it LMA now on.
- The next step is to make each section in the image to be relocated to their execution address as specified in the linking time. ARM toolchain calls it execution address. GNU toolchain call it VMA(virtual memory address), I will call it VMA from now on.
ARM toolchain using Scatter-loading mechanism to get section from LMA to VMA. For details, see http://wikigu.blogspot.jp/2017/01/arm-scatter-file-explain.html
One thing needs to be noted here is that, each section in ARM toolchain generated AXF file(ELF format) has the same LMA and VMA. The actually LMA/VMA mapping information is in linker generated InRoot$$Section. When ARM library function "__main" function is called, the section are copied from LMA to VMA according to info in InRoot$$Section.
GNU toolchain does not have similar Scattering-loading mechanism as the ARM. The LMA and VMA specified in the linker file are actually put in the ELF's header information. The LMA information is actually in the ELF's programmer's p_paddr.
The startup code of the image is responsible for copying the section from the LMA to VMA. There is no library function call provided by toolchain to do that.
Below is a good example.
https://www.embedded.com/design/mcus-processors-and-socs/4026075/Building-Bare-Metal-ARM-Systems-with-GNU-Part-2
https://www.embedded.com/design/mcus-processors-and-socs/4026080/Building-Bare-Metal-ARM-Systems-with-GNU-Part-3
2018/02/01
Handling of Data Section In Image
ARM Linker
RW section is compressed in image the decompressed at loading.
http://www.keil.com/support/man/docs/armlink/armlink_pge1362065930871.htm
RW data areas typically contain a large number of repeated values, such as zeros, that makes them suitable for compression.
RW data compression is enabled by default to minimize ROM size.
The linker compresses the data. This data is then decompressed on the target at run time.
RW section is compressed in image the decompressed at loading.
http://www.keil.com/support/man/docs/armlink/armlink_pge1362065930871.htm
RW data areas typically contain a large number of repeated values, such as zeros, that makes them suitable for compression.
RW data compression is enabled by default to minimize ROM size.
The linker compresses the data. This data is then decompressed on the target at run time.
Subscribe to:
Posts (Atom)
-
Explain There is not interrupt PIN for PCIe interrupt. When device wants to raise an interrupt, an interrupt message is sent to host via ... -
Configure Space Addressing One of the major improvements the PCI Local Bus had over other I/O architectures was its configuration mechanism... -
What is LMA and VMA Every loadable or allocatable output section has two addresses. The first is the VMA, or virtual memory address. This ...
