I have an embedded system with flash storage. The program is stored in flash. I have a function that calculates the checksum of the .text section of flash where my non volatile code is stored. I would like to compare the computed checksum with a value fixed and known at compile time stored in flash. I made a new flash section in the linker. I want to fill it with 0xABCD, which is the checksum. How can I do this in the linker? The compiler is GCC
The code that you are check-summing is generated by the linker, so getting the linker to generate it directly in one pass is not possible.
A simpler approach perhaps is to simply reserve the checksum storage area in the linker script unprogrammed (0xFFFF) and the add then calculate and add the checksum post-link using a tool such as the SRecord utilities. Essentially doing what your PROM burner (mentioned in comment) used to do.
Related
I am working on a project which contains of subset of code which needs to be validated from flash at runtime with a CRC value. This code is placed into its own section of flash using the linker and during build the CRC value is calculated and injected into the appropriate area of memory. Then at runtime the flash is read and CRCed and compared to the stored value. This is all working correctly and as intended.
The code which is placed into this special section of flash is considered critical which is why it needs to be verified periodically as correct at runtime. The CRC value is also supposed to be used to validate that no changes were made to the critical section from version to version. This is what is not working as expected.
When the changes to non-critical sections of code are made (for example things placed into the normal .text region of flash) there are small differences in the critical code. Upon examining the changes it appears that most, perhaps all, of the changes are due to external function/variable references which are not in the critical code section of flash. This of course makes sense because the linker will be inserting the calls to other functions wherever they might get placed in flash which of course can change.
Is it possible to force the linker to make references to external functions/variables static in this section of flash? I was thinking this could be accomplished with some kind of lookup table which contained virtual memory/function addresses and then actual memory/function addresses and the critical code section would only reference the virtual addresses?
You don't say what CPU you are using, but suppose you want to call routine do_stuff from your critical section, with signature int do_stuff(int a, intb). Then you need a header in your critical section:
int tramp_do_stuff(int a, int b);
and an assembly file with a trampoline for each function in your normal section:
.org 7ffff00H ;; however you specify a fixed address in your asm
_tramp_do_stuff: ;; this address is fixed
JMP do_stuff ;; This address gets set by linker
_tramp_next_trampoline:
I am beginning to learn to write some low-level software for micro-controllers, and I've started studying linker scripts.
I don't really get the meaning of the ENTRY command in this context. Since most micro-controllers start execution at a predetermined address, what difference does it make which entry point we choose in the linker script?
ENTRY() is an ELF feature that basically just sets the program entry address in the ELF header of your executable. This address may differ from the start address of the first executable segment of your binary (which would be the default execution address if you didn't define ENTRY()).
Whether this information is used (i.e. whether start of execution happens at the first code segment address or at ENTRY()) is out of control of the linker as it entirely depends on the availability and features of your ELF loader.
As you usually do not have such thing on a microcontroller, ENTRY() is practically useless there and you might as well omit the statement at no consequence.
The entry point defines the starting point of your program. This is of course very good information to have. This way flash tools know where to flash your code and also debug tools know where your symbols are at.
I am using gcc to compile some code for an ARM Cortex-M4F microcontroller. My application uses a large collection of data that I have conveniently written into a C file: large arrays of ints and floats, circular linked lists pointing to those various arrays, various structs, that sort of thing.
When I compile this it adds up to about 500K of data, plus a few hundred K for the actual application. gcc is putting all this data conveniently into the .data section; ld then tries to build the elf putting the .data section into RAM and .text (code) section into FLASH. The mcu I am using doesn't have 500K of RAM so it cannot build the ELF, but it does have 1M of FLASH. I tried changing my linker script so that both .data and .text are put into FLASH which "worked" but there are some other bit of code that expect its data to go into RAM, so ultimately execution failed; I can't make that sweeping change.
What I need is to tell gcc to put every single object in this C file into the .text section so it can go into FLASH with the rest of the non-mutable stuff, or at least some other section which I can then instruct my linker script what to do with so that it doesn't interfere with existing blobs that have no problem fitting in RAM. I don't know how to do that. Here is a very slimmed down example of what I have
/* data.c */
static char* option_array_0_0[] =
{
"O=0.40",
"K=FOO",
"JAR=JAR",
};
static int width_array_0_0[] =
{
0,
1,
1,
};
Window window_array_0[] =
{
{
option_array,
width_array,
},
};
/* main.c */
extern Window window_array_0[];
int main()
{
/* Do stuff */
}
The stuff in data.c, window_array_0 and everything (or most everything, maybe the string arrays are going to .text?) it links to, is being put in .data which my linker script puts into RAM. I want it all in a different section which I can then put into FLASH. There are thousands of these types of arrays in there, plus hundreds of structs and dozens of other bits of information. Is this possible to change? As a test I replaced my "window_array_0" with a char[500000] of random data and that compiled without complaint so I assume it put it all into .text (as would be expected), I just don't know how to make it do so for arbitrary objects.
Thanks for your help.
As other commenters pointed, 'static const' items usually end up in .rodata section which is likely to be placed right next to .text in potentially read-only memory. The caveat is that it may or may not be true in your case as that is specific to particular target and may be changed by particular build process (i.e. linker options, specific section specified via __attribute__((section("name"))) in C code, linker script, binaries tweaked after build with various binutils, etc).
If you need to have precise control over in-memory layout and you know what you're doing, you can use LD script to do it. Among other things it will let you specify that .rodata from file data.o should be placed just before/after .text from all other .o files linked into the executable.
You can use arm-<your toolchain variant>-ld -verbose to dump default linker script and use it as a starting point for tweaking.
Most compilers/linkers, if you declare a variable as static const, it will place it in the text section instead of data. Obviously, these must be preinitialized and not modified at run-time, but that's the only way it makes sense to go in flash.
Somewhere in the code (.text section) put like a sample:
__attribute__((section(".text")))
const int test[0x0A] = {0,0,0,0,0,0,0,0,0,0};
or without const if you want a variable to change:
__attribute__((section(".text")))
int test[0x0A] = {0,0,0,0,0,0,0,0,0,0};
Then try changing it:
test[0] = 0xffffffff;
This works on my Linux 32 intel machine.
IIRC, code in flash is usually required to be ROPI (read only position independent). So option_array_0_0 and width_array_0_0 would need const qualifiers (read only). However:
Window window_array_0[] =
{
{
option_array,
width_array,
},
};
needs to be changed somehow (I'm assuming option_array and width_array are indeed arrays). That makes window_array_0 not position independent.
All non-trivial embedded projects shall have a linker script. It defines where different symbols (function, global variables, debug symbols, ...) shall be placed in memory. Here is some tutorial about gcc linker script.
forcing all data to be placed in one section might not be the best solution!
NOTE: Since these arrays are NOT constants, it doesn't make sense to store them in data section! because this means you will end up over-writing code section by you code (which is PRETTY dangerous). Either make them const or create a no-init section which is not initialized by the loader, and you initialize it on reset.
I am programming an ARM Cortex-R4 and I have a few binary files that I'd like to execute them from TCRAM, just to see if the increase in performance is good enough.
I know I'd have to write a function to copy the binaries to the RAM (which can be accomplished with the linker script, and knowing the size of the binaries). But how would they run?
Imagine this: The first binary has func1(), func2(), func3() and func4(). I'd copy the entire module to TCRAM and how would I call a function there? I'd have to use a function pointer to that specific function? And what if func4(), calls func2() and func3()? If I'm not mistaken they'd point to the piece of code located in the flash. Does that mean I'd have to re write those funcs? Use entirely function pointers? I've been told that just the linker script is enough to do all of this and I needn't worry about anything, but I still don't understand how it works.
On GCC: Just put the function in the .data section:
__attribute__( ( section(".data") ) )
It will be copied over with the rest of your initialzed variables by the startup code (no need to mess with the linker scipt). You may also need a "long_call" option as well if the function ends up "far away" from the rest of the code after being placed into RAM.
__attribute__( ( long_call, section(".data") ) )
Example:
__attribute__( ( long_call, section(".data") ) ) void ram_foobar (void) { ... }
You may get an compiler warning that can be safely ignored:
Warning: ignoring changed section attributes for .data
You have two options.
Copy them as you suggest, compile with pc relative.
Use a linker file with a different load/run address.
A simple copy will only work if the routines do not use any absolute addresses. It maybe fine if they do use the absolute address as I guess you are going to leave a copy in standard RAM. However, this may not get the full benefit of the TCM.
With a linker script, you can specify a different LOAD and RUN locations.
sections {
.text { *(.text); } >FLASH
.tcm {
*(.tcm);
} >TCM_MEM AT>FLASH
.data { *(.data); } > RAM
.bss : NOLOAD { *(.bss); } > RAM
}
Note especially AT>FLASH.
See also: gnu linker map file... and many more on stackoverflow. The Gnu Ld manual has information on LMA sections (LOAD address). Your LMA would be flash, but the VMA (RUN address) would be TCM. The manual link above also shows how to copy. The RAM, FLASH, and TCM_MEM are defined with ld MEMORY information, depending on the addresses are for your board. All of this will be documented in a MAP file. Be sure to generate a MAP file and examine the addresses to double check your ld script.
The 2nd case also requires a copy (at start-up or at least before the first TCM function use). However, the compiler can use absolute addresses and they will be in the TCM memory. Also any function within the main DRAM can call the TCM function directly. With the first case, you must use function pointers to call the TCM code. If you wish global variables to be placed in this memory, you can use attributes to put them in different sections and use gnu ld to place them appropriately. I think there is ITCM and DTCM? So maybe this doesn't apply for you, or you need two sections.
The linker script is more generic and will work best if you put complicated functionality in the TCM. Just using -fpic, etc and copying may get things working quickly, especially if you only have a single pure function.
Nowadays (then-a-days as well?) you can just use the macro __RAM_FUNC, __RAMFUNC_EXT(bank, name) or __RAMFUNC(bank)
My embedded projects have a post-process step that replaces a value in the executable with the CRC of (some sections of) the flash. This step can only be done after linking since that is the first opportunity to CRC the image. In the past the file format was COFF, and I have created a custom tool to do the patching.
The development tool has switched to ELF, so I need to re-implement the CRC patcher. Before I do, I thought I'd look for an existing tool to do this. The compiler is based on gcc, but I can't see any combination of ld and nm and readelf that can do the job. A Google search has not been fruitful.
My present tool uses nm to find the address to patch, and calls the patcher with the address, the expected value (to prevent overwriting the wrong data), and the new CRC value. The CRC is calculated on a "hex" format of the executable (that I also patch) so fortunately I don't have to redo that part.
I can implement this with libelf and custom code again, but before I do, does it already exist?
Is there a better way to accomplish my goal of putting a CRC of the executable into the executable so it's available to the application?
If I've understood what you're trying to do correctly, I think the following would work:
nm gives you the runtime virtual address of the location you want to patch;
readelf -S gives you both the runtime virtual address and the offset within the file for the beginning of each section;
stitching the two together (e.g. with a few lines of your favourite scripting language) gives the offset within the file to patch.
I'm not sure if this would work, but you might be able to arrange it so that the CRC location within your object file were to be set to the address of an external symbol X. That external symbol might then be satisfied by a last linking step by linking in an elf file that did nothing but specify that X's address was the CRC that you have calculated.
This is still pretty hacky, and I'm not sure if it's easily do-able (since it is such an abuse of the tools).