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>
1. refactor the ghs/gcc/clang/armclang toolchain management in CMake
2. unify the cmake toolchain naming style
3. support greenhills build procedure with CMake
4. add protect build for greenhills and gnu toolchain with CMake
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
reason:
In x86_64, g_current_regs is still used for context switching.
This commit fixes the regression from https://github.com/apache/nuttx/pull/13616
Signed-off-by: hujun5 <hujun5@xiaomi.com>
all os-api those have post/wait feature will not allowed in pm_callbacks
and pm_handler, until we support by cpu/tcb sched_lock and add
sched_lock/unlock back here. Then should revert this commit.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
add arm64 qemu pm compatible for demo pm_idle in not smp & smp usage
demo, chip should based on demo to add more operation in pm_idle_handler
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
Summary:
Due to the modification of 4244610, the heap_size may be used on SRAM1, which can lead to misconfiguration problems for some mps qemu configurations (e.g.MPS3) that use extern DDR as the heap, refer to the previous issue VELAPLATFO-34555.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Signed-off-by: ligd <liguiding1@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>
Macro definitions such as _S in public header files can cause compilation problems under the MSVC compiler.
Move macro definitions that are not used in public locations to the corresponding files
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
nxsem_tickwait correctly sleeps more than 1 tick. But nxsem_tickwait_uninterruptible
may wake up to a signal (with -EINTR), in which case the tick + 1 must also
be taken into account. Otherwise the nxsem_tickwait_uninterruptible may
wake up 1 tick too early.
Also fix the nxsem_tickwait to return with -ETIMEDOUT if called with delay 0.
This is similar to e.g. posix sem_timedwait.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This fixes two issues with the tick timer
1) Each tick was longer than the requested period. This is because setting
the compare register was done by first reading the current time, and only
after that setting the compare register. In addition, when handling the
timer interrupts in arch_alarm.c / oneshot_callback, the current_tick is
first read, all the tick handling is done and only after that the next tick
is started. The whole tick processing time was added to the total tick time.
2) When the compare time is not aligned with tick period, and is drifting,
eventually any call to ONESHOT_TICK_CURRENT would either return the current
tick, or the next one, depending on the rounding of division by the
cycle_per_tick. This again leads to oneshot_callback randomly handling
two ticks at a time, which breaks all wdog based timers, causing them to
randomly timeout too early.
The issues are fixed as follows:
Align the compare time register to be evenly divisible by cycle_per_tick.
This will lead arm64_tick_current always to return the currently ongoing tick,
fixing 2). Also calculating the next tick's start from the aligned current
count will fix 1), as there is no time drift in the start cycle.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
1. extract dump from assert main flow
2. use OSINIT_PANIC for fatal error.
3. fix the method to judge kernel thread.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
anjiahao