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>
Since the introduction of the rp2350, the pico-sdk project has been
re-arranged and elf2uf2 has been merged in to a new 'picotool' binary
which is supplied and installed separately.
Normally ccache places the temporary files in `~/.ccache`, when invoking the container with
`-u <uid>:<gid>`
as e.g. Jenkins does, this might result in a invalid/unknown home folder.
Thus ccache tries to write to `/.ccache` which doesn't exist and the user doesn't have any permissions.
Explicitly set `CCACHE_DIR` to a folder with appropriate permissions.
Copied spi flash files from risc-v
Removed old spiflash from make.defs
KConfig modifications for common spiflash
Added new spiflash entry to make.defs
S2 Board config update
Modifications working on S2. Need fix on ROM function
Board fixes
Deleted old spiflash files
Fixes for smartfs operation
Set new HAL version
Fixed wrong change on S3
The docker image has not been updated we currently use that one
from 22 days ago.
It seems that the error encountered is due to an incomplete download. It will probably work fine if downloaded again..
https://github.com/apache/nuttx/actions/runs/10619683045/job/29437799464#step:7:1339
28.31
28.31 gzip: stdin: unexpected end of file
28.31 tar: Unexpected EOF in archive
28.32 tar: Unexpected EOF in archive
28.32 tar: Error is not recoverable: exiting now
Trying to reduce the size of the docker image, I found files and folders to be deleted.
For now, I have commented Swift from the Dockerfile because the package is too large.
* Fix nxstyle check so it does not report error on comments on the same
line as if statements
* Rework if statement checks
* Report warning instead of error for is statements check fail
Currently concerns only arm.
tools/ci/testlist/msys2.dat:
At the moment I only added the board nucleo-l152re:nsh
.github/workflows/build.yml:
Enabled cmake for msys2
The main objective is to determine if the examples really work or if they have been obsoleted.
The languages included in the list promote good interoperability with the NuttX API (C predominant).
This will show if they are worth integrating in NuttX.
**FFI method**
- Rust: bindgen or c2rust
- D: importC
- Swift: Bridging header or clang modulemap.
- Zig: `@cImport/@cInclude` or translate-c
It can only read the contents of the first buffer, so fblen should be changed to ensure that it can read the second buffer as well.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
The benefit of this approach is that in a multi-core AMP system,
a single coredump might contain memory information from other cores.
By analyzing this coredump along with the corresponding ELF files from
the other cores, you can reconstruct the crash site of those other
cores.
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
If we have a full memory raw dump, we can parse g_tcbinfo, g_npidhash,
and g_pidhash from the ELF to get NuttX thread info,
regardless of the crash dump log file.
support new command in gdb:
info threads
thread id
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
stack dump add new region `show stacks`, but this script is not support
now this is fixed with adding check condition for all lines contains stack word
Signed-off-by: xinbingnan <xinbingnan@xiaomi.com>
Traceback (most recent call last):
File nuttx/tools/parsetrace.py, line 29, in <module>
from pycstruct import pycstruct
ModuleNotFoundError: No module named 'pycstruct'
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
Create the nuttx.asm in the disassembly format using the objdump program.
NOTE:
'>', objdump doesn't take arguments for output file,
but result is printed to standard out, and is redirected.
Signed-off-by: fanjiangang <fanjiangang@lixiang.com>
Signed-off-by: chao an <anchao@lixiang.com>
This PR updates the Docker Image for NuttX CI, so that it builds Rust Apps correctly for QEMU RISC-V 64-bit. We add the Rust Target for `riscv64gc-unknown-none-elf` to the Docker Image.
In the next PR, we will call the Updated Docker Image to [compile the Rust App `leds_rust`](https://github.com/apache/nuttx/pull/12852), at every run of NuttX CI. This will validate whether Rust Apps are built correctly for QEMU RISC-V 64-bit.
Modified Files:
`tools/ci/docker/linux/Dockerfile`: Add Rust Target `riscv64gc-unknown-none-elf` for Docker CI
`tools/ci/platforms/ubuntu.sh`: Same as above, but for Ubuntu CI
`tools/ci/platforms/msys2.sh`: Same as above, but for MSYS2 CI
This PR fixes the build for Rust Apps and D Apps on QEMU RISC-V. Previously the Rust Build selected the [incorrect Rust Target riscv64i-unknown-none-elf](https://lupyuen.github.io/articles/rust5#rust-target-is-incorrect). Now the Rust Build selects the correct Rust Target: riscv64gc-unknown-none-elf.
This PR also fixes the 32-bit RISC-V Target for D Apps. D Targets ("riscv32") are named differently from Rust Targets ("riscv32gc"), this PR restores the correct Target Names.
Note that Rust Apps won't build correctly for QEMU RISC-V 32-bit. This requires a [Rust Custom Target for riscv32gc](https://lupyuen.github.io/articles/rust4#custom-target-for-rust), which will make the NuttX Makefiles much more complicated.
Also note that `hello_d` won't build correctly for 64-bit `rv-virt:nsh64`. To date, NuttX has never supported 64-bit RISC-V for D Apps.
Modified Files:
`tools/Rust.defs`: Rename the RISC-V ISA `imafdc` to `gc` for Rust Targets
`tools/D.defs`: Exclude the RISC-V ISA for D Targets
Rust/D support for RISC-V is broken after https://github.com/apache/nuttx/pull/11549,
since the target triple is quite different bewteen Rust/D toolchain and GCC,
only few RISC-V targets are supported by Rust toolchain now, so it's better to
construct target triple in Rust.defs/D.defs for RISC-V.
tools/testbuild.sh
added option -N Use CMake with Ninja as the backend.
updated help.
added date to print startup board
added HOST=Msys
github/workflows/build.yml
added option -N job docker
