Understanding of NOLOAD directive for GNU-LD

[Kraal]

Hi everyone,

I want to have a section in FLASH that will act as an EEPROM with some initial values defined at compile time. I have defined the section in the linker script (the last page of the FLASH) and I can see it in the .map file correctly.

However I thought that I had to use the NOLOAD directive in order to avoid loading the RAM with its content at run-time. But the actual content of the page are empty (FF) with the NOLOAD directive, and correct without.

Can somebody please explain me what is the goal of the NOLOAD directive ?

[Tesla DeLorean]

It typically means there is no data in the object file or output for a specific load region. ie a void expressed with zero information, having size but not content.

If you want to carve out a hole in the memory for EEPROM Emulation or FLASH configuration space, one would normally split the SECTION table to have two distinct sections with a gap between them.

GNU/GCC is not good for allocating objects dynamically, so you'd likely need to steer things manually, specifically getting the reset/vector stuff into the front section.

On an F4, one might consider having a flash based loader in the first 16KB of FLASH, then leave the next three 16KB sectors for config/eeprom, and have your application reside/start at the 64KB marker. This way both the app/loader could access the config data.

[waclawek.jan]

The GNU linker's lingo is rather confusing, as some of the concepts it is using stem from a long forgotten era (the 70s and 80s), and also as it is written from the perspective of "big" computers, eg. a PC. There, typically, programs are loaded from a fixed medium (hard disk, but before magnetic tape units and punched cards) into the RAM of the computer where they are run. The linker is supposed to do this - load the program itself, load the referenced libraries (which used to be stored separately, shared among all the programs, as storage was expensive - think of dll) , cross-link the references (use adresses of objects to fill in the target addresses of jumps and calls and data loads and stores) and then run. This is reflected in its name - ld means loader. That the "combined image" of the RAM can be then stored into an output file, is almost a side effect.

This is where NOLOAD comes from. It's an area which contains program (i.e. symbols to be linked against, so the linker has to know of the program in that area) but does not need to be loaded when the program is to be run - for example, because it's in a ROM, think of the BIOS ROM in PC.

JW