Topics

Removing padding from generated hex files


Jamie Mccrae <Jamie.Mccrae@...>
 

Hi,

Is it possible when building projects to have the flash sections that are defined in the dts but unused (in this instance, the Nordic MBR) and not have them filled but instead left blank/empty? I have created a simple project and enabled mcuboot support in the build options, it uses the flash partition table correctly and places the code at 0x1000 instead of 0x0, but it has filled 0x0 – 0x1000 with 0x00 bytes, which if flashed will overwrite the Nordic MBR and leave a dead module. Instead, I would like to have code start at 0x1000, nothing at all placed between 0x0 – 0x1000, and the same in another section which is defined later, this is so that there can be external data present which isn’t overwritten when the application hex file is flashed to the module.

Thanks,

Jamie


Sebastian Boe
 

Hi,

try enabling

CONFIG_BUILD_NO_GAP_FILL

IMHO this should be the default. Needing to fill the gaps is indicative of a problem
elsewhere, e.g. in the linker scripts.

________________________________________
From: devel@... <devel@...> on behalf of via Lists.Zephyrproject.Org <Jamie.Mccrae=lairdconnect.com@...>
Sent: Thursday, April 4, 2019 2:14 PM
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Removing padding from generated hex files

Hi,
Is it possible when building projects to have the flash sections that are defined in the dts but unused (in this instance, the Nordic MBR) and not have them filled but instead left blank/empty? I have created a simple project and enabled mcuboot support in the build options, it uses the flash partition table correctly and places the code at 0x1000 instead of 0x0, but it has filled 0x0 – 0x1000 with 0x00 bytes, which if flashed will overwrite the Nordic MBR and leave a dead module. Instead, I would like to have code start at 0x1000, nothing at all placed between 0x0 – 0x1000, and the same in another section which is defined later, this is so that there can be external data present which isn’t overwritten when the application hex file is flashed to the module.
Thanks,
Jamie


lairdjm
 

Hi,
I have tried that but it still pads the first section with 0x00 bytes. I'm using a custom board file and project so tried switched to trying it with the hello world sample using the nrf52840_pca10059 board file and enabled the option there, the area where the MBR is, is filled with 0x00 inside the hex file.
Thanks,
Jamie

-----Original Message-----

Hi,

try enabling

CONFIG_BUILD_NO_GAP_FILL

IMHO this should be the default. Needing to fill the gaps is indicative of a problem
elsewhere, e.g. in the linker scripts.


Sebastian Boe
 

Okay, if I was you I would have a look at the map file and try to figure out what it's putting there and why.

________________________________________
From: Jamie Mccrae <@lairdjm>
Sent: Thursday, April 4, 2019 2:34 PM
To: Bøe, Sebastian; devel@...
Subject: RE: Removing padding from generated hex files

Hi,
I have tried that but it still pads the first section with 0x00 bytes. I'm using a custom board file and project so tried switched to trying it with the hello world sample using the nrf52840_pca10059 board file and enabled the option there, the area where the MBR is, is filled with 0x00 inside the hex file.
Thanks,
Jamie

-----Original Message-----

Hi,

try enabling

CONFIG_BUILD_NO_GAP_FILL

IMHO this should be the default. Needing to fill the gaps is indicative of a problem
elsewhere, e.g. in the linker scripts.


lairdjm
 

Hi,
That's where I'm not sure on, I see the fill section but can't work out where it's coming from:
Memory Configuration

Name Origin Length Attributes
FLASH 0x00000000 0x00100000 xr
SRAM 0x20000000 0x00040000 xw
IDT_LIST 0x20040000 0x00000800 xw
*default* 0x00000000 0xffffffff

Linker script and memory map

LOAD zephyr/CMakeFiles/kernel_elf.dir/misc/empty_file.c.obj
LOAD zephyr/CMakeFiles/kernel_elf.dir/isr_tables.c.obj
LOAD app/libapp.a
LOAD zephyr/libzephyr.a
LOAD zephyr/arch/arch/arm/core/libarch__arm__core.a
LOAD zephyr/arch/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a
LOAD zephyr/arch/arch/arm/core/cortex_m/mpu/libarch__arm__core__cortex_m__mpu.a
LOAD zephyr/lib/libc/minimal/liblib__libc__minimal.a
LOAD zephyr/boards/arm/nrf52840_pca10059/libboards__arm__nrf52840_pca10059.a
LOAD zephyr/drivers/serial/libdrivers__serial.a
LOAD zephyr/kernel/libkernel.a
LOAD zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
LOAD c:/gcc-arm/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp\libgcc.a
0x00000020 _region_min_align = 0x20

.rel.plt 0x00000000 0x0
*(SORT_BY_ALIGNMENT(.rel.plt))
[!provide] PROVIDE (__rel_iplt_start = .)
*(SORT_BY_ALIGNMENT(.rel.iplt))
.rel.iplt 0x00000000 0x0 zephyr/CMakeFiles/kernel_elf.dir/isr_tables.c.obj
[!provide] PROVIDE (__rel_iplt_end = .)

.rela.plt 0x00000000 0x0
*(SORT_BY_ALIGNMENT(.rela.plt))
[!provide] PROVIDE (__rela_iplt_start = .)
*(SORT_BY_ALIGNMENT(.rela.iplt))
[!provide] PROVIDE (__rela_iplt_end = .)

.rel.dyn
*(SORT_BY_ALIGNMENT(.rel.*))

.rela.dyn
*(SORT_BY_ALIGNMENT(.rela.*))

