CONFIG_CUSTOM_LINKER_SCRIPT in prj.conf not working.

[SteveKranz]

Summary:
If I add these two lines to my prj.conf the system will no longer build. Any ideas on what I’m doing wrong? Any help would be appreciated.

CONFIG_HAVE_CUSTOM_LINKER_SCRIPT=y
CONFIG_CUSTOM_LINKER_SCRIPT="linker.cmd"

Details:
Without those two lines I can build the supplied cli sample from the nordic SDK and build it fine. It runs fine too. With a now populated cli/build directory if I then do the following commands:

$ cd cli
$ cp  build/zephyr/linker.cmd linker.cmd
$ rm build/zephyr/linker.cmd

… and then add the two lines to my prj.conf files you would think I’d get the same exact build as before since all I did is relocate the same linker.cmd and add the reference in prj.conf. But in fact the build will fail the link step. Any ideas on what I’m doing wrong? Any help would be appreciated.

Misc:
nrf sample project = cli
board: nrf52840-DK
SDK: nrf v2.4.1
Machine: MacBook Pro with Ventura 13.4.1

Error Transcript:
[381/386] Generating linker.cmd
[382/386] Generating isr_tables.c, isrList.bin
FAILED: zephyr/isr_tables.c zephyr/isrList.bin
cd /Users/Kranz/puzl/nrf/nordic_puzl_thread/build/zephyr && /opt/nordic/ncs/toolchains/4ef6631da0/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-objcopy --input-target=elf32-littlearm --output-target=binary --only-section=.intList /Users/Kranz/puzl/nrf/nordic_puzl_thread/build/zephyr/zephyr_pre1.elf isrList.bin && /opt/nordic/ncs/toolchains/4ef6631da0/opt/[email protected]/bin/python3.9 /opt/nordic/ncs/v2.4.1/zephyr/scripts/build/gen_isr_tables.py --output-source isr_tables.c --kernel /Users/Kranz/puzl/nrf/nordic_puzl_thread/build/zephyr/zephyr_pre1.elf --intlist isrList.bin --sw-isr-table --vector-table
Traceback (most recent call last):
  File "/opt/nordic/ncs/v2.4.1/zephyr/scripts/build/gen_isr_tables.py", line 359, in <module>
    main()
  File "/opt/nordic/ncs/v2.4.1/zephyr/scripts/build/gen_isr_tables.py", line 261, in main
    intlist = read_intlist(args.intlist, syms)
  File "/opt/nordic/ncs/v2.4.1/zephyr/scripts/build/gen_isr_tables.py", line 82, in read_intlist
    header = struct.unpack_from(intlist_header_fmt, intdata, 0)
struct.error: unpack_from requires a buffer of at least 8 bytes for unpacking 8 bytes at offset 0 (actual buffer size is 0)
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /opt/nordic/ncs/toolchains/4ef6631da0/bin/cmake --build /Users/Kranz/puzl/nrf/nordic_puzl_thread/build

Thanks in advance,
Steve K, PuzL Labs, LLC

[Kenneth]

I can ask internally if someone have some suggestions, in the meantime you can try to look at whether this devzone case provide any help:
https://devzone.nordicsemi.com/f/nordic-q-a/95928/how-can-i-allocate-array-in-flash 

Kenneth

[SteveKranz]

Hi Kenneth,

Did you happen to see that last reply I sent you (around Aug 18th)?

Steve K. PuzL Labs, LLC

[Vidar Berg]

Hi Steve,

I believe a more straightforward way to reserve the first 256 bytes in RAM is to offset the start address of the sram0 node in the devicetree by 0x100. You can achieve this by creating a board overlay file.

For example, for the nrf52840dk_nrf52840 board, the overlay file would look like this:

nrf52840dk_nrf52840.overlay

&sram0 {
    reg = < 0x20000100 (DT_SIZE_K(256)-0x100)>;
};

The overlay can be placed in the project root. It will be picked up by the build system after a pristine build.

Best regards,

Vidar

[SteveKranz]

Hi Vidar,

I appreciate the tip. That did get me a bit closer to a solution. However, the issue I'm seeing is that overall RAM size is not being honored. Instead of reducing by only 256 bytes, it seems to reduce in 1024 byte increments. After placing the following in my boards/nrf52840dk_nrf52840.overlay:

&sram0 {

reg = < 0x20000100 (DT_SIZE_K(256)-0x100)>;

};

... the prestine build generates the following build/zephyr/linker.cmd setting:

MEMORY
    {
    FLASH (rx) : ORIGIN = (0x0 + 0x0), LENGTH = (1024*1K - 0x0)
    RAM (wx) : ORIGIN = 0x20000100, LENGTH = (255 * 1K)  
    IDT_LIST (wx) : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
    }

Summary: The start of Ram was indeed offset by 0x100 , yet the Ram total length was reduced by 0x400.

Maybe there is a slight tweak that might fix this. Not sure, but any additional tips would be appreciated.

Thanks,

Steve K., PuzL Labs, LLC.

[Vidar Berg]

Hi Steve,

Good catch, it seems like the RAM size is being aligned to 0x400 somewhere. Please try this approach instead:

1. Add the following line to CMakelists.txt after project(): 

zephyr_linker_sources(RAM_SECTIONS reserve_ram.ld)

2. Create the reserve_ram.ld file with the content below and place it in your project root.

SECTION_PROLOGUE(.reserved_ram,(NOLOAD),)
{
    . = 0x100;
} GROUP_START(RAMABLE_REGION)

I tried this here, and the linker.cmd file ended up looking like this: 

...
 . = 0x20000000;
 . = ALIGN(_region_min_align);
 _image_ram_start = .;
.reserved_ram (NOLOAD) :
{
    . = 0x100;
}
.ramfunc : ALIGN_WITH_INPUT
{
...

And the *.map file:

....
                0x0000000020000000                . = 0x20000000
                0x0000000020000000                . = ALIGN (_region_min_align)
                0x0000000020000000                _image_ram_start = .

.reserved_ram   0x0000000020000000      0x100
                0x0000000000000100                . = 0x100
 *fill*         0x0000000020000000      0x100 

.ramfunc        0x0000000020000100        0x0 load address 0x0000000000044614
                0x0000000020000100                . = ALIGN (_region_min_align)
                0x0000000020000100                . = ALIGN ((0x1 << LOG2CEIL (__ramfunc_size)))
                0x0000000020000100                __ramfunc_start = .
 *(SORT_BY_ALIGNMENT(.ramfunc))
 *(SORT_BY_ALIGNMENT(.ramfunc.*))
 ...

Best regards,

Vidar