nuttx/boards/arm/stm32h7/nucleo-h743zi/scripts/kernel.space.ld

111 lines
3.1 KiB
Plaintext
Raw Normal View History

/****************************************************************************
* boards/arm/stm32h7/nucleo-h743zi/scripts/kernel.space.ld
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/
/* NOTE: This depends on the memory.ld script having been included prior to
* this script.
*/
OUTPUT_ARCH(arm)
ENTRY(_stext)
SECTIONS
{
.text : {
_stext = ABSOLUTE(.);
*(.vectors)
*(.text .text.*)
*(.fixup)
*(.gnu.warning)
*(.rodata .rodata.*)
*(.gnu.linkonce.t.*)
*(.glue_7)
*(.glue_7t)
*(.got)
*(.gcc_except_table)
*(.gnu.linkonce.r.*)
_etext = ABSOLUTE(.);
} > kflash
.init_section : {
_sinit = ABSOLUTE(.);
KEEP(*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP(*(.init_array .ctors))
_einit = ABSOLUTE(.);
} > kflash
.ARM.extab : {
*(.ARM.extab*)
} > kflash
__exidx_start = ABSOLUTE(.);
.ARM.exidx : {
*(.ARM.exidx*)
} > kflash
__exidx_end = ABSOLUTE(.);
_eronly = ABSOLUTE(.);
.data : {
_sdata = ABSOLUTE(.);
*(.data .data.*)
*(.gnu.linkonce.d.*)
CONSTRUCTORS
. = ALIGN(4);
_edata = ABSOLUTE(.);
} > ksram AT > kflash
.bss : {
_sbss = ABSOLUTE(.);
*(.bss .bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
. = ALIGN(4);
_ebss = ABSOLUTE(.);
} > ksram
arch/stm32h7 - Fix HEAP clobbering static data in SRAM4 Normally, statically allocated data goes in .bss, followed by the initial stack, followed by HEAP. However, any data that is statically allocated in SRAM4 with __attribute__ ((section (".sram4"))) will clobber, and be clobbered by, the HEAP. On STM32H7, BDMA can only access SRAM4. Therefore any BDMA buffers (or any other data) placed in SRAM4 will expose this problem. In one case, this manifested as a failure of NSH to start, because the SPI6 BDMA buffers clobbered the /dev/console inode structs, which the OS allocated earlier. This PR ensures that only the rest of SRAM4, after any static data, is added to the heap. This PR also allows SRAM4 to be completely excluded from the heap by a new Kconfig, CONFIG_STM32H7_SRAM4EXCLUDE, similar to what CONFIG_STM32H7_DTCMEXCLUDE does for the DTCM region. Change required in linker scripts: Every STM32H7 linker script must replace this: .sram4 : { } > sram4 with this: .sram4_reserve (NOLOAD) : { *(.sram4) . = ALIGN(4); _sram4_heap_start = ABSOLUTE(.); } > sram4 or link will fail with: undefined reference to '_sram4_heap_start'. The Release Notes should document this for users with out-of-tree boards. arch/arm/src/stm32h7/Kconfig: * Add config STM32H7_SRAM4EXCLUDE to allow excluding all of SRAM4 from the HEAP. arch/arm/src/stm32h7/stm32_allocateheap.c: * Only when including SRAM4 in the heap, define HAVE_SRAM4, SRAM4_START, SRAM4_END, and SRAM4_HEAP_START. * Add "Private Data" section. * Add extern for_sram4_heap_start, which must be defined in the board's linker script. * arm_addregion(): Only add SRAM4 to the heap when configured to do so, i.e., unless CONFIG_STM32H7_SRAM4EXCLUDE is defined, and only add the portion of SRAM4 that is past any static data. boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld: boards/arm/stm32h7/nucleo-h743zi/scripts/kernel.space.ld: boards/arm/stm32h7/nucleo-h743zi2/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/kernel.space.ld: * Update all in-tree STM32H7 board linker scripts as described in "Change required in linker scripts" above. Testing: * Successfully built all of the following configurations: nucleo-h743zi2:jumbo nucleo-h743zi2:nsh nucleo-h743zi:nxlines_oled nucleo-h743zi:elf nucleo-h743zi:otg_fs_host nucleo-h743zi:nsh nucleo-h743zi:netnsh nucleo-h743zi:pwm stm32h747i-disco:nsh * Tested with custom board. * nxstyle. References: [1] See the dev@nuttx.a.o mailing list discussion started 2021/03/25: "How to ensure HEAP will not overlap static DMA buffer?" https://lists.apache.org/thread.html/recf2bb9043f8c9f53c10917e2adb2ec64fe35dc5e6f9a695a7ac6ecc%40%3Cdev.nuttx.apache.org%3E [2] See arm_addregion() in arch/arm/src/stm32h7/stm32_allocateheap.c Thanks to Gregory Nutt and David Sidrane for suggestions and reviews.
2021-03-26 19:29:28 +01:00
/* Emit the the D3 power domain section for locating BDMA data
*
* Static data with locate_data(".sram4") will be located
arch/stm32h7 - Fix HEAP clobbering static data in SRAM4 Normally, statically allocated data goes in .bss, followed by the initial stack, followed by HEAP. However, any data that is statically allocated in SRAM4 with __attribute__ ((section (".sram4"))) will clobber, and be clobbered by, the HEAP. On STM32H7, BDMA can only access SRAM4. Therefore any BDMA buffers (or any other data) placed in SRAM4 will expose this problem. In one case, this manifested as a failure of NSH to start, because the SPI6 BDMA buffers clobbered the /dev/console inode structs, which the OS allocated earlier. This PR ensures that only the rest of SRAM4, after any static data, is added to the heap. This PR also allows SRAM4 to be completely excluded from the heap by a new Kconfig, CONFIG_STM32H7_SRAM4EXCLUDE, similar to what CONFIG_STM32H7_DTCMEXCLUDE does for the DTCM region. Change required in linker scripts: Every STM32H7 linker script must replace this: .sram4 : { } > sram4 with this: .sram4_reserve (NOLOAD) : { *(.sram4) . = ALIGN(4); _sram4_heap_start = ABSOLUTE(.); } > sram4 or link will fail with: undefined reference to '_sram4_heap_start'. The Release Notes should document this for users with out-of-tree boards. arch/arm/src/stm32h7/Kconfig: * Add config STM32H7_SRAM4EXCLUDE to allow excluding all of SRAM4 from the HEAP. arch/arm/src/stm32h7/stm32_allocateheap.c: * Only when including SRAM4 in the heap, define HAVE_SRAM4, SRAM4_START, SRAM4_END, and SRAM4_HEAP_START. * Add "Private Data" section. * Add extern for_sram4_heap_start, which must be defined in the board's linker script. * arm_addregion(): Only add SRAM4 to the heap when configured to do so, i.e., unless CONFIG_STM32H7_SRAM4EXCLUDE is defined, and only add the portion of SRAM4 that is past any static data. boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld: boards/arm/stm32h7/nucleo-h743zi/scripts/kernel.space.ld: boards/arm/stm32h7/nucleo-h743zi2/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/kernel.space.ld: * Update all in-tree STM32H7 board linker scripts as described in "Change required in linker scripts" above. Testing: * Successfully built all of the following configurations: nucleo-h743zi2:jumbo nucleo-h743zi2:nsh nucleo-h743zi:nxlines_oled nucleo-h743zi:elf nucleo-h743zi:otg_fs_host nucleo-h743zi:nsh nucleo-h743zi:netnsh nucleo-h743zi:pwm stm32h747i-disco:nsh * Tested with custom board. * nxstyle. References: [1] See the dev@nuttx.a.o mailing list discussion started 2021/03/25: "How to ensure HEAP will not overlap static DMA buffer?" https://lists.apache.org/thread.html/recf2bb9043f8c9f53c10917e2adb2ec64fe35dc5e6f9a695a7ac6ecc%40%3Cdev.nuttx.apache.org%3E [2] See arm_addregion() in arch/arm/src/stm32h7/stm32_allocateheap.c Thanks to Gregory Nutt and David Sidrane for suggestions and reviews.
2021-03-26 19:29:28 +01:00
* at start of SRAM4; the rest of SRAM4 will be added to the heap.
*/
arch/stm32h7 - Fix HEAP clobbering static data in SRAM4 Normally, statically allocated data goes in .bss, followed by the initial stack, followed by HEAP. However, any data that is statically allocated in SRAM4 with __attribute__ ((section (".sram4"))) will clobber, and be clobbered by, the HEAP. On STM32H7, BDMA can only access SRAM4. Therefore any BDMA buffers (or any other data) placed in SRAM4 will expose this problem. In one case, this manifested as a failure of NSH to start, because the SPI6 BDMA buffers clobbered the /dev/console inode structs, which the OS allocated earlier. This PR ensures that only the rest of SRAM4, after any static data, is added to the heap. This PR also allows SRAM4 to be completely excluded from the heap by a new Kconfig, CONFIG_STM32H7_SRAM4EXCLUDE, similar to what CONFIG_STM32H7_DTCMEXCLUDE does for the DTCM region. Change required in linker scripts: Every STM32H7 linker script must replace this: .sram4 : { } > sram4 with this: .sram4_reserve (NOLOAD) : { *(.sram4) . = ALIGN(4); _sram4_heap_start = ABSOLUTE(.); } > sram4 or link will fail with: undefined reference to '_sram4_heap_start'. The Release Notes should document this for users with out-of-tree boards. arch/arm/src/stm32h7/Kconfig: * Add config STM32H7_SRAM4EXCLUDE to allow excluding all of SRAM4 from the HEAP. arch/arm/src/stm32h7/stm32_allocateheap.c: * Only when including SRAM4 in the heap, define HAVE_SRAM4, SRAM4_START, SRAM4_END, and SRAM4_HEAP_START. * Add "Private Data" section. * Add extern for_sram4_heap_start, which must be defined in the board's linker script. * arm_addregion(): Only add SRAM4 to the heap when configured to do so, i.e., unless CONFIG_STM32H7_SRAM4EXCLUDE is defined, and only add the portion of SRAM4 that is past any static data. boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld: boards/arm/stm32h7/nucleo-h743zi/scripts/kernel.space.ld: boards/arm/stm32h7/nucleo-h743zi2/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/kernel.space.ld: * Update all in-tree STM32H7 board linker scripts as described in "Change required in linker scripts" above. Testing: * Successfully built all of the following configurations: nucleo-h743zi2:jumbo nucleo-h743zi2:nsh nucleo-h743zi:nxlines_oled nucleo-h743zi:elf nucleo-h743zi:otg_fs_host nucleo-h743zi:nsh nucleo-h743zi:netnsh nucleo-h743zi:pwm stm32h747i-disco:nsh * Tested with custom board. * nxstyle. References: [1] See the dev@nuttx.a.o mailing list discussion started 2021/03/25: "How to ensure HEAP will not overlap static DMA buffer?" https://lists.apache.org/thread.html/recf2bb9043f8c9f53c10917e2adb2ec64fe35dc5e6f9a695a7ac6ecc%40%3Cdev.nuttx.apache.org%3E [2] See arm_addregion() in arch/arm/src/stm32h7/stm32_allocateheap.c Thanks to Gregory Nutt and David Sidrane for suggestions and reviews.
2021-03-26 19:29:28 +01:00
.sram4_reserve (NOLOAD) :
{
arch/stm32h7 - Fix HEAP clobbering static data in SRAM4 Normally, statically allocated data goes in .bss, followed by the initial stack, followed by HEAP. However, any data that is statically allocated in SRAM4 with __attribute__ ((section (".sram4"))) will clobber, and be clobbered by, the HEAP. On STM32H7, BDMA can only access SRAM4. Therefore any BDMA buffers (or any other data) placed in SRAM4 will expose this problem. In one case, this manifested as a failure of NSH to start, because the SPI6 BDMA buffers clobbered the /dev/console inode structs, which the OS allocated earlier. This PR ensures that only the rest of SRAM4, after any static data, is added to the heap. This PR also allows SRAM4 to be completely excluded from the heap by a new Kconfig, CONFIG_STM32H7_SRAM4EXCLUDE, similar to what CONFIG_STM32H7_DTCMEXCLUDE does for the DTCM region. Change required in linker scripts: Every STM32H7 linker script must replace this: .sram4 : { } > sram4 with this: .sram4_reserve (NOLOAD) : { *(.sram4) . = ALIGN(4); _sram4_heap_start = ABSOLUTE(.); } > sram4 or link will fail with: undefined reference to '_sram4_heap_start'. The Release Notes should document this for users with out-of-tree boards. arch/arm/src/stm32h7/Kconfig: * Add config STM32H7_SRAM4EXCLUDE to allow excluding all of SRAM4 from the HEAP. arch/arm/src/stm32h7/stm32_allocateheap.c: * Only when including SRAM4 in the heap, define HAVE_SRAM4, SRAM4_START, SRAM4_END, and SRAM4_HEAP_START. * Add "Private Data" section. * Add extern for_sram4_heap_start, which must be defined in the board's linker script. * arm_addregion(): Only add SRAM4 to the heap when configured to do so, i.e., unless CONFIG_STM32H7_SRAM4EXCLUDE is defined, and only add the portion of SRAM4 that is past any static data. boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld: boards/arm/stm32h7/nucleo-h743zi/scripts/kernel.space.ld: boards/arm/stm32h7/nucleo-h743zi2/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/flash.ld: boards/arm/stm32h7/stm32h747i-disco/scripts/kernel.space.ld: * Update all in-tree STM32H7 board linker scripts as described in "Change required in linker scripts" above. Testing: * Successfully built all of the following configurations: nucleo-h743zi2:jumbo nucleo-h743zi2:nsh nucleo-h743zi:nxlines_oled nucleo-h743zi:elf nucleo-h743zi:otg_fs_host nucleo-h743zi:nsh nucleo-h743zi:netnsh nucleo-h743zi:pwm stm32h747i-disco:nsh * Tested with custom board. * nxstyle. References: [1] See the dev@nuttx.a.o mailing list discussion started 2021/03/25: "How to ensure HEAP will not overlap static DMA buffer?" https://lists.apache.org/thread.html/recf2bb9043f8c9f53c10917e2adb2ec64fe35dc5e6f9a695a7ac6ecc%40%3Cdev.nuttx.apache.org%3E [2] See arm_addregion() in arch/arm/src/stm32h7/stm32_allocateheap.c Thanks to Gregory Nutt and David Sidrane for suggestions and reviews.
2021-03-26 19:29:28 +01:00
*(.sram4)
. = ALIGN(4);
_sram4_heap_start = ABSOLUTE(.);
} > sram4
/* Stabs debugging sections */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_info 0 : { *(.debug_info) }
.debug_line 0 : { *(.debug_line) }
.debug_pubnames 0 : { *(.debug_pubnames) }
.debug_aranges 0 : { *(.debug_aranges) }
}