The xipfs configuration enabled CONFIG_NXFLAT and the nxflatxip example,
whose build runs mknxflat to generate the module thunk. The NXFLAT tools
are not installed in the CI container, so every CI build of this
configuration failed with "mknxflat: command not found".
* xipfs keeps the file system, the xipfs command and the test suite. It
builds with a plain toolchain, so CI still covers the file system code.
* xipfs-nxflat adds CONFIG_NXFLAT and CONFIG_EXAMPLES_NXFLATXIP and is
excluded from the CI build list, the same treatment the other NXFLAT
configurations already get (eagle100:nxflat, lm3s6965-ek:qemu-nxflat,
olimex-lpc1766stk:thttpd-nxflat).
Impact: CI and board configurations only. No source or runtime change.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Ignores Python defconfig from esp32p4-tab5 board.
Python builds are excluded due to its long build time.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
New RISC-V chip port for the GigaDevice GD32VW55x (Nuclei N307, Wi-Fi 6
and BLE 5.3 combo), with the GD32VW553K-START board.
Core:
- ECLIC interrupt controller, clock tree (160 MHz / 40 MHz HXTAL),
64-bit machine timer, serial (USART0/UART1/UART2) and RTC.
- The instruction cache must be enabled in head.S or the UART drops
characters under load; the mask ROM uses the first 0x200 bytes of SRAM
so the image is linked at 0x20000200; the RTC needs PMU_CTL0.BKPWEN or
the register writes are silently discarded.
- The ECLIC only auto-clears the interrupt pending bit in hardware-vectored
mode, so the trap dispatch clears it for edge-triggered sources or they
re-fire forever (level-triggered peripherals clear their own).
Peripherals: DMA (8 channels), GPIO + EXTI, SPI (optional DMA), I2C0/I2C1
(the new STM32-v2-style IP, not the GD32F4 one), ADC, PWM and input
capture on the timers, both watchdogs, PROGMEM, TRNG and CRC. All use
the standard NuttX lower-half interfaces and direct register access, not
the vendor SPL. Three user LEDs (GPIOC), and a software reset through the
Nuclei SysTimer.
Internal flash: it is a system-in-package NOR die behind the real-time
decryption block, so it is not programmed through the FMC registers -- the
driver goes through the mask ROM API (rom_flash_*), the same way the
vendor code does. PROGMEM can be mounted as LittleFS; the region sits
below the Wi-Fi NVDS and must not overlap it.
Wi-Fi (wlan0), station and softAP:
- The MAC/PHY, RF and WPA supplicant are linked as prebuilt BSD-3
libraries. They are RTOS-agnostic, so the OS binding is a sys_* facade
on NuttX primitives (gdwifi/wrapper_nuttx.c). Critical sections mask by
ECLIC priority threshold, not by disabling every interrupt, or the MAC
misses its microsecond deadlines.
- The lwIP stack of the SDK is not used: the interface is a
netdev_lowerhalf driver driven by the standard tools (wapi, ifup, renew,
ping, dhcpd). EAPOL is handed to the supplicant instead of the IP
stack. The lowerhalf "priority" field is the work-queue id (HPWORK/
LPWORK), not a task priority -- a wrong value makes receive() never run
and every packet is dropped.
- The vendor gives the radio 32 KB of shared SRAM as an extra heap; this
needs CONFIG_MM_REGIONS >= 2 or the kernel silently drops the region.
- The DHCP client needs CONFIG_NETUTILS_DHCPC_BOOTP_FLAGS=0x8000 so the
server answers the OFFER by broadcast.
- softAP (wapi master mode -> wifi_management_ap_start): the single-VIF
firmware does station or AP at a time. Use WPA2, not WPA3: the SAE
handshake is deep on the stack and overflows the elliptic-curve crypto
with the default task stacks, so the Wi-Fi configs raise
CONFIG_INIT_STACKSIZE/DEFAULT_TASK_STACKSIZE.
Vendor SDK: cloned by the build at "context" time, pinned to a validated
commit and patched in place -- so CI can build with nothing preinstalled,
the same pattern as esp-hal-3rdparty. The prebuilt libraries are built
for the hard-float ilp32f ABI.
BLE 5.3, marked EXPERIMENTAL and off by default: the prebuilt libble is an
all-in-one controller plus RivieraWaves host (GAP/GATT/SMP inside the blob)
with no HCI transport, so the port drives the vendor host directly
(ble_adp_*, ble_adv_*, ble_gap_*) instead of registering a bt_driver_s.
The SDK's radio interrupt handlers must be attached to the NuttX IRQ table
(they are reached through the ECLIC hardware vector table in the vendor
build); attaching also keeps --gc-sections from dropping them. It ships
with no configuration; enabling it advertises as "NuttX", connectable.
Boards: gd32vw553k-start with nsh, wapi, sta_softap, periph and littlefs
configurations, and the board added to the CI build list.
Tested on hardware (GD32VW553K-START): NSH, the peripheral drivers
(TRNG entropy and the LEDs exercised), LittleFS (write, read, survives a
reboot), the full Wi-Fi station path (scan, WPA2, DHCP, ping to the
internet), the softAP (a client associates with WPA2, gets an address
from the board's DHCP server, and pings the board), and BLE (advertises as
"NuttX"; a central connects and enumerates the GATT database).
Assisted-by: Claude Opus 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Move the stm32l1 sources, headers and boards into arch/arm/src/stm32l1,
arch/arm/include/stm32l1 and boards/arm/stm32l1, then finalize the split:
source each split family directly in arch/arm/Kconfig and boards/Kconfig and
remove the now-empty combined arch/arm/src/stm32 and boards/arm/stm32 trees.
BREAKING CHANGE: The legacy STM32 architecture and board paths were split into
stm32f1, stm32l1, stm32f2, stm32f3, stm32f4, and stm32g4 directories.
Out-of-tree boards must move from stm32 to the matching split family.
Signed-off-by: raiden00pl <raiden00@railab.me>
Even after installing the ftdi library on CI it doesn't work to
compile the sim:ft2232h_gpio, so remove it from CI test.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
This commit adds a defconfig for enabling the NuttX Web Panel on
ESP32-P4. It also create entries to automatically call the Web
panel application after system's boot up.
The `webpanel` is removed from regular ESP32-P4 CI testing because
it ships with Python and that would overload CI infrastructure.
Signed-off-by: Tiago Medicci Serrano <tiago.medicci@espressif.com>
Remove `esp32p4-function-ev-board:python` defconfig from being
built for the regular CI pipelines to avoid overloading it.
Signed-off-by: Tiago Medicci Serrano <tiago.medicci@espressif.com>
For boards b-g431b-esc1/nsh, nucleo-g431kb/nsh and nucleo-g431rb/nsh,
the `.data` section of nuttx.elf overflows the 128 KB flash region by a
few hundred bytes on default GNU EABI builds:
arm-none-eabi-ld: nuttx section `.data' will not fit in region `flash'
arm-none-eabi-ld: region `flash' overflowed by 296 bytes
Enabling CONFIG_LTO_FULL=y in the corresponding defconfigs brings flash
usage back below the 128 KB limit (~93%).
Additionally, fix arch/arm/src/cmake/gcc.cmake so that when LTO is
enabled it always uses the gcc-ar / gcc-nm / gcc-ranlib wrappers, not
just when CONFIG_ARM_TOOLCHAIN_GNU_EABI is also set. CI tooling (via
tools/testbuild.sh) configures cmake first, then flips the toolchain
choice in .config with kconfig-tweak before running `cmake --build`.
With the previous "ARM_TOOLCHAIN_GNU_EABI && !LTO_NONE" guard the
regen step would switch to plain `ar` for the .a files, even though the
linker driver picked at configure time is still arm-none-eabi-g++ and
the object files contain GCC LTO IR. The result was a flood of
"undefined reference to `printf' / `free' / `puts' ..." link errors
when running tools/testbuild.sh -A -N -R on the *_CLANG variants.
Now that we are inside gcc.cmake the toolchain is unambiguously GCC,
so dropping the redundant CONFIG_ARM_TOOLCHAIN_GNU_EABI conjunct keeps
the LTO-aware ar wrappers in place across kconfig-tweak toolchain
switches.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Introduce minimal chip support for the STMicro STM32N6 family
(Cortex-M55, ARMv8.1-M with TrustZone and FPU), sufficient to bring
up an NSH console over USART1.
Scope (deliberately minimal first drop):
- Chip selector ARCH_CHIP_STM32N6 wired into arch/arm/Kconfig and
chip-name mapping ("stm32n6").
- Sub-Kconfig under arch/arm/src/stm32n6 with the STM32N657X0 chip
selector and a single user-selectable USART (USART1).
- Boot path: stm32_start with a naked dispatcher that clears the
boot-ROM MSPLIM/PSPLIM stack limits before any compiler-emitted
prologue, then runs vector relocation and SRAM-only heap init.
The chip runs entirely in the Secure state; SAU is left in its
reset configuration.
- PLL1-based clock tree fed from HSI64 targeting 200 MHz CPU, with
USART1 kernel-clock routed to HSI for a predictable BRR that is
independent of any later clock change.
- Low-level USART driver with full serial framework support.
stm32_serial.c is adapted from arch/arm/src/stm32h5/stm32_serial.c
(sibling ARMv8-M Mainline port with the same USART IP), stripped
of DMA-RX, LPUART, the per-USART2..5 plumbing, RS-485 driver-enable,
TIOCSINVERT/SWAP and HALFDUPLEX paths.
- SysTick system timer.
- GPIO, PWR and RCC helpers.
TrustZone, MPU, I/D-cache and Helium (MVE) are left disabled to
minimise bring-up surface; these will be added in follow-up patches
alongside the drivers that need them.
Signed-off-by: ImBonkers <samuelnlinden@pm.me>
This is necessary because new defconfig were recently added to
Xtensa-based Espressif SoCs and the build job may exceed 2 hours.
In order to avoid increasing job timeout, a specific job for each
supported SoC (ESP32, ESP32-S2 and ESP32-S3) was created instead.
Signed-off-by: Tiago Medicci Serrano <tiago.medicci@espressif.com>
This bl602evb:elf configuration has caused job risc-v-01 to fail on several occasions.
riscv-none-elf-ld: cannot find /github/workspace/sources/nuttx/arch/risc-v/src/crt0.o: No such file or directory
https://github.com/apache/nuttx/pull/17792
Added -bl602evb:elf to the risc-v-01.dat file to skip the build.
Signed-off-by: simbit18 <simbit18@gmail.com>
- CMake added board Raspberry Pi Pico
- Added the entry:
CMake,raspberrypi-pico:bmp280
to the file arm-06.dat.
- Moved the search for the Python 3 interpreter to the
root CMakefile to avoid unnecessary repetition.
Signed-off-by: simbit18 <simbit18@gmail.com>
Removed from the arm-05.dat file the entries:
CMake,nrf52832-dk:buttons
CMake,nrf52832-dk:wdog
CMake,nrf52840-dk:adc
CMake,nrf52840-dk:buttons
CMake,nrf52840-dk:pwm
CMake,nrf52840-dk:qspi
CMake,nrf52840-dk:timer
present in the jumbo configuration
Signed-off-by: simbit18 <simbit18@gmail.com>
This PR adds support for the CI system for native Windows as well. It allows you to build NuttX on GitHub and test it locally for Windows users.
With these CI tools with PowerShell scripts, it is possible to build NuttX for Windows Native using (for now only) Cmake + Ninja with the same logic as the CI system with Bash scripts.
This allows the msvc job to be used not only with the simulator (currently only with Visual Studio 17 2022), but also with other architectures using the same Windows runner to get more coverage and avoid future breakage.
As with the other jobs, we use artifacts to save the compilation result at the end of the workflow execution (previously for the simulator it was not done).
The proposed solution is based on the following additions and modified:
Modified Files
buildyml -> only CI Jobs MSVC
New Files in tools/
ci/cibuild.ps1 -> Added Powershell script for Run the CI Builds
ci/platforms/windows.ps1 -> Added Powershell script for installing toolchains and tools.
testlist/windows.dat -> Target (Add sim (msvc), risc-v arm)
tools/testbuild.ps1
We tested the NuttX build on GitHub and locally.
How we build on GitHub and test locally.
Locally
cd .\nuttx\tools\ci\
.\cibuild.ps1 -n -i -A -C -N .\testlist\windows.dat
Signed-off-by: simbit18 <simbit18@gmail.com>
This prevents CI from testing esp32s3-devkit:python automatically,
avoiding it to be overloaded. Manual testing can be triggered to
test xtensa-03.dat.
Signed-off-by: Tiago Medicci Serrano <tiago.medicci@espressif.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
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 PR splits the CI Build Job sim-01 and adds sim-03:
Before the Split: Simulator Jobs take up to 1.5 hours to complete
- sim-01 (1 hour 31 mins): adb, citest, lvgl, matter
- sim-02 (28 mins): posix_test, sqlite
After the Split: Simulator Jobs will complete within 1 hour
- sim-01 (58 mins): adb, citest
- sim-02 (35 mins): lvgl, matter
- sim-03 (28 mins): posix_test, sqlite
This will help us comply with the ASF Policy for GitHub Actions, as explained here: https://github.com/apache/nuttx/issues/14376
nucleo-144 combines 3 different ST boards. This approach is inconsistent with
the support for the rest of the nucleo boards, where each board is in separate folders.
Also nucleo-144 is no longer reserved for STM32F7 chips but other families also use this format.
After this commit nucleo-144 is divided into 3 boards:
- nucleo-f746zg
- nucleo-f767zi
- nucleo-f722ze
This PR creates the new CI Build Jobs `arm64-01` and `x86_64-01`. The new jobs will split and offload the Arm64 and x86_64 Build Targets from `other`. This will reduce our usage of GitHub Runners, to comply with the ASF Policy for GitHub Actions. (Recently we see more PRs for Arm64 and x86_64)
Before the Split: Simple PRs (One Arch and/or One Board) for Arm64 and x86_64 require almost 1 hour for CI Build
- `other` (57 mins): AVR, SPARC, x86, PinePhone, QEMU Arm64, QEMU x86_64
After the Split: Simple PRs for Arm64 and x86_64 will complete under 30 mins
- `other` (24 mins): AVR, SPARC, x86
- `arm64-01` (29 mins): PinePhone, QEMU Arm64
- `x86_64-01` (9 mins): QEMU x86_64
To skip more unnecessary builds: Our Build Rules `arch.yml` shall ignore the label "Area: Documentation", so that a Simple PR + Docs is still a Simple PR. Previously we experienced longer CI Build Times, just because we added docs to our Simple PR. (Now our PR shall be built exactly like a Simple PR)
The updated CI code is explained here: https://github.com/apache/nuttx/issues/13775
To speed up the CI Workflow, this PR splits the CI Build Jobs for RISC-V into smaller jobs. Each job will now complete within 1 hour.
Before the PR: There are 2 jobs for RISC-V, each requiring more than 1.5 hours
- `risc-v-01` (1 hour 42 mins): BL602, Ox64, ESP32-C3 / C6 / H2
- `risc-v-02` (1 hour 41 mins): K230, Icicle, QEMU, RV32M1-Vega
After the PR: The build is spread across 6 jobs for RISC-V, each job completes within 1 hour
- `risc-v-01` (19 mins): BL602, Ox64
- `risc-v-02` (44 mins): ESP32-C3
- `risc-v-03` (45 mins): ESP32-C6, ESP32-H2
- `risc-v-04` (31 mins): K230, Icicle
- `risc-v-05` (41 mins): QEMU CITest
- `risc-v-06` (38 mins): Rest of QEMU, RV32M1-Vega
Following the same convention as the Arm32 Build Jobs, the above jobs are sorted by Target Name. Performance of the RISC-V Build Jobs is discussed in https://github.com/apache/nuttx/issues/13775
CI Build Job `arm-05` (runtime 2 hours) has become the Performance Bottleneck for CI Workflow. That's because `arm-05` builds too many targets for nRF, RP2040, SAM 3, SAM A and SAM D. This PR splits `arm-05` into multiple smaller jobs, to reduce the CI Build Duration.
Before the PR: `arm-05` is overloaded, build requires 2 hours
- `arm-05` (2 hours): nRF, RP2040, SAM 3, SAM A, SAM D
- `arm-06` (56 mins): STM32 [a-m]*
After the PR: `arm-05` is offloaded (to `arm-06` and `arm-07`), completes within 1 hour
- `arm-05` (47 mins): nRF
- `arm-06` (1 hour): Reserve for RP2040 exclusively
- `arm-07` (1 hour 15 mins): SAM 3, SAM A, SAM D, STM32 [a-m]*
Build Jobs are sorted by Target Name. So we cascade the changes and rename the Build Jobs: `arm-07` becomes `arm-08`, `arm-08` becomes `arm-09` etc. Then `arm-13` becomes a new job `arm-14`. (Which we added to `build.yml`)
Performance of `arm-05` is discussed in https://github.com/apache/nuttx/issues/13775 and https://github.com/apache/nuttx/issues/12773
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
find: boards/risc-v/esp32c3/esp32c3-devkit/configs/cxx: No such file or directory
find: boards/risc-v/esp32c3/esp32c3-devkit/configs/wifi: No such file or directory
There have been errors like below on macOS for sim:libcxxtest
```
Error: /Applications/Xcode.../include/mach/vm_page_size.h:59:44:
error: expected ';' after top level declarator
```
This patch tries to disable that check on macOS.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
