# Elf files and initialized data

**URL:** <https://users.rust-lang.org/t/elf-files-and-initialized-data/109678>\
**Category:** embedded\
**Created:** [April 10, 2024, 1:51pm UTC](https://users.rust-lang.org/t/elf-files-and-initialized-data/109678 "2024-04-10T13:51:27Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![espenalb](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/espenalb/32/40088_2.png) [@espenalb](https://users.rust-lang.org/u/espenalb)\
**Post date:** [April 10, 2024, 1:51pm UTC](https://users.rust-lang.org/t/elf-files-and-initialized-data/109678/1 "2024-04-10T13:51:27Z")

</div>

Hi.

We are developing an application for the STM32H7, and we need some fairly large memory buffers. We want these to be in the "AXISRAM" section, so in our Rust code we have code like

```rust
#[link_section = ".axisram.buffers"]
static mut ADC1_BUFFER: [u16; ADC_RX_BUFFER_SIZE] = [0; ADC_RX_BUFFER_SIZE];

```

This works fine, we can flash and run the application using the normal `cargo run`.  
So far so good.

We want to use a bootloader, and therefore need to generate a .bin file instead of the "normal" .elf file that cargo builds.

Again - straightforward, we install the `cargo-binutils` and call `cargo-objcopy -- -O binary`

However: The generated .bin file is enormous - several 100MB. After some investigation, I realized that this is caused by the .elf file containing a _large_ section of zero's - which correspond to the zero-initialization of the `ADC1_BUFFER`. Since code starts at 0x08000000 and AXISRAM starts at 0x24000000 - the generated binary becomes enormous.

I _think_ we can solve our issue by leaving the `ADC1_BUFFER` un-initialized - but is there a more elegant solution?

This is our memory.x:

```rust
/**
 * See: https://github.com/stm32-rs/stm32h7xx-hal/blob/master/memory.x
 * https://www.st.com/resource/en/reference_manual/dm00176879-stm32h745-755-and-stm32h747-757-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf
 */

MEMORY
{
    SRAM1 : ORIGIN = 0x30000000, LENGTH = 128K /* 32-bit AHB bus matrix, D2 domain */
    SRAM2 : ORIGIN = 0x30020000, LENGTH = 128K /* 32-bit AHB bus matrix, D2 domain */
    SRAM3 (RW) : ORIGIN = 0x30040000, LENGTH = 32K /* 32-bit AHB bus matrix, D2 domain */
    SRAM4 (RW) : ORIGIN = 0x38000000, LENGTH = 64K /* 32-bit AHB bus matrix, D3 domain */
    BSRAM : ORIGIN = 0x38800000, LENGTH = 4K /* 32-bit AHB bus matrix, D3 domain */
    AXISRAM (RWX) : ORIGIN = 0x24000000, LENGTH = 512K /* 64-bit AXI bus matrix, D1 domain */
    DTCMRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K /* 64-bit AXI bus matrix, D1 domain */
    FLASH2 (RX) : ORIGIN = 0x08100000, LENGTH = 1M /* 64-bit AXI bus matrix, D1 domain */
    FLASH1 (RX) : ORIGIN = 0x08000000, LENGTH = 1M /* 64-bit AXI bus matrix, D1 domain */
    ITCMRAM (RWX) : ORIGIN = 0x00000000, LENGTH = 64K /* 64-bit AXI bus matrix, D1 domain */
}

/* stm32h7xx-hal uses a PROVIDE that expects RAM and FLASH symbols to exist */
REGION_ALIAS(RAM, DTCMRAM);
REGION_ALIAS(FLASH, FLASH1);

/* The location of the stack can be overridden using the
   `_stack_start` symbol. Place the stack at the end of RAM */
_stack_start = ORIGIN(RAM) + LENGTH(RAM);

SECTIONS
{
    .itcmram : ALIGN(4) {
        *(.itcmram .itcmram.*);
        . = ALIGN(4);
    } > ITCMRAM

    .dtcmram : ALIGN(4) {
        *(.dtcmram .dtcmram.*);
        . = ALIGN(4);
    } > DTCMRAM

    .axisram : ALIGN(8) {
        *(.axisram .axisram.*);
        . = ALIGN(8);
    } > AXISRAM

    /* The SRAM1 and SRAM2 section are commonly used as the stack and
       heap for the CM4 core in dualcore versions and should thus not
       be used in examples */

    .sram3 (NOLOAD) : ALIGN(4) {
        *(.sram3 .sram3.*);
        . = ALIGN(4);
    } > SRAM3

    .sram4 (NOLOAD) : ALIGN(4) {
        *(.sram4 .sram4.*);
        . = ALIGN(4);
     } > SRAM4
};

```

---

<div class="post-metadata">

**Author:** ![espenalb](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/espenalb/32/40088_2.png) [@espenalb](https://users.rust-lang.org/u/espenalb)\
**Post date:** [April 10, 2024, 1:57pm UTC](https://users.rust-lang.org/t/elf-files-and-initialized-data/109678/2 "2024-04-10T13:57:37Z")

</div>

Removing axisram from the binary seems to work - but is this the recommended solution?

```rust
 cargo objcopy --release -- --remove-section=.axisram -O binary 

```

---

<div class="post-metadata">

**Author:** ![yyogo](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/yyogo/32/34679_2.png) [@yyogo](https://users.rust-lang.org/u/yyogo)\
**Post date:** [April 10, 2024, 3:24pm UTC](https://users.rust-lang.org/t/elf-files-and-initialized-data/109678/3 "2024-04-10T15:24:30Z")

</div>

Perhaps the buffer should be `MaybeUninit`?

---

<div class="post-metadata">

**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/system/32/51372_2.png) [@system](https://users.rust-lang.org/u/system)\
**Post date:** [July 9, 2024, 3:24pm UTC](https://users.rust-lang.org/t/elf-files-and-initialized-data/109678/4 "2024-07-09T15:24:33Z")

</div>

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.