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>
