The patch
Make: use gcc as LD
introduced use of GCC wrapper as linker. LD variable references GCC
executable now. But when GCC wrapper s used to build relocatable
loadable objects (ELF executables and modules) then it causes
linking of toolchain default libc and other libraries even when -r
is usd. Another problem is that incorrect multiarch variant is selected
for libraries search and possibly even for LTO or C++ templates
instantiating and other glue code which causes fails during linking
if CFLAGS selects non/default miltiarch variant.
Corresponding CFLAGS are passed to LDMODULEFLAGS and LDELFFLAGS
as well as -nostartfiles -nodefaultlibs options.
Separate line is used to easily find and adjust lines if link
process is changed in future.
Signed-off-by: Pavel Pisa <ppisa@pikron.com>
Gwenhael Goavec has submitted the ICLA and we can migrate the licenses
to Apache.
David Sidranec has submitted the ICLA and we can migrate the licenses
to Apache.
Gregory Nutt has submitted the SGA and we can migrate the licenses
to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
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.
David Sidrane has submitted the ICL and we can migrate the licenses
to Apache.
Gregory Nutt has submitted the SGA and we can migrate the licenses
to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
In the current compilation environment, the recursive assignment(=) for compile
flags will be delayed until every file is actually need to be compile.
For example:
--------------------------------------------------------------------------------
arch/arm/src/Makefile:
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)chip}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)common}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)$(ARCH_SUBDIR)}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(TOPDIR)$(DELIM)sched}
CPPFLAGS += $(INCLUDES) $(EXTRAFLAGS)
CFLAGS += $(INCLUDES) $(EXTRAFLAGS)
CXXFLAGS += $(INCLUDES) $(EXTRAFLAGS)
AFLAGS += $(INCLUDES) $(EXTRAFLAGS)
--------------------------------------------------------------------------------
All compilation options will be included recursively,
which will be delayed until the compilation options are actually used:
tools/Config.mk:
--------------------------------------------------------------------------------
define COMPILE
@echo "CC: $1"
$(Q) $(CC) -c $(CFLAGS) $($(strip $1)_CFLAGS) $1 -o $2
endef
--------------------------------------------------------------------------------
All compile flags to be reexecuted $(INCDIR) as long as one file needs to be compiled,
but in fact, the compilation options have not changed in the current directory.
So the we recommand to change the syntax of assignment
From
Recursive (=)
To
Simple (:=)
In this way, we can ensure that all compilation options are expanded only once and reducing repeated works.
Signed-off-by: chao.an <anchao@xiaomi.com>
1.Reduce the default size of task_group_s(~512B each task)
2.Scale better between simple and complex application
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ia872137504fddcf64d89c48d6f0593d76d582710
to save the preserved space(1KB) and also avoid the heap overhead
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I694073f68e1bd63960cedeea1ddec441437be025
Change the preallocated message and descriptor from 32/24 to 4.
The total size is reduce from 1892 to 532
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I79d199465daef678986868f773876289859f42fc
since the maximum number of argument pass to wd_start in the whole
code base is 2 and change CONFIG_MAX_WDOGPARMS in some defconfig
from 1 to 2 oherwise pthread_condclockwait will fail
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ib6cb28b8c0722058849e7be916e164513431d21c
1.It make sense to let Toolchain.defs give the default value
2.The board can still change if the default isn't suitable
3.Avoid the same definition spread more than 200 Make.defs
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ic2649f1c7689bcf59c105ca8db61cad45b6e0e64
Make.defs under board folder can still overwrite the default as needed
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I1c300a8ace4b54d475ef8d398661ed65ca273a2e
so all boards support uClibc++/libc++ automatically
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ibe6fafbec57f7acb26ea6188a3e9923ea82295c5
since cxx initialization is controlled by CONFIG_HAVE_CXXINITIALIZE now
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I39438dc3006d0a0b810052ecef50cd3c92f09d83
so the lower half driver don't need include the specific board.h
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Icf6638a6865bac42150b5957376e55909f041d40
so the lower half driver don't need include the specific board.h
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I2ff5c30049a5c5e8ee90baea56e9f4cb1a8a4f87