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>
`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
```
`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>
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>
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.
