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>
reason:
svc call may trigger hardfault
Background
The origin of this issue is our desire to eliminate the function of storing
"regs" in g_current_regs and instead utilize (*running_task)->xcp.regs for storage.
The benefits of this approach include faster storage speed and
avoiding multiple accesses to g_current_regs during context switching,
thus ensuring that whether returning from an interrupt or an exception,
we consistently use this_task()->xcp.regs
Issue Encountered
However, when storing registers, we must ensure that (running_task)->xcp.regs is invalid
so that it can be safely overwritten.
According to the existing logic, the only scenario where (running_task)->xcp.regs
is valid is during restore_context. We must accurately identify this scenario.
Initially, we used the condition (running_task)==NULL for this purpose, but we deemed
this approach unsatisfactory as it did not align well with the actual logic.
(running_task) should not be NULL. Consequently, we adopted other arch-specific methods for judgment,
but due to special logic in some arch, the judgment was not accurate, leading to this issue.
Solution:
For armv6-m, we haven't found a more suitable solution, so we are sticking with (*running_task)==NULL.
For armv7-m/armv8-m, by removing support for primask, we can achieve accurate judgment.
PRIMASK is a design in armv6-m, that's why arm introduce BASEPRI from armv7-m.
It's wrong to provide this option for armv7-m/armv8-m arch.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
The Kconfig of system/usbmsc has updated to support setting paths that bind to LUN at runtime.
More details: https://github.com/apache/nuttx-apps/pull/2876
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Add an option to use HSE on the Nucleo-H563ZI with board modification. This is enabled through board Kconfig.
It supplies the same PLL output frequencies using the HSE instead of HSI, for significantly more precise clocks.
reason:
up_set_current_regs initially had two functions:
1: To mark the entry into an interrupt state.
2: To record the context before an interrupt/exception. If we switch to
a new task, we need to store the upcoming context regs by calling up_set_current_regs(regs).
Currently, we record the context in other ways, so the second function is obsolete.
Therefore, we need to rename up_set_current_regs to better reflect its actual meaning,
which is solely to mark an interrupt.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
The large max command line length may cause stack overflow.
Test
./tools/configure.sh lm3s6965-ek:qemu-flat
make -j16
qemu-system-arm -semihosting \
-M lm3s6965evb \
-device loader,file=nuttx.bin,addr=0x00000000 \
-netdev user,id=user0 \
-serial mon:stdio -nographic
Link: https://github.com/apache/nuttx-apps/pull/2850
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Adds ADC support with minimal feature set (no DMA or Timers etc). A new nucleo-h563zi configuration was added to
provide easy testing with the adc example NSH addon.
Fix Kconfig spacing to tabs
Old upstream from @acassis:
d97227eddd/nuttx/configs/efm32gg-pnbfano/include/board.h
chip/efm32_clockconfig.c:860:24: error: 'BOARD_SWOPORT_LOCATION' undeclared (first use in this function);
did you mean 'BOARD_UART0_ROUTE_LOCATION'?
860 | regval |= ((uint32_t)BOARD_SWOPORT_LOCATION <<
| ^~~~~~~~~~~~~~~~~~~~~~
| BOARD_UART0_ROUTE_LOCATION
chip/efm32_clockconfig.c:860:24: note: each undeclared identifier is reported only once for each function it appears in
chip/efm32_clockconfig.c:866:20: error: 'BOARD_GPIO_SWOPORT' undeclared (first use in this function)
866 | efm32_configgpio(BOARD_GPIO_SWOPORT);
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: chao an <anchao@lixiang.com>
Split nucleo-f4x1re into nucleo-f401re and nucleo-f411re.
These are separate boards and should be in separate directories as it's
done for all other nucleo boards in NuttX
The PLL clock configuration was simplified on the assumption the clocks are correctly set in the board.h file. Instead of seperate conditions
for register components, assume the relevant PLL registers are fully defined in board.h. This should result in easier to understand defines in board.h
and simpler code flow in the standard clock configuration function.
Changes were mad in the board file alongside changing the arch files. Changes to board/stm32h5:
- PLL1 has been configured to use integer instead of fractional mode to reach the 250 MHz target. PLL2 and PLL3 configurations were
removed since they are currently unused in the H5 configuration.
- PLL1 output was verified by testing for changes in serial baud rate.
enable various types of common applications and libraries, and enable CMake CI checks.
To avoid regression issues in the build system
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
This patch fix _eronly value which is used during boot process to initialize
.data section to sram.
Since .data section is 4 byte aligned in flash, also _eronly must follow this
alignment to stay coherent with the start address of .data.
If one of the sections preceeding .data has a size which is not 4 byte aligned,
the _eronly value does not match with .data physical address resulting in wrong
copy of data section to sram and thus an almost immediate hardfault.
Signed-off-by: Federico Braghiroli <federico.braghiroli@gmail.com>
* It seems that they assume up_putc() and syslog() outputs to the
same device. Depending on the system and configurations, it's wrong.
* They are wrapped with "#if 0" and unused.
Fixes https://github.com/apache/nuttx/issues/14694
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>
