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.
Copyright and Author information is missing from the License and was filled with
commit authorship
Signed-off-by: Jakub Janousek <janouja9@fel.cvut.cz>
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>
the author has submitted the CLA and the license can be migrated to ASF
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
both co-authors have submitted the CLA and the license can be migrated to ASF
Co-authored-by: Dong Heng <dongheng@espressif.com>
Co-authored-by: Abdelatif Guettouche <abdelatif.guettouche@espressif.com>
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
After https://github.com/apache/nuttx/pull/15075, the static
assertion at `nuttx/arch/xtensa/src/esp32s3/esp32s3_libc_stubs.c`
was being triggered when building any of the ESP32-S3's defconfigs.
This commit updates the reserved size to reflect the changes
introduced by the related PR.
continue work of a68b00206b
| commit a68b00206b
| Author: hujun5 <hujun5@xiaomi.com>
| Date: Mon Dec 9 20:48:09 2024 +0800
|
| cxd56_rtc.c: use small lock in arch/arm/src/cxd56xx/cxd56_rtc.c
|
| reason:
| We hope to remove all instances of spin_lock_irqsave(NULL).
|
| Signed-off-by: hujun5 <hujun5@xiaomi.com>
Signed-off-by: chao an <anchao@lixiang.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>
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 is continue work of https://github.com/apache/nuttx/pull/13726
We can utilize percpu storage to hold information about the
current running task. If we intend to implement this feature, we would
need to define two macros that help us manage this percpu information
effectively.
up_this_task: This macro is designed to read the contents of the percpu
register to retrieve information about the current
running task.This allows us to quickly access
task-specific data without having to disable interrupts,
access global variables and obtain the current cpu index.
up_update_task: This macro is responsible for updating the contents of
the percpu register.It is typically called during
initialization or when a context switch occurs to ensure
that the percpu register reflects the information of the
newly running task.
Signed-off-by: hujun5 <hujun5@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>
