Executing from RAM ARM Cortex M4 - c

Question

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)
}
}

Answer 1

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.