`up_perf_init` defined in `nuttx/arch.h`, if CONFIG_ARCH_PERF_EVENTS enabled the compiler will raise a error:
```
board/esp32c3_boot.c:55:3: error: implicit declaration of function 'up_perf_init' [-Wimplicit-function-declaration]
55 | up_perf_init(NULL);
| ^~~~~~~~~~~~
board/esp32c3_boot.c:55:16: error: 'NULL' undeclared (first use in this function)
55 | up_perf_init(NULL);
| ^~~~
board/esp32c3_boot.c:28:1: note: 'NULL' is defined in header '<stddef.h>'; this is probably fixable by adding '#include <stddef.h>'
27 | #include <nuttx/board.h>
+++ |+#include <stddef.h>
28 |
board/esp32c3_boot.c:55:16: note: each undeclared identifier is reported only once for each function it appears in
55 | up_perf_init(NULL);
| ^~~~
make[1]: *** [/home/huang/Work/nx/nuttx/boards/Board.mk:83: esp32c3_boot.o] Error 1
```
Will report clang: error: invalid argument 'medium' to -mcmodel=
-mcmodel=large will both support clang and gcc.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
This commit adds files in preperation of adding ethernet drivers for the STM32H563 and Nucleo-H563ZI board.
It also modifies the pinmap to include ethernet pins (and cleaned up leftover comments from L5 file), as well as
add those pins to the board.h for the nucleo-h563zi.
Files added:
- arch/arm/src/stm32h5/hardware/stm32_ethernet.h
- arch/arm/src/stm32h5/hardware/stm32_sbs.h
- Not fully implemented, just register necessary for ethernet driver.
PLL1FRACN was being set improperly. stm32h5xxx_rcc.c does not shift the value provided by board.h. So it was being set wrong. The defintions in stm32h5xxx_rcc.h shift the FRACN value and are now used by board.h. Also, board.h was not setting PLL1P properly. PLL1P can not have odd divisors. Therefore a value of 0 was invalid. Set it to a value of 1 (divide by 2), then adjust PLL1N to 31 and PLL1FRAC1 to 2048 to actually set SYSCLK to 250MHz.
Made fixes to issues from CI. Nxstyle and defconfig syntax.
This is a combination of 6 commits.
Adding STM32H5 arch files. With comments addressed.
Created stm32h5 directory to add support for the H5 chip, and used a Nucleo-H563ZI dev board during development. The goal was to get a working nutshell through the STLink connector on the board.
Remove board/docs changes for PR update.
Squash commits into one for PR guideline conformity.
trying to fix build issues
Fix format from review
Nucleo-H563ZI support for NSH.
Created stm32h5 directory to add support for the H5 chip, and used a Nucleo-H563ZI dev board during development. The goal was to get a working nutshell through the STLink connector on the board.
Fix switch default case placement.
NXstyle fixes
Renaming files
rename stm32h5_gpio.x files
rename h5 hsi48 files
Rename h5 idle file
rename stm32h5_irq.c
Rename some rcc functions and stm32h5_rcc.c
rename stm32h5_rcc.h
Rename stm32h5_pwr.x
lowputc renames
timerisr renames
uart renamed
rename serial file
rename start
Turn off the defines that enable DMA on serial
remove DMA Kconfig options
Remove H5 documentation. Will add in a future PR.
Fix styling and defconfig improper syntax.
Created stm32h5 directory to add support for the H5 chip, and used a Nucleo-H563ZI dev board during development. The goal was to get a working nutshell through the STLink connector on the board.
Remove board/docs changes for PR update.
Squash commits into one for PR guideline conformity.
trying to fix build issues
Fix format from review
The reason for removing math.h is that undefining __GLIBC__ does not take effect. By default, sim will use the toolchain's math library and undef __GLIBC__ in the source file.
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
use the dynamic library .so of the binding compilation environment,
and then modify the dynamic loader of elf at runtime to run sim elf across system versions
1.add post-build for sim build
2.collect dynamic .so and dynamic interpreter
3.add execution script for the entire package sim elf
change text-segment to 0x50000000
because patchelf will modify the .dynamic section in elf,
the upward alignment of elf will be less than 0x3fffffff,
which will cause asan shadow memory overlap error
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
This patch fixed userspace headers conflict. Architecture-related definition and API should not be exposed to users.
Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
1. CONFIG_ARCH_COVERAGE has been replaced by CONFIG_SCHED_GCOV
2. Delete the SIM-specific GCOV_ALL configuration and change it to a universal configuration for all architectures
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
After recent changes on nuttx-apps (not limited to, but related
to nuttx-apps#2738, for instance), the stack usage for the NSH
task increased, causing stack overflows under specific situations
(when running `ps` command, for instance). This commit increases
the init task stack size to avoid it. Please note that, even before
these changes, the stack usage of the NSH task was around 90% and,
then, increasing the stack size of it was recommended.
To make it easier to keep the linker scripts updated for both
MCUboot and "simple-boot", this commit merges them into a single
linker script with macros to enable/disable specific sections.
`riscv_internal.h` is a private chip level header file,
and it should not be included in the board files.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
LD: nuttx
nuttx.rel: in function `ff_dct32_float_sse2':
(.text+0x66f9e): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_32' defined in .bss.ff_cos_32 section in nuttx.rel
(.text+0x66fa7): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_32' defined in .bss.ff_cos_32 section in nuttx.rel
(.text+0x672a6): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_16' defined in .bss.ff_cos_16 section in nuttx.rel
(.text+0x672ae): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_16' defined in .bss.ff_cos_16 section in nuttx.rel
nuttx.rel: in function `ff_imdct_calc_sse':
(.text+0x67905): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_64' defined in .bss.ff_cos_64 section in nuttx.rel
(.text+0x67948): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_128' defined in .bss.ff_cos_128 section in nuttx.rel
(.text+0x67988): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_256' defined in .bss.ff_cos_256 section in nuttx.rel
(.text+0x679c8): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_512' defined in .bss.ff_cos_512 section in nuttx.rel
(.text+0x67a08): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_1024' defined in .bss.ff_cos_1024 section in nuttx.rel
(.text+0x67a48): relocation truncated to fit: R_X86_64_32S against symbol `ff_cos_2048' defined in .bss.ff_cos_2048 section in nuttx.rel
(.text+0x67a88): additional relocation overflows omitted from the output
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
Modify the starting position of the elf segment to 0x5000000
==2561587==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==2561587==ASan shadow was supposed to be located in the [0x1ffff000-0x3fffffff] range.
==2561587==Process memory map follows:
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
Add support for memory partitioning for OTA updates.
This feature is targeted at the integration of ESP32 boards with RISC-V architecture in conjunction with MCUboot
Signed-off-by: davidiogos <davi.silva@agrosystem.com.br>
fix
CMake Error at boards/arm/stm32f7/nucleo-f746zg/src/CMakeLists.txt:76 (endif):
Flow control statements are not properly nested.
CMake Error at boards/arm/stm32f7/nucleo-f746zg/src/CMakeLists.txt:76 (endif):
Flow control statements are not properly nested.
-- Configuring incomplete, errors occurred!
nucleo-144 combines 3 different ST boards. This approach is inconsistent with
the support for the rest of the nucleo boards, where each board is in separate folders.
Also nucleo-144 is no longer reserved for STM32F7 chips but other families also use this format.
After this commit nucleo-144 is divided into 3 boards:
- nucleo-f746zg
- nucleo-f767zi
- nucleo-f722ze
* Nucleo-L432KC board was missing internal MCU DAC code.
* DAC is now available on PA4/A3 and /dev/dac0 when enabled.
* Updated info on ADC inputs (PA6/A5,PA7/A6) depending on configuration.
Signed-off-by: Tomasz 'CeDeROM' CEDRO <tomek@cedro.info>
that pr requires chip turn on CONFIG_DRIVERS_BLUETOOTH to use bluetooth,
but not all defconig enable this option, so let's map bt_driver_register
to bt_netdev_register in header file in this case, and revert the unnessary
change in the related chip and board folders.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Implement PIC loading in armv8-m qemu,
for example: load address-independent AP ELF in the bootloader,
and the text segment in AP ELF is XIP,
no need to apply for memory and modify it.
Two config:
bootloader abbreviation bl:
use romfs to load ap elf, use the boot command to parse and jump to ap
application abbreviation ap:
run os test
We need to compile ap first, then compile bl.
compile step:
./tools/configure.sh mps3-an547:ap
make -j20
mkdir -p pic
cp boot pic/.
genromfs -a 128 -f ../romfs.img -d pic
make distclean -j20
./tools/configure.sh mps3-an547:bl
make -j20
run qemu:
qemu-system-arm -M mps3-an547 -m 2G -nographic -kernel nuttx.bin \
-gdb tcp::1127 -device loader,file=../romfs.img,addr=0x60000000
nsh> boot /etc/boot
ap> ostest
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
The segment of the Xen PVH boot protocol was not specified during linking and was placed before .loader.text, causing the boot to fail
Signed-off-by: liwenxiang1 <liwenxiang1@xiaomi.com>
Summary:
1. The start location of FLASH reserves the extended bootloader
2. DTB data is reserved at the start location of RAM
Signed-off-by: wangming9 <wangming9@xiaomi.com>
Signed-off-by: lipengfei28 <lipengfei28@xiaomi.com>
Added a flash driver for the STM32G4 series. The primary change here is
the addition of stm32g4xxx_flash.c. This file uses the STM32L4 flash
driver as a template. The primary difference is the accounting for dual
banks with different page sizes.
Fixed error while building b-g474e-dpow1/buckboost. It was possible (technically) to have page be used uninitialzied. Changing the if statement to default to using a flash_page_size == 2048 fixes this issue.
Avoid compilation errors due to insufficient flash in CI
Configuration/Tool: same70-xplained/mcuboot-loader,CONFIG_ARM_TOOLCHAIN_GNU_EABI
2024-10-14 16:17:34
arm-none-eabi-ld: /github/workspace/sources/nuttx/nuttx section `.ramfunc' will not fit in region `flash'
arm-none-eabi-ld: region `flash' overflowed by 52 bytes
arm-none-eabi-ld: warning: /github/workspace/sources/nuttx/nuttx has a LOAD segment with RWX permissions
make[1]: *** [Makefile:212: nuttx] Error 1
make: *** [tools/Unix.mk:551: nuttx] Error 2
make: Target 'all' not remade because of errors.
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
/usr/bin/ld: nuttx.rel: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
the detailed warning info:
ccarm: Warning: Unknown option "-Wno-cpp" ignored. Did you mean "--nocpp"?
ccarm: Warning: Unknown option "-pipe" passed to linker
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
Follow the elf format, correct the memory region flag description:
Executable 0x1, Writable 0x2, Readable 0x4
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
tc32-elf-ld generated: In function `nrand_r':
/data/project/code/vela-pt/nuttx/libs/libc/stdlib/lib_srand.c:241: undefined reference to `__fixunsdfsi'
telink compiler do not support float point, so set LIBC_RAND_ORDER
to be 0 to avoid function srand() use float point.
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
gprof can analyze code hot spots based on scheduled sampling.
After adding the "-pg" parameter when compiling, you can view the code call graph.
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
The default bpp is STM32_LTDC_L1_L8, when TM32_FB_CMAP=y,and The default bpp is STM32_LTDC_L1_RGB565 when TM32_FB_CMAP=n. The color-format bpp of stm32f429i is 16, so we should be disable TM32_FB_CMAP, otherwise fb demo will result in an error.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
up_interrupt_context indicates that we self inside interrupt/handler mode,
replaced to private function is_nesting_interrupt to make less confused.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
The case want to determine if a interrupt with higher priority and the
interrupt preemption occurred, but up_interrupt_context indicates that we
self inside interrupt/handler mode. As we previously did not handle the
ramvector interrupt correctly, after update breaked the case. We should
use a more clear private function is_nesting_interrupt.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
during migration from legacy pinout some of the FMC pins were ommited because
their names were identical to the new pinout, which didn't cause a compilation error.
This fixes LCD examples.
Also update incomplete stm32f769i-disco FMC support to avoid this kind of bug in the future
riscv_internal.h is used literally everywhere, while the SBI definitions
are needed only by whomever needs the services.
Having the SBI definitions:
a) Copied from OpenSBI (why has this been done? even the names are same)
b) Presented publicly to 99% of risc-v modules
creates a build error when building with OpenSBI, due to duplicate
definitions of the SBI service identifiers:
In file included from /nuttx/arch/risc-v/src/common/riscv_internal.h:40,
from /nuttx/arch/risc-v/src/chip/chip.h:32,
from board/mpfs_domain.c:30:
/nuttx/arch/risc-v/src/common/riscv_sbi.h:36: error: "SBI_EXT_BASE" redefined [-Werror]
36 | #define SBI_EXT_BASE 0x00000010
and so forth...
Fix this by removing riscv_sbi.h i.e. not exposing the ABI publicly.
Add heap current used to note.
Plot it in segger sysview data plot.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
Signed-off-by: Neo Xu <neo.xu1990@gmail.com>
1. Kconfig - Removed USART1 config option from STM32_STM32G47XX. Not necessary to adding LPUART functionality. 2. stm32_lowput.c - Added extra check from STM32G4 board because that is the only with LPUART functionality. 2. stm32_serial.c - Removed unneeded function (stm32_serial_get_lpuart). Fixed up_putc return bug. Added configuration for DMAMAP_LPUART RX and TX for STM32G4XXX only. The G4 is the only in this family with LPUART and uses a DMAMUX unlike the others.
1. Removed 1WIRE LPUART refereences in Kconfig and stm32_uart.h. There is no support for LPUART currently in stm32_1wire.c. 2. Removed references to LPUART under DMA_V2 ifdefs. STM32G4 uses DMA_V1, and I saw that none of the chips DMA_V2 (F20, F4) have LPUARTs. AFAIK the only chip in the stm32 folder that has LPUART peripherals is the STM32G4.
Removed unnecessary brackets and empty lines
Added lpuartnsh (LPUART NuttShell) config to the nucleo-g474re board configurations. nsh uses USART3 by default. lpuartnsh uses nsh as a template, changes the serial console to LPUART1, and adds the DMA configs to enable DMA for the LPUART.
Added support for using the lpuart prescaler register. Without prescaling the apbclock, 9600 baud is not supported on the G474RE. By utilizing the prescaler, when necessary, we can support nearly any baud rate (300 baud to 30M Mbaud). lowputc defaults to a prescaler of 16 for the lpuart so standard baud rates (9600 to 115200) are supported early in the boot process. Later in stm32_serial.c the ideal prescaler and BRR values are determined.
Added ifdef statements for LPUART code sections not compatible with other chips.
Changed LPUART BRR calcuation to use 64-bit integers.
Feedback from nuttx pull request. Added brackets around single line if/else statements. Reordered lpuartnsh defconfig file.
Fix lpuart brr calculation after attempting to break the calculation into 2 lines.
Removed TAB
read content of undefinedinsn address, and compare it with what it is in elf to check if there is a ram bit flip
Signed-off-by: liaoao <liaoao@xiaomi.com>
Summary
MPS-521 support Dual Cortex-M33 and maybe suitable for AMP-like
case which is for AUTO OS, the change
1. add support for single core at msp-521 with nsh bringup
2. testing with ostest
TODO:
Dual core support for flat-build
Dual CORE support for Protected Build
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
Signed-off-by: ligd <liguiding1@xiaomi.com>
Summary
1. add Protected build Support for ARM MPS AN500
2. refine mps Memory layout configure and enable MPU support
Note
1. ostest for an547:nsh
2. ostest for an500:nsh and an500:knsh
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
Signed-off-by: ligd <liguiding1@xiaomi.com>
This commit reimplemented the NuttX32 multiboot1 wrapper:
1. Fixed the issue of SMP AP booting.
2. Reduced memory copy overhead. We only need to copy .realmode section
now.
3. Move the multiboot1 header to intel64_head.S.
Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
fix previous problemc
added defconfig for weact-stm32h743:nshusb
board.h
Wrong column position or missing blank line before comment: FIX
hopefully last commit
- Fix `MAKE_PC_FROM_RA` macro to consider the instruction region
base address;
- Add sanity check for calculated PC and SP registers;
- Check if the stack pointer is within the interrupt stack to
enable backtrace dump if an exception occurs during the ISR;
This defconfig is an example of the recorded stack and it became
faulty recently after the implementation of the `up_current_regs`
functions. The `noinstrument_function` directive must be used for
preventing it from being looped when instrumentation is enabled.
Also, this commit places `sched/instrument/stack_record.c` in IRAM.
Since the size of the shadow area will change during the script merging of global variables, it will lead to unpredictable number of links. After fixing, only three links are required.
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
LD: nuttx
arm-none-eabi-ld: /home/ligd/platform/mainline/nuttx/nuttx section `.bss' will not fit in region `ksram'
arm-none-eabi-ld: region `ksram' overflowed by 40 bytes
make[1]: *** [Makefile:212: nuttx] Error 1
make: *** [tools/Unix.mk:538: nuttx] Error 2
Signed-off-by: ligd <liguiding1@xiaomi.com>
arm-none-eabi-ld: /github/workspace/sources/nuttx/nuttx section `.bss' will not fit in region `ksram'
arm-none-eabi-ld: region `ksram' overflowed by 16 bytes
Signed-off-by: zhangshoukui <zhangshoukui@xiaomi.com>
This interface may be used by application specific logic to start
specified slave cpu core under the pseudo AMP case which is different
with armv7-a/armv8-a SMP. Support for this function is required by
board-level logic if CONFIG_BOARDCTL_START_CPU is selected.
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
After changing sp, following functions calling will result
in unpredictable behavior in case of jumping
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
Revert "Parallelize depend file generation"
This reverts commit d5b6ec450f.
parallel depend ddc does not significantly speed up compilation,
intermediately generated .ddc files can cause problems if compilation is interrupted unexpectedly
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
- Edited linker script for shmem to have condition according to cores selected.
- Added new configuration for nsh_cm7_rptun and nsh_cm4_rptun.
- Appended RPTUN bringup code in stm32_bringup.c
Signed-off-by: Nonpawit Ekburanawat <nonpawit.ek@gmail.com>
add configs with PCI serial console for qemu-intel64 so we can run NuttX on bare
metal Intel HW with serial port card
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
prepare 16550 UART driver to support PCI:
- [breaking change] change argument of uart_ioctl() from `struct file *filep` to `FAR struct u16550_s *priv`
Also fix moxart_16550.c build related to this change
- [breaking change] change argument of uart_getreg() and uart_putreg from `uart_addrwidth_t base` to `FAR struct u16550_s *priv`
Also fix arch/x86/src/qemu/qemu_serial.c and arch/x86_64/src/intel64/intel64_serial.c related to this change
- [breaking change] change argument of uart_dmachan() from `uart_addrwidth_t base` to `FAR struct u16550_s *priv`
- move `struct u16550_s` to public header
- generalize UART_XXX_OFFSET so we can use it with any register increment
- make u16550_bind(), u16550_interrupt(), u16550_interrupt() public
- remove arch/or1k/src/common/or1k_uart.c and use common 16550 MIMO interfacve
- change irq type in `struct u16550_s` from uint8_t to int to match MSI API
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
move MCR_OUT2 configuration from qemu-intel64/src/qemu_boot.c to common code
also leave this option disabled for qemu-intel64 as it's not required
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
Some of PCI drivers require OS interfaces that can't be executed in the INIT context.
In that case we have to postpone PCI drivers probing and call it for example
in board initialization logic.
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
reason:
1 On different architectures, we can utilize more optimized strategies
to implement up_current_regs/up_set_current_regs.
eg. use interrupt registersor percpu registers.
code size
before
text data bss dec hex filename
262848 49985 63893 376726 5bf96 nuttx
after
text data bss dec hex filename
262844 49985 63893 376722 5bf92 nuttx
size change -4
Configuring NuttX and compile:
$ ./tools/configure.sh -l qemu-armv8a:nsh_smp
$ make
Running with qemu
$ qemu-system-aarch64 -cpu cortex-a53 -smp 4 -nographic \
-machine virt,virtualization=on,gic-version=3 \
-net none -chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel ./nuttx
Signed-off-by: hujun5 <hujun5@xiaomi.com>
