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,
toggle quoted messageShow quoted text
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 <Jamie.Mccrae@...> 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,
toggle quoted messageShow quoted text
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 <Jamie.Mccrae@...> 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.
|
|