/DISCARD/
*(SORT_BY_ALIGNMENT(.plt))
*(SORT_BY_ALIGNMENT(.iplt))
*(SORT_BY_ALIGNMENT(.got.plt))
*(SORT_BY_ALIGNMENT(.igot.plt))
*(SORT_BY_ALIGNMENT(.got))
*(SORT_BY_ALIGNMENT(.igot))
*(SORT_BY_ALIGNMENT(.irq_info))
*(SORT_BY_ALIGNMENT(.intList))
0x00000000 _image_rom_start = 0x0

text 0x00000000 0x1100
0x00001000 . = 0x1000
*fill* 0x00000000 0x1000
0x00001000 _vector_start = .
*(SORT_BY_ALIGNMENT(.exc_vector_table))
*(SORT_BY_ALIGNMENT(.exc_vector_table.*))

The linker.cmd file has this:
_image_rom_start = (0x0 + 0x0);
text :
{
. = 0x1000;
_vector_start = .;
KEEP(*(.exc_vector_table))
KEEP(*(".exc_vector_table.*"))
KEEP(*(.gnu.linkonce.irq_vector_table))
KEEP(*(.vectors))
KEEP(*(.openocd_dbg))
KEEP(*(".openocd_dbg.*"))

KEEP(*(.kinetis_flash_config))
KEEP(*(".kinetis_flash_config.*"))
_vector_end = .;
} > FLASH
Does the ". = 0x1000;" indicate the padding?
Thanks,
Jamie

-----Original Message-----

Okay, if I was you I would have a look at the map file and try to figure out what it's putting there and why.


Sebastian Boe
 

"Does the ". = 0x1000;" indicate the padding?"


Yes, you would want to compare it to the source to see what it's trying to do, and possibly
how to make it stop.

________________________________________
From: Jamie Mccrae <@lairdjm>
Sent: Thursday, April 4, 2019 3:13 PM
To: Bøe, Sebastian; devel@...
Subject: RE: Removing padding from generated hex files

Hi,
That's where I'm not sure on, I see the fill section but can't work out where it's coming from:
Memory Configuration

Name Origin Length Attributes
FLASH 0x00000000 0x00100000 xr
SRAM 0x20000000 0x00040000 xw
IDT_LIST 0x20040000 0x00000800 xw
*default* 0x00000000 0xffffffff

Linker script and memory map

LOAD zephyr/CMakeFiles/kernel_elf.dir/misc/empty_file.c.obj
LOAD zephyr/CMakeFiles/kernel_elf.dir/isr_tables.c.obj
LOAD app/libapp.a
LOAD zephyr/libzephyr.a
LOAD zephyr/arch/arch/arm/core/libarch__arm__core.a
LOAD zephyr/arch/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a
LOAD zephyr/arch/arch/arm/core/cortex_m/mpu/libarch__arm__core__cortex_m__mpu.a
LOAD zephyr/lib/libc/minimal/liblib__libc__minimal.a
LOAD zephyr/boards/arm/nrf52840_pca10059/libboards__arm__nrf52840_pca10059.a
LOAD zephyr/drivers/serial/libdrivers__serial.a
LOAD zephyr/kernel/libkernel.a
LOAD zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
LOAD c:/gcc-arm/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp\libgcc.a
0x00000020 _region_min_align = 0x20

.rel.plt 0x00000000 0x0
*(SORT_BY_ALIGNMENT(.rel.plt))
[!provide] PROVIDE (__rel_iplt_start = .)
*(SORT_BY_ALIGNMENT(.rel.iplt))
.rel.iplt 0x00000000 0x0 zephyr/CMakeFiles/kernel_elf.dir/isr_tables.c.obj
[!provide] PROVIDE (__rel_iplt_end = .)

.rela.plt 0x00000000 0x0
*(SORT_BY_ALIGNMENT(.rela.plt))
[!provide] PROVIDE (__rela_iplt_start = .)
*(SORT_BY_ALIGNMENT(.rela.iplt))
[!provide] PROVIDE (__rela_iplt_end = .)

.rel.dyn
*(SORT_BY_ALIGNMENT(.rel.*))

.rela.dyn
*(SORT_BY_ALIGNMENT(.rela.*))

/DISCARD/
*(SORT_BY_ALIGNMENT(.plt))
*(SORT_BY_ALIGNMENT(.iplt))
*(SORT_BY_ALIGNMENT(.got.plt))
*(SORT_BY_ALIGNMENT(.igot.plt))
*(SORT_BY_ALIGNMENT(.got))
*(SORT_BY_ALIGNMENT(.igot))
*(SORT_BY_ALIGNMENT(.irq_info))
*(SORT_BY_ALIGNMENT(.intList))
0x00000000 _image_rom_start = 0x0

text 0x00000000 0x1100
0x00001000 . = 0x1000
*fill* 0x00000000 0x1000
0x00001000 _vector_start = .
*(SORT_BY_ALIGNMENT(.exc_vector_table))
*(SORT_BY_ALIGNMENT(.exc_vector_table.*))

The linker.cmd file has this:
_image_rom_start = (0x0 + 0x0);
text :
{
. = 0x1000;
_vector_start = .;
KEEP(*(.exc_vector_table))
KEEP(*(".exc_vector_table.*"))
KEEP(*(.gnu.linkonce.irq_vector_table))
KEEP(*(.vectors))
KEEP(*(.openocd_dbg))
KEEP(*(".openocd_dbg.*"))

KEEP(*(.kinetis_flash_config))
KEEP(*(".kinetis_flash_config.*"))
_vector_end = .;
} > FLASH
Does the ". = 0x1000;" indicate the padding?
Thanks,
Jamie

-----Original Message-----

Okay, if I was you I would have a look at the map file and try to figure out what it's putting there and why.