In linker scripts, I can get the LMA of a section like this
.got : ALIGN(4)
{
__global_offset_table_flash_start__ = LOADADDR(.got) ;
...
} >SRAM_DTC AT>PROGRAM_FLASH
When I use
.got : ALIGN(4)
{
__global_offset_table_flash_start__ = . ;
...
} >SRAM_DTC AT>PROGRAM_FLASH
or
.got : ALIGN(4)
{
__global_offset_table_flash_start__ = ABSOLUTE(.) ;
...
} >SRAM_DTC AT>PROGRAM_FLASH
it will give the VIRTUAL memory address. Where I thought the ABSOLUTE would give the LMA, but it doesn't.
Is there also a way to get the current LOAD memory address for . ?
Only workaround I can figure out is adding a section which only goes to flash.
.dummy :
{
__global_offset_table_flash_start__ = .;
} > PROGRAM_FLASH
As far as I can find in the documentation, there is no way to get the "current" load address
Related
I am working on baremetal application for an MSP430 MCU from TI. This MCU uses FRAM, a non volatile memory. The following script for SRAM works well:
SECTIONS {
__data_load_start = .;
.data : AT ( __data_load_start )
{
. = ALIGN(2);
__data_start = .;
*(.data*)
__data_end = .;
} >RAM
}
__data_load_start gets the load memory address in flash (implicitly?), and reserves some space in RAM.
Now, I want to use it for non volatile memory. This memory zone, under certain circumstances will be re-initialized to their initial value, so the Load Address (LMA) and Virtual Address (VMA) will be different, as explained in the ld documentation.
SECTIONS {
__nvdata_load_start = .;
.NVdata : AT ( __nvdata_load_start ) {
. = ALIGN(2);
__nvdata_start = .;
*(.nvdata*)
__nvdata_end = .;
} >FRAM
However, it doesn't work. A look to the .map output file shows that the load address has been set out of any memory section :/
.NVdata 0x0000000000004400 0x4 load address 0x0000000000010000
I would like to specify explicitly the location of the initial value of this memory region. Do anyone can help?
EDIT:
I have tried to update the script not to have any implicit rule:
SECTIONS {
.NVdata : AT ( __nvdata_load_start ) {
. = ALIGN(2);
__nvdata_start = .;
*(.nvdata*)
__nvdata_end = .;
} >FRAM
.NVdataInit : {
. = ALIGN(2);
__nvdata_load_start = .;
/* reserve space for non volatile data init value */
. += SIZEOF(.NVdata);
} >FRAM
}
But in this case, each section that is declared after gets an offset between the VMA and LMA. For instance, the section that just follows gives (.map file):
.textInit 0x0000000000004408 0x416 load address 0x000000000000440c
But both adresses should be same :/
I found a workaround.
When I have declared the section .NVdata and .NVdataInit (just above), there was an offset between the LMA and VMA and the binary code was incorrect.
In the section that just follows, I have forced LMA and VMA to be the same:
SECTIONS {
/* we make sure that both
* - VMA (virtual memory address) and
* - LMA (load memory address)
* are the same */
.textInit __nvdata_load_end : AT(__nvdata_load_end) {
KEEP(*(.init)) /* start here after reset */
} > FRAM
}
It now works perfectly, even if I don't understand why this offset has appeared :/
I have a bootloader program "boot.asm" which must contains a special word at an offset of 510 bytes from the beginning. And I have a kernel source written in C "kernel.c".
My plan is to call the Kernel (which will be in the second sector of hd) by loading second sector of hard disk from the bootloader program and put it at location 0x8000 in memory.
Now I am compiling both the source files into ELF object files (separately) into "boot.o" and "kernel.o" and then linking them through a linker and outputting a raw binary file "kernel.bin" .
I want to put my bootloader code starting at 0x7c00 and then at the 0x7dfe location I have to put the special word. Then right at 0x8000 I have to place my kernel code. i.e I want to put respective sections of both the object files at different locations.
This is my failed attempt.
ENTRY(boot)
OUTPUT_FORMAT("binary")
SECTIONS{
. = 0x7c00;
.text :
{
*(.boot)
}
.sig : AT(0x7dfe){
SHORT(0xaa55);
}
. = 0x8000;
.text :
{
kernel.o(.text)
}
.rodata :
{
kernel.o(.rodata)
}
.data :
{
kernel.o(.data)
}
.bss :
{
kernel.o(.bss)
}
}
What I have understood is that an executable cannot have a section more than once.
I have limited knowledge about low level programming.
How do I solve this problem.
Thankyou.
You need to fix two things, don't split the .text output section, and use AT() to place the kernel immediately after the boot sector in the output binary while keeping its address at 0x8000. For example, a linker script something like this should work:
ENTRY(boot)
OUTPUT_FORMAT("binary")
SECTIONS {
. = 0x7c00;
.boot :
{
*(.boot)
}
. = 0x7dfe;
.sig : {
SHORT(0xaa55);
}
. = 0x8000;
.kernel : AT(0x7e00) /* place immediately after the boot sector */
{
*(.text)
*(.rodata)
*(.data)
_bss_start = .;
*(.bss)
*(COMMON)
_bss_end = .;
}
kernel_sectors = (SIZEOF(.kernel) + 511) / 512;
/DISCARD/ : {
*(.eh_frame)
}
}
I've added some stuff to handle sections you'll see in GCC compiled object files. The _bss_start and _bss_end symbols can be used to zero out the .bss section, and per Michael Petch's suggestion the kernel_sector symbol is set to the length of the kernel in 512 byte sectors.
I'm really confused by scatter files and the steps necessary to execute in RAM (for a bootloader).
From my understanding the startup.S file and sysinit need to be execute from Flash, and during that time the vector table needs to be copied over to RAM before jumping to main?
I also don't really understand the purpose of the scatter file, if I am copying the vectors and code to ram before jumping why do I even need it.
Here's my wrong scatter file:
LR_IROM1 0x14000000 0x00400000 { ; load region size_region
ER_IROM1 0x14000000 0x00400000 { ; load address = execution address
startup.o (RESET, +FIRST)
* (InRoot$$Sections)
}
RW_IRAM1 0x10000000 0x00020000 { ; RW data
*.o
}
RW_IRAM2 0x20000000 0x00010000 {
* (+RO,+RW,+ZI)
}
}
One solution for the bootloaders ram based linker script. Assuming you are using the gnu linker. There is more than one way to do this.
MEMORY
{
ram : ORIGIN = 0x20000000, LENGTH = 0x2000
}
SECTIONS
{
.text : { *(.text*) } > ram
.rodata : { *(.rodata*) } > ram
.bss : { *(.bss*) } > ram
.data : { *(.data*) } > ram
}
If your code requires .bss to be zeroed you can add more code to the linker script and more code to the bootstrap, but gnu will do this for you if you use the above and guarantee there is at least one byte of .data somewhere (it will pad .bss with zeros to get the .data item(s) in the right relative place when doing the objcopy to a binary). Your choice on how to solve that one though. If you dont need .bss zeroed then swap .data and .bss make the binary smaller. you are either copying zeros in a very very efficient loop, or writing zeros in a maybe as efficient loop if you work the alignments in the linker script.
the copy and jump side if it would only need something like this
MEMORY
{
rom : ORIGIN = 0x00000000, LENGTH = 0x2000
}
SECTIONS
{
.text : { *(.text*) } > rom
.rodata : { *(.rodata*) } > rom
}
worst case (for a simple assembly copy and jump), may be able to get rid of the .rodata line
The above are for gnu ld assuming that is what you are using, note that the memory names dont have meaning, you can instead do this:
MEMORY
{
bob : ORIGIN = 0x00000000, LENGTH = 0x2000
}
SECTIONS
{
.text : { *(.text*) } > bob
.rodata : { *(.rodata*) } > bob
}
or
MEMORY
{
joe : ORIGIN = 0x00000000, LENGTH = 0x2000
}
SECTIONS
{
.text : { *(.text*) } > joe
.rodata : { *(.rodata*) } > joe
}
or
MEMORY
{
pizza : ORIGIN = 0x00000000, LENGTH = 0x2000
}
SECTIONS
{
.text : { *(.text*) } > pizza
.rodata : { *(.rodata*) } > pizza
}
or
MEMORY
{
thehut : ORIGIN = 0x08000000, LENGTH = 0x2000
pizza : ORIGIN = 0x20000000, LENGTH = 0x2000
}
SECTIONS
{
.text : { *(.text*) } > thehut
.rodata : { *(.rodata*) } > thehut
.bss : { *(.bss*) } > pizza
.data : { *(.data*) } > pizza AT > thehut
}
you can attack things in the MEMORY or in the SECTIONS side with gnu ld. if you feel the need to have two .texts perhaps two .datas two .bss, etc (one for the copy/jump portion of the bootloader and one for the bootloader itself and have one linker script and link for all of the bootloader) you can do the this AT that thing or take the approach you are taking. But as well as the bootstrap for each being intimately connected to the linker script, you also have to use toolchain specific solutions to make the bootloader on ram fit into the proper .text/.bss, etc by either overriding them into some other (.my_bl_text...) or calling out object file names in the linker script or other solutions. Unfortunately the gnu linker script language has many features, and at the same time the documentation is more of a reference assuming you already know the language. Difficult to see how folks who have written elaborate linker scripts figured that out from the existing gnu documentation, and then trying to write your first one or modify someone elses. I recommend two programs the ram program and the copy jump program that contains the ram program as data.
I'm writing a bare metal ARM boot loader and am trying to use some internal SRAM as a scratch pad to communicate to the application code. For my needs I don't need to initialise or zero the memory. Using this script I can place my desired variables in the memory just fine.
/**
* Linker script for secondary bootloader.
*
* Allocatest the first 1Mb of DRAM for its use.
* Scratchpad in internal SRAM.
*/
MEMORY
{
SRAM : o = 0x402F0400, l = 0x0000FC00 /* 63kB available internal SRAM */
DDR0 : o = 0x80000000, l = 1M /* 1Mb external DDR Bank 0 */
}
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
SECTIONS
{
.startcode :
{
__AppBase = .;
. = ALIGN(4);
*init.o (.text)
} >DDR0
.text :
{
. = ALIGN(4);
*(.text*)
*(.rodata*)
} >DDR0
.data :
{
. = ALIGN(4);
*(.data*)
} >DDR0
.bss :
{
. = ALIGN(4);
_bss_start = .;
*(.bss*)
*(COMMON)
_bss_end = .;
} >DDR0
.stack :
{
. = ALIGN(4);
__StackLimit = . ;
*(.stack*)
. = __AppBase + 1M;
__StackTop = .;
} >DDR0
_stack = __StackTop;
.internal_ram :
{
. = ALIGN(4);
*(.internal_ram*)
} >SRAM
}
When using objcopy to create the raw binary, I'm getting huge files. I'm assuming this is because the first bytes of the raw binary are actually the internal memory with megabytes of padding up to the start of the .text section. Objdump -h shows that the internal_ram section being marked with the CONTENTS, LOAD, and DATA flags even though the variables placed there are not initialised.
I can clean this up in objcopy using --remove-section=.internal_ram but it seems there should be a way to get the linker to recognise that the data is not initialised.
Is there a way to mark the section appropriately?
The correct section declaration is:
.internal_ram (NOLOAD) :
{
. = ALIGN(4);
*(.internal_ram*)
} >SRAM
The NOLOAD section attribute is documented but speaks in terms of program loaders handling the section at load time. At first this doesn't seem to apply to bare metal images but, for that purpose, objcopy acts like a program loader and honors the flag settings in the object file, omitting the section from the raw image.
The other answer mentions this as well - the key is to make the section NOLOAD so that the data remains uninitialized.
The `(NOLOAD)’ directive will mark a section to not be loaded at run time. The linker will process the section normally, but will mark it so that a program loader will not load it into memory.
A quote from Ashley Duncan that you might find useful:
NOLOAD is useful in embedded projects for making sure a block of RAM is not initialised or zeroed. For example if you want the contents of that RAM to not lose its values during a software reset (e.g. if you want to set a variable with the reason you are resetting). Another useful application is to pass information from a boot loader to application without the application startup code overwriting the values of that memory area. Of course in this case both the boot loader and application linker files need to declare the exact same memory area location and size.
Some more explanation/story can be found here
I'm working on a university project where I'm writing software for an Atmel SAM7S256 microcontroller from the ground up. This is more in depth than other MCUs I've worked with before, as a knowledge of linker scripts and assembly language is necessary this time around.
I've been really scrutinizing example projects for the SAM7S chips in order to fully understand how to start a SAM7/ARM project from scratch. A notable example is Miro Samek's "Building Bare-Metal ARM Systems with GNU" tutorial found here (where the code in this question is from). I've also spent a lot of time reading the linker and assembler documentation from sourceware.org.
I'm quite happy that I understand the following linker script for the most part. There's just one thing involving the location counter that doesn't make sense to me. Below is the linker script provided with the above tutorial:
OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_vectors)
MEMORY { /* memory map of AT91SAM7S64 */
ROM (rx) : ORIGIN = 0x00100000, LENGTH = 64k
RAM (rwx) : ORIGIN = 0x00200000, LENGTH = 16k
}
/* The sizes of the stacks used by the application. NOTE: you need to adjust */
C_STACK_SIZE = 512;
IRQ_STACK_SIZE = 0;
FIQ_STACK_SIZE = 0;
SVC_STACK_SIZE = 0;
ABT_STACK_SIZE = 0;
UND_STACK_SIZE = 0;
/* The size of the heap used by the application. NOTE: you need to adjust */
HEAP_SIZE = 0;
SECTIONS {
.reset : {
*startup.o (.text) /* startup code (ARM vectors and reset handler) */
. = ALIGN(0x4);
} >ROM
.ramvect : { /* used for vectors remapped to RAM */
__ram_start = .;
. = 0x40;
} >RAM
.fastcode : {
__fastcode_load = LOADADDR (.fastcode);
__fastcode_start = .;
*(.glue_7t) *(.glue_7)
*isr.o (.text.*)
*(.text.fastcode)
*(.text.Blinky_dispatch)
/* add other modules here ... */
. = ALIGN (4);
__fastcode_end = .;
} >RAM AT>ROM
.text : {
. = ALIGN(4);
*(.text) /* .text sections (code) */
*(.text*) /* .text* sections (code) */
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
*(.glue_7) /* glue arm to thumb (NOTE: placed already in .fastcode) */
*(.glue_7t)/* glue thumb to arm (NOTE: placed already in .fastcode) */
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
_etext = .; /* global symbol at end of code */
} >ROM
.preinit_array : {
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(SORT(.preinit_array.*)))
KEEP (*(.preinit_array*))
PROVIDE_HIDDEN (__preinit_array_end = .);
} >ROM
.init_array : {
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array*))
PROVIDE_HIDDEN (__init_array_end = .);
} >ROM
.fini_array : {
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array*))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
} >ROM
.data : {
__data_load = LOADADDR (.data);
__data_start = .;
*(.data) /* .data sections */
*(.data*) /* .data* sections */
. = ALIGN(4);
_edata = .;
} >RAM AT>ROM
.bss : {
__bss_start__ = . ;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .; /* define a global symbol at bss end */
__bss_end__ = .;
} >RAM
PROVIDE ( end = _ebss );
PROVIDE ( _end = _ebss );
PROVIDE ( __end__ = _ebss );
.heap : {
__heap_start__ = . ;
. = . + HEAP_SIZE;
. = ALIGN(4);
__heap_end__ = . ;
} >RAM
.stack : {
__stack_start__ = . ;
. += IRQ_STACK_SIZE;
. = ALIGN (4);
__irq_stack_top__ = . ;
. += FIQ_STACK_SIZE;
. = ALIGN (4);
__fiq_stack_top__ = . ;
. += SVC_STACK_SIZE;
. = ALIGN (4);
__svc_stack_top__ = . ;
. += ABT_STACK_SIZE;
. = ALIGN (4);
__abt_stack_top__ = . ;
. += UND_STACK_SIZE;
. = ALIGN (4);
__und_stack_top__ = . ;
. += C_STACK_SIZE;
. = ALIGN (4);
__c_stack_top__ = . ;
__stack_end__ = .;
} >RAM
/* Remove information from the standard libraries */
/DISCARD/ : {
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
}
}
Throughout the example (such as in the .ramvect, .fastcode and .stack sections) there are symbol definitions such as __ram_start = .;. These addresses are used by the startup assembly code and initialization C code in order to initialize the correct locations in the MCU's RAM.
What I have a problem understanding, is how these symbol definitions result in the correct values being assigned. This does happen, the script is correct, I just don't understand how.
The way I understand it, when you use the location counter within a section, it only contains a relative offset from the virtual memory address (VMA) of the section itself.
So for example, in the line __ram_start = .;, I would expect __ram_start to be assigned a value of 0x0 - as it is assigned the value of the location counter at the very beginning of the .ramvect section. However, for the initialization code to work correctly (which it does), __ram_start must be getting assigned as 0x00200000 (the address for the beginning of RAM).
I would have thought this would only work as intended if the line was instead __ram_start = ABSOLUTE(.); or __ram_start = ADDR(.ramvect);.
The same goes for __fastcode_start and __stack_start__. They can't all be getting defined as address 0x0, otherwise the program wouldn't work. But the documentation linked here seems to suggest that that's what should be happening. Here's the quote from the documentation:
Note: . actually refers to the byte offset from the start of the current containing object. Normally this is the SECTIONS statement, whose start address is 0, hence . can be used as an absolute address. If . is used inside a section description however, it refers to the byte offset from the start of that section, not an absolute address.
So the location counter values during those symbol assignments should be offsets from the corresponding section VMAs. So those "_start" symbols should all be getting set to 0x0. Which would break the program.
So obviously I'm missing something. I suppose it could simply be that assigning the location counter value to a symbol (within a section) results in ABSOLUTE() being used by default. But I haven't been able to find a clear explanation anywhere that confirms this.
Thanks in advance if anybody can clear this up.
I think I may have figured out the answer to my own question. I'm not sure I'm right, but it's the first explanation I've been able to think of that actually makes sense. What made me rethink things was this page of the documentation. Particularly this quote:
Addresses and symbols may be section relative, or absolute. A section
relative symbol is relocatable. If you request relocatable output
using the `-r' option, a further link operation may change the value
of a section relative symbol. On the other hand, an absolute symbol
will retain the same value throughout any further link operations.
and this quote:
You can use the builtin function ABSOLUTE to force an expression to be
absolute when it would otherwise be relative. For example, to create
an absolute symbol set to the address of the end of the output section
.data:
SECTIONS
{
.data : { *(.data) _edata = ABSOLUTE(.); }
}
If ABSOLUTE were not used, _edata would be relative to the .data
section.
I had read them before, but this time I saw them from a new perspective.
So I think my misinterpretation was thinking that a symbol, when assigned a relative byte offset address, is simply set to the value of that offset while the base address information is lost.
That was based on this quote from my original question:
Note: . actually refers to the byte offset from the start of the
current containing object. Normally this is the SECTIONS statement,
whose start address is 0, hence . can be used as an absolute address.
If . is used inside a section description however, it refers to the
byte offset from the start of that section, not an absolute address.
Instead what I now understand to be happening is that the base address information is not lost. The symbol does not simply get assigned the value of the offset from the base address. The symbol will still eventually resolves to an absolute address, but only when there's no chance its base address can change.
So where I thought that something like __stack_start__ = . ; should have to be changed to __stack_start__ = ABSOLUTE(.) ;, which does work, I now think it is unnecessary. What's more, I understand from the first quote in this response that you can relink an ELF file?
So if I used __stack_start__ = ABSOLUTE(.) ;, ran the linker script to create the ELF executable, then tried to relink it and moved the .stack section somewhere else, the __stack_start__ symbol would still be pointing to the same absolute address from the first link, and thus be incorrect.
This is probably hard to follow, but I've written it as articulately as I could. I suspect I've got close to the right idea, but I still need someone who actually knows about this stuff to confirm or deny this.
The placement of the section is determined by the memory region after the closing brace (>RAM AT>ROM). So the execution address is in RAM at 0x00200000 and following, but the load address is in ROM (flash) at 0x00100000. The startup code must copy the .fastcode output section from its load to its execution address, that's what the symbols are for.
Note that these need not be at address 0, because the AT91SAM7S remaps either RAM or ROM to address 0. Usually it starts up with ROM mapped, and the startup code switches that to RAM.
This question also troubled me, Give my understanding：
.ramvect : { /* used for vectors remapped to RAM */
__ram_start = .;
. = 0x40;
} >RAM
The above statement tells the linker to place the __ram_start symbol at location counter, that is at the start of the .ramvect segment.
Since the __ram_start symbol is located at the head of the .ramvect segment, when the C code is used to get the __ramvect address, it will get the starting address of the.ramvect segment, i.e. its absolute address.