Wire the RTL8720F to the shared Ameba I2C master driver
(arch/arm/src/common/ameba/ameba_i2c.c), reusing it unchanged.
Add the per-chip header arch/arm/src/rtl8720f/ameba_i2c_chip.h supplying
the chip's I2C wiring: two controllers (I2C0/I2C1) on their non-secure
register aliases (0x401c8000 / 0x401c9000), the APBPeriph function/clock
masks, the crossbar SCL/SDA pad-mux codes (59/60 and 61/62), and
AMEBA_I2C_HAS_DMA_FIELDS=1 (the chip's I2C_InitTypeDef carries the DMA
request-level fields).
Add the board glue: rtl8720f_i2c.c registers I2C0 at /dev/i2c0
(PA22/PA23) and I2C1 at /dev/i2c1 (PA24/PA25), plus the build wiring
(Make.defs / CMakeLists.txt / ameba_board.mk pull in the common driver
and the fwlib ram_common/ameba_i2c.c data-table source), the bringup
registration hook and the board header declaration.
Add the i2c defconfig (minimal NSH with the i2ctool) and document the
config in the board index.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Wire the shared common UART driver
(arch/arm/src/common/ameba/ameba_uart.c) into RTL8720F. Add an
ameba_uart_chip.h supplying the per-chip UART parameters: two
general-purpose controllers (UART0/UART1), their non-secure register
bases (0x401C3000 / 0x401C4000 -- the fwlib UART_DEV_TABLE points at
the non-secure alias), NVIC vectors, APBPeriph function/clock masks
and the crossbar TX/RX pad-mux function codes.
The fwlib ROM UART routines index data tables (UART_DEV_TABLE,
APBPeriph_UARTx) that live in fwlib ram_common/ameba_uart.c, so that
source is compiled in when CONFIG_AMEBA_UART is set. Wire
CONFIG_AMEBA_UART into Make.defs/CMakeLists/ameba_board.mk, add the
board port table (UART0 at /dev/ttyS1, PA22 TX / PA23 RX, 115200 8N1)
with bringup registration, a uart config and board documentation.
Hardware-verified on rtl8720f_evb: serialrx/serialblaster over a
PA22-to-PA23 TX/RX loopback transferred all 2600 bytes intact.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
RTL8720F drives all GPIO through a single 32-pin port A controller
served by one NVIC vector, unlike RTL8721Dx (ports A/B) or RTL8721F
(ports A/B/C). Add an ameba_gpio_chip.h that configures the shared
common GPIO driver (arch/arm/src/common/ameba/ameba_gpio.c) for a
single port: AMEBA_GPIO_NPORTS=1, AMEBA_GPIO_PORT_IRQS={GPIOA} and
the APBPeriph_GPIO gate bits.
GPIO_INTStatusGet/ClearEdge live in the RTL8720F ROM symbol table, so
no fwlib ram_common object needs compiling in. Wire CONFIG_AMEBA_GPIO
into Make.defs/CMakeLists/Kconfig, add the board pin table (PA22 out,
PA23 in, PA24 interrupt) with bringup registration and a gpio config.
Hardware-verified on rtl8720f_evb: output, input and (falling-edge)
interrupt all confirmed via a PA22-to-PA24 loopback.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Wire the shared Ameba I2C master lower-half (arch/arm/src/common/
ameba/ameba_i2c.c) into the RTL8721F (amebagreen2) build through a
per-chip header (ameba_i2c_chip.h), and register the RTL8721F EVB
buses at /dev/i2cN.
Per-chip differences from the other Ameba SoCs (non-secure register
bases, crossbar pinmux codes, APB clock masks and the fwlib
I2C_InitTypeDef layout) are isolated in ameba_i2c_chip.h; no change to
the shared driver is needed.
Verified end-to-end on hardware against a second Ameba board acting
as an I2C slave: address ACK, register write and read-back over
repeated-START, and bus scan all pass on I2C0 (PA22/PA23).
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Add a shared NuttX I2C master lower-half for the Realtek Ameba I2C
controllers (I2C0/I2C1) in arch/arm/src/common/ameba, driven through
the SDK fwlib in polling mode. Per-chip wiring (controller count,
register bases, clock masks, crossbar pad-mux codes and the fwlib
I2C_InitTypeDef layout) lives in arch/arm/src/rtl8721dx/ameba_i2c_chip.h
so a port to the other Ameba chips only supplies a same-named header.
Each controller registers as /dev/i2cN from pke8721daf bring-up through
the stock I2C character driver; a dedicated `i2c` defconfig drives the
i2ctool for validation.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
esp32s3_bringup.c still guards on CONFIG_ESP32S3_RT_TIMER, includes
"esp32s3_rt_timer.h" and calls esp32s3_rt_timer_init(). None of those
exist any more: c17e16eaed ("xtensa/espressif: Update common-source
integration for Xtensa devices") deleted the chip-specific RT timer and
replaced it with the common-source HR Timer, and updated every other
esp32s3 board's bringup to CONFIG_ESPRESSIF_HR_TIMER /
"espressif/esp_hr_timer.h" / esp_hr_timer_init(). This board was missed.
The stale guard is not dead code: ESPRESSIF_WIRELESS selects
ESP32S3_RT_TIMER (which survives only as a deprecated alias that selects
ESPRESSIF_HR_TIMER), so enabling Wi-Fi on this board turns the guard on and
the build fails outright:
board/esp32s3_bringup.c:61:12: fatal error: esp32s3_rt_timer.h:
No such file or directory
No esp32s3-ws-lcd128 defconfig enables Wi-Fi, which is why CI has not
caught it.
Switch to the same guard, include and initializer the other esp32s3 boards
use. No functional change for the existing defconfigs: they leave both
ESP32S3_RT_TIMER and ESPRESSIF_HR_TIMER unset, so the block stays compiled
out.
Verified with esp32s3-ws-lcd128:nsh plus CONFIG_ESPRESSIF_WIFI=y (and the
Wi-Fi prerequisites the in-tree wifi defconfigs set: SCHED_LPWORK,
DRIVERS_WIRELESS/DRIVERS_IEEE80211, NETDEV_WIRELESS_IOCTL, IOB_NCHAINS,
TLS_TASK_NELEM, TIMER): the fatal error above before the change, a clean
build and image after it, with no other change to the configuration.
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Assisted-by: Claude Opus 5 (Claude Code)
A protected build on the ESP32 could only use the legacy IDF image format.
Kconfig allowed simple boot to be selected with BUILD_PROTECTED, because the
legacy format is only a default and not a select, but the result did not link
and then did not boot.
Simple boot has no second-stage bootloader. __start() maps the flash itself,
so everything it reaches must already be in RAM. kernel-space.ld pinned none
of it, and it did not place esp32_start at all, so the entry point went to the
flash the code was about to map. The chip loaded the RAM segments, jumped to
0x400d0ba4 and took an IllegalInstruction on the first instruction.
So this pins the bootloader, flash, ROM, clock and log objects that
bootloader_init() and map_rom_segments() reach, along with esp32_start itself,
and defines the six _image_* symbols that __start() needs. All of it is
behind CONFIG_ESPRESSIF_SIMPLE_BOOT, so a legacy build gets the same IRAM it
had before.
kernel-space.ld also had no `#include <nuttx/config.h>'. It held no
conditionals until now, so nothing showed the omission: the new blocks
compiled away silently and the link failed as if the file had not been
changed.
The default is unchanged. A protected build still selects the legacy format
unless the user clears CONFIG_ESP32_APP_FORMAT_LEGACY.
Verified on an ESP32-DevKitC V4, ESP32-D0WD-V3 revision 3.1, with
esp32-devkitc:knsh and the legacy format turned off. The kernel flashes at
0x1000 and the user image at 0x90000, with no bootloader and no partition
table. It maps seven segments, reaches NSH, and runs ostest to the same point
as the legacy build.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
BUILD_PROTECTED defaults ESP32S3_APP_FORMAT_LEGACY to y, so a protected build
has always needed the ESP-IDF second-stage bootloader. Nothing about the
protected layout requires it: the kernel and user images are described
entirely by ESP32S3_KERNEL_OFFSET, ESP32S3_KERNEL_IMAGE_SIZE and
ESP32S3_KERNEL_RAM_SIZE, and esp32s3_userspace() maps the user image itself.
Three obstacles stood in the way.
Those three symbols were gated on ESP32S3_APP_FORMAT_LEGACY, but
protected_memory.ld needs all of them for KIROM, KDROM, UIROM, UDROM, KDRAM
and UDRAM. Without them the region lengths underflow to 2**64-1 and the
kernel/user RAM split lands nowhere, which the hardware reports as a DRAM0
PMS monitor violation once the first user process runs. The offset becomes
0x0 for simple boot, where the image is flashed at the start of the device.
protected_memory.ld had no case for a 32 MB part, so FLASH_SIZE was
undefined there and ROM, UIROM and UDROM underflowed the same way.
flat_memory.ld has had the case all along.
kernel-space.ld defined none of the symbols simple boot needs
(_image_irom_*, _image_drom_*, _bss_*), and kept none of the early code
resident. __start() runs bootloader_init() and map_rom_segments() before any
flash mapping exists, so everything they reach has to be in RAM -- including
map_rom_segments() itself, which unmaps the MMU it is running from, and
nuttx_enter_critical(), reached from rtc_clk_init() by way of regi2c. These
mirror what esp32s3_sections.ld already does for the flat build.
Verified on an ESP32-S3-WROOM-2 (32 MB octal flash), esp32s3-devkit:knsh with
FLASH_MODE_OCT: boots to NSH and runs ostest, where it reaches the same
timedmutex abort as every other target. The legacy path is untouched.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
A full ostest run never reached the end on esp32-devkitc:knsh. It stopped in
the barrier test:
barrier_test: ERROR thread 6 create, status=12
ostest_main: Exiting with status 256
The cause is the interaction of two settings that are each reasonable on their
own. CONFIG_TLS_ALIGNED is set and CONFIG_TLS_LOG2_MAXSTACK is 13, so every
pthread stack must start on an 8 KiB boundary. The barrier threads take the
2 KiB default stack, so each one occupies an 8 KiB aligned slot. Eight of them
do not fit the 96 KiB user heap of a protected build once the tests before them
have fragmented it, and up_create_stack() fails:
up_create_stack: ERROR: Failed to allocate stack, size 2048
The flat build has the same two settings and passes, because its heap is
320 KiB against 96 KiB here.
So this lowers the barrier thread count for this configuration only. Four
threads still test a barrier, and they leave margin: six was the most that
ever started, so six would pass with none.
The user heap cannot grow far. User data has to sit in the MMU governed window
of SRAM2, which is 128 KiB in total, and the kernel holds the first 32 KiB of
it.
Verified on an ESP32-DevKitC V4, ESP32-D0WD-V3 revision 3.1. All four threads
reach the barrier and ostest reports "Exiting with status 0".
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
QEMU's b-l475e-iot01a machine models the STM32L4x5 core peripherals, but
not the QUADSPI controller or the on-board MX25R6435F flash. The nsh
configuration therefore panics during board bring-up, inside
stm32_qspi_initialize() -> mx25rxx_initialize() -> qspi_command(), before
the console has produced any output.
Add a qemu configuration that is nsh without CONFIG_B_L475E_IOT01A_MTD_FLASH
and the QSPI/MTD/SMARTFS chain that symbol selects. It boots to an NSH
prompt on USART1 under:
qemu-system-arm -M b-l475e-iot01a -nographic -kernel nuttx
Document the new configuration, including the fact that QEMU's STM32L4x5
USART model never calls qemu_chr_fe_accept_input() after the guest reads
RDR. Console input consequently stalls after the first byte or two when a
line is pasted or piped in, although typing at human speed works.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Expose the RTL8721F general-purpose UARTs through the shared Ameba serial
driver in arch/arm/src/common/ameba. Only the chip-specific glue is added:
a new ameba_uart_chip.h supplying the green2 register bases, IRQs, clock
masks and UART TX/RX pin-mux function codes, plus the build wiring and a
board port table registering UART0 at /dev/ttyS1. The common serial layer
is reused unchanged.
A new "uart" board config enables the driver with the serialrx and
serialblaster examples and runtime TERMIOS support.
Verified on RTL8721F EVB hardware with a PA24/PA25 loopback: single-message
echo, 2600-byte serialrx/serialblaster throughput with no loss, and TERMIOS
reconfiguration (CS7 data-bit truncation, parity and stop-bit ioctl
round-trip, and 9600 baud reprogramming) all pass.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
This change fixes NuttX’s CMake support when NuttX is embedded
in another project via add_subdirectory(). CMake’s CMAKE_SOURCE_DIR
and CMAKE_BINARY_DIR refer to the outermost project, causing NuttX
to access its .config, generated files, host tools, and build artifacts
in the parent project’s directories. The fix introduces NUTTX_DIR and
NUTTX_BINARY_DIR, based on CMAKE_CURRENT_SOURCE_DIR and
CMAKE_CURRENT_BINARY_DIR, and consistently uses them for NuttX
self-references while preserving existing standalone builds. It fixes
the Kconfig initialization failure reported in #19697 and allows an
embedded sim:nsh build to configure, build, and boot successfully.
The change affects only the CMake build system (not Make or Kconfig
defaults), requires the corresponding nuttx-apps change, and does not
extend add_subdirectory() support to cross-compiled non-sim boards due
to CMake’s toolchain-file limitation.
Fixes#19697.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Alan Carvalho de Assis <acassis@gmail.com>
HIDKBD_NOGETREPORT reads keyboard reports with DRVR_ASYNCH(), and that
macro is only defined when USBHOST_ASYNCH is set. The option selected
neither, so turning it on by itself fails at the call site with no hint
that a second option was meant to come with it.
Select it. Every in-tree configuration that sets NOGETREPORT already
resolves USBHOST_ASYNCH: ci20:jumbo and sama5d3-xplained:bluetooth
through USBHOST_HUB, and the two linum-stm32h753bi configurations by
setting it directly. No existing build changes.
The two that set it directly no longer can, since a selected symbol is
no longer settable, so savedefconfig drops the line. Their defconfigs
are normalized here to keep them canonical.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
After simplifications in NuttX init process, app core boots too fast so that
net core doesn't have time to initialize HCI service.
Let's add a short sleep before BLE initialization in app core as a temporary
fix, in the future it should be done better.
Signed-off-by: raiden00pl <raiden00@railab.me>
Adds two examples on esp32p4-tab5 that use LCD and touchscreen.
Both redirect the serial console to UART0 instead of USB.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Adds support for ST7123 touchscreen controller on esp32p4-tab5.
Includes new KConfig option and additions to hmi_power source.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Adds support for st7121 and st7123 variants for LCD support
on the esp32p4-tab5 board. Includes power management though IO
expander under 'hmi_power' and new board KConfig options.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Adds support for bringup of the two IO Expanders available on the
esp32p4-tab5 board. Those IO Expanders allow for control of many
peripherals such as radio, camera, display and touch.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
build will fail with the following error
arm-none-eabi-ld: /awork/android/NuttX/nuttx/nuttx section flash'
arm-none-eabi-ld: region .text' will not fit in region flash' overflowed by 1144 bytes
before
Register: qe
Register: nsh
Register: sh
LD: nuttx
arm-none-eabi-ld: /awork/android/NuttX/nuttx/nuttx section .text will not fit in region flash
arm-none-eabi-ld: region flash overflowed by 1144 bytes
Memory region Used Size Region Size %age Used
flash: 66680 B 64 KB 101.75%
sram: 5136 B 16 KB 31.35%
make[1]: *** [Makefile:230: nuttx] Error 1
make: *** [tools/Unix.mk:569: nuttx] Error 2
after
Register: qe
Register: nsh
Register: sh
LD: nuttx
Memory region Used Size Region Size %age Used
flash: 38008 B 64 KB 58.00%
sram: 4132 B 16 KB 25.22%
CP: nuttx.hex
CP: nuttx.bin
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Restore the esp32c3-devkit:dropbear defconfig and its documentation, now that
the AES symbol collision between the Wi-Fi stack and crypto/aes.c is fixed in
the ESP HAL. netutils/dropbear depends on CRYPTO_CRYPTODEV_SOFTWARE_CRYPTO,
so the defconfig enables the cryptodev software backend and base64 codecs.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The 32 MHz TCXO that clocks the SX1276 is powered from PA12 and was never
driven, so the radio had no clock at all. The user button was copied from
the Nucleo L073RZ and left on PC13, which carries DIO3 of the radio on this
board; it is PB2.
Adds lorawan_tx and lorawan_beacon, with the radio defaults of a public
LoRaWAN network in the 915 MHz band, and fills in the board page.
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Character driver for the Semtech SX1301, the baseband processor of a LoRaWAN
gateway, and the two SX125x radios it drives. Received packets come from
read(), downlinks go to write(), and the channel plan, the start and the stop
are ioctls.
The interface is device independent, in nuttx/wireless/lpwan/lora_gw.h with
the commands in the common WLIOC_GW_* space, so another concentrator driver
can implement it and the same application drive it.
Adds a lorawan_gw configuration for the Nucleo F746ZG with a shield of the
LRWAN_GS_HF1 family. Off by default (LPWAN_SX1301).
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The CMake build compiled no ROMFS source, so kernel-mode
configurations (knsh_romfs) failed to link with undefined references
to romfs_img. Generate the ROMFS image from the applications in
<build>/bin with genromfs/xxd and compile it into the board library;
other configurations keep the empty stub.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
ARM PIC has used r10 as the base register, but the tree has never been
consistent about it. Toolchain.defs gives CONFIG_BUILD_PIC
-mpic-register=r9 and CONFIG_PIC -mpic-register=r10, twenty-five lines
apart, and arm_initialstate.c sets REG_R9 from inline assembly under one
and REG_PIC under the other, with a comment reading "Set the PIC base
register (probably R10)". This settles it on r9 for all of PIC: NXFLAT,
ELF PIC and CONFIG_BUILD_PIC alike.
r9 is the right choice rather than an arbitrary one. It is the AAPCS
platform register, the "static base", and it is what GCC itself picks
for -msingle-pic-base on an EABI target; r10 is the non-EABI default.
It also removes a combination that cannot build today. Stack checking
adds -ffixed-r10 in armv7-m/Toolchain.defs and armv8-m/Toolchain.defs,
while CONFIG_PIC adds -mpic-register=r10, and GCC rejects the pair with
"unable to use 'r10' for PIC register". The comment above REG_PIC has
always said the register "can be R9 if stack checking is enabled", but
the definition was unconditionally REG_R10, so it would have named the
wrong register even had the build succeeded.
The thunk generator moves with the firmware. NXFLAT import stubs had
the register baked in as "add ip,ip,sl", so a module built for r9 would
load and then branch to a wild address on its first call out. The stubs
now come from NXFLAT_PIC_REG in the in-tree tool, which is built only
when CONFIG_NXFLAT is set, following the
CONFIG_BOARD_ETC_ROMFS_PASSWD_ENABLE precedent in tools/Unix.mk.
That leaves modules built before this change, and they are the reason
for the ABI marker. The NXFLAT header cannot carry a version: h_magic
is written by ldnxflat, which is GPL, derived from elf2flt, and stays
out of this repository, so it can never be changed in step with the
loader. The import table can, because both of its ends are in-tree --
mknxflat emits it and nxflat_bindimports() reads it -- and ldnxflat
passes it through untouched. So every module now imports
__nxflat_abi_v2, the base firmware defines it, and a module that does
not import it is refused.
Making the marker a real exported symbol rather than a name the loader
special-cases is what keeps it out of the build system's way: a board's
symbol table picks it up exactly as it picks up printf, so mksymtab.sh
and its equivalents need no change. It also gives the reverse direction
a diagnosis for free -- a module built against a newer ABI than its
firmware fails with "Exported symbol __nxflat_abi_v2 not found".
Most of the remaining churn is boards restating a default. ARCHPICFLAGS
is a "?=" default so that a board only speaks up when it differs, and
twenty-six were assigning the value the default already had. MKNXFLAT
gets the same treatment: thirteen boards named the same tool, and the
only thing that varies is ARM versus Thumb-2, which falls out of
CONFIG_ARM_THUMB. LDNXFLAT gains a default too -- it stays an
out-of-tree PATH lookup, but naming it centrally fixes boards that never
assigned it, where it expanded to nothing and handed make a recipe
beginning "-e", whose leading dash make ate as "ignore errors".
The non-ARM boards carrying -mpic-register=r10 lose it: it is an
ARM-only option, reachable only through CPICFLAGS, which is only used to
build NXFLAT modules, and no non-ARM board enables NXFLAT.
Boards keep nothing about PIC flags any more. ARCHPICFLAGS was set by
sixty-three of them and only ever fed CPICFLAGS, which is only used to
build NXFLAT modules; no board outside arch/arm enables NXFLAT, so every
non-ARM copy was setting a variable nothing read. Those are removed
rather than moved somewhere more central, which would only make dead
text look load-bearing. LDNXFLAT goes the same way as MKNXFLAT, for the
same reason: thirteen boards named the same tool that Toolchain.defs now
names once.
One of them was not merely redundant. am67/t3-gem-o1 asked for
"-mpic-register=r10 -ffixed-r10", which GCC refuses outright with
"unable to use 'r10' for PIC register" -- the very combination the
filter-out machinery in Toolchain.defs exists to prevent. It has
survived because that board does not build NXFLAT modules, so the flags
are never handed to a compiler. Renaming the register would have
carried the fault forward unchanged, so the line goes.
Tested on lm3s6965-ek:qemu-nxflat under QEMU, configured and built with
no overrides. The nxflat example runs the errno, hello and struct
modules with output identical to the same config built from master.
Built with the old out-of-tree thunk generator instead, the same
firmware refuses all three with ENOEXEC rather than locking up in a
HardFault, which is what this change is for. mps3-an547:picostest,
which is CONFIG_PIC without CONFIG_NXFLAT, builds clean and does not
build the thunk generator.
The .def files pick up two cosmetic changes here alongside the register:
a "Dyanamic" typo that codespell rejects, and a reworded comment in each
thunk_*.c. Neither appears in the emitted thunk -- both are in C
comments -- so the generated text is still what the upstream tool
produces, modulo the register itself.
BREAKING CHANGE: ARM PIC moves from r10 to r9. An NXFLAT module built
before this change has r10 baked into its import stubs and will not run
against a firmware carrying it; the two cannot be mixed. The module is
refused with ENOEXEC rather than branching to a wild address, by way of the
__nxflat_abi_v2 marker described below.
Quick fix: rebuild the module against this tree. Its source needs no
change. A board that reserved r10 by hand, or that assigned ARCHPICFLAGS
or MKNXFLAT to restate a default, should drop those assignments; nothing
else is affected, and CONFIG_PIC without CONFIG_NXFLAT needs no action.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Runs NXDoom on the board's LCD, played with a USB HID keyboard and
reading the game data from the microSD card, so it exercises the LTDC
framebuffer, the OTG FS host and the SDMMC peripheral at once.
Three settings are needed that are not obvious:
CONFIG_FAT_FORCE_INDIRECT, because the FAT layer otherwise reads whole
sectors straight into the caller's buffer and the SDMMC IDMA cannot
reach the caller's buffer when it lives in external SDRAM. The
failure appears part way through startup, once the internal RAM has
filled and allocations start coming from SDRAM.
CONFIG_HIDKBD_NOGETREPORT, because the keyboard answers GET_REPORT on
the control pipe with an empty report and only delivers key data on
its interrupt endpoint. Without it the keyboard enumerates, reports
no error, and no key is ever seen.
CONFIG_STM32_LTDC_L1_L8 with the frame buffer colour map, because DOOM
is natively palettised: letting the display convert the palette while
it scans out removes the conversion from the blit and halves the
amount of data written per frame.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The terminal no longer has separate matrix and USB input sources: it
reads any keyboard through one path.
Left as it was, the unknown symbol would have been dropped and the
configuration would have fallen back to the touch variant, which is the
default. This board has no touchscreen, so the terminal would have had
no input at all and the build would have said nothing.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The terminal reads a keyboard device and does not care which one, so it
can be driven with no keyboard plugged in at all. Enable UINPUT_KEYBOARD
and system/kbd so that the configuration can do it out of the box, and
document how, including how to have the USB keyboard and the console feed
the terminal at the same time.
The terminal no longer has a USB specific input source either, so the
device path has to be spelled out: the USB HID driver names its devices
/dev/kbda onwards while the option defaults to /dev/kbd0.
INPUT_KEYBOARD_BYTESTREAM is not needed here. The terminal reads events
now, and this configuration has no other keyboard consumer.
UINPUT_KEYBOARD_BUFNUMBER is raised to 128. It counts events rather than
keys, so the default of eight holds four keystrokes, and a console hands
over a whole line at once. The upper half overwrites the oldest event
when the buffer is full, so a typed line arrived with its beginning
silently missing.
HIDKBD_NOGETREPORT is enabled as well. Sampling the keyboard over the
control pipe every 40 ms loses any key pressed and released between two
samples, which on this board meant most of them.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
On K3 SoCs the A53 cluster does not own device power, clocks, resets or
interrupt routing; these are managed by the DM/TIFS firmware and requested
over TISCI through the secure-proxy mailbox. Add:
- a TISCI client (secure-proxy transport plus device/clock/reset helpers)
- a GPIO driver for banks 0/1 with pad mux and TISCI power-on
- an OMAP-I2C driver for the main-domain I2C controllers
and wire them into the PocketBeagle2 and BeaglePlay bring-up.
Tested on PocketBeagle2 (SYSFW 11.2.5) with the TechLab cape attached:
nsh> i2c bus
nsh> i2c dev -b 0 0x03 0x77 # I2C0 detects onboard 0x20 and 0x50
nsh> gpio -o 1 /dev/gpio3 # drives a user LED; read back with:
nsh> gpio /dev/gpio3
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
apache/nuttx#19586 removed HIDKBD_ENCODED and made USBHOST_HIDKBD select
INPUT, but four configurations still name one or both, so they do not
survive a refresh and the normalisation step fails:
boards/arm/sama5/sama5d4-ek/configs/ipv6
boards/arm/sama5/sama5d4-ek/configs/nsh
boards/arm/sama5/sama5d4-ek/configs/nxwm
boards/arm/stm32h7/linum-stm32h753bi/configs/lvglterm_kbda
Removing the lines is the whole fix. INPUT still ends up enabled through
the select, and encoding now comes from INPUT_KEYBOARD_BYTESTREAM, which
the one configuration that wanted it already sets.
Nothing changes in the resulting .config, which is why the build never
noticed: Kconfig drops an option that no longer exists without saying
anything, and only the refresh compares the file before and after.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The Fn cursor cluster was reported as ordinary key presses carrying 0x80
to 0x83, chosen to sit above the printable range so that an application
could tell them apart from characters. That is the collision this work
exists to remove: a key that produces no character is a special key, and
the event type is what says so.
Report them as KEYBOARD_SPECPRESS carrying KEYCODE_UP and friends, which
is what every other keyboard does and what the applications now expect.
The character tables are untouched, so the layout and the shift map behave
exactly as before. Only the four Fn cursor keys change.
Not tested on hardware: the board was not available. It builds, and the
change is confined to the two lines that pick the event type.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
These are the configurations whose application reads the USB HID keyboard
as a byte stream. Now that the driver reports through the keyboard upper
half, they need INPUT_KEYBOARD_BYTESTREAM to keep behaving as before.
INPUT drops out of the normalised defconfigs because USBHOST_HIDKBD now
selects it.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Wire the shared Ameba GPIO driver into the RTL8721F (amebagreen2) build and
add the EVB board glue:
- arch/arm/src/rtl8721f: build ameba_gpio.c (CMake/Make.defs), source the
common Ameba Kconfig, and add ameba_gpio_chip.h describing the chip's
three GPIO ports (A/B/C), their IRQs and the APBPeriph clock bit.
- arch/arm/src/common/ameba: teach the driver that amebagreen2's ROM
GPIO_Init does not call PAD_PullCtrl or GPIO_INTMode, so call both
explicitly after GPIO_Init; on RTL8721Dx (ram_common) these are harmless
redundant writes. Add the AMEBA_PORT_C / AMEBA_PC() helpers.
- boards/arm/rtl8721f/rtl8721f_evb: register output/input/interrupt demo
pins, add the bringup hook, and provide a minimal 'gpio' NSH defconfig.
- Documentation: add a GPIO section for the RTL8721F EVB and fix a
rising/falling typo in the PKE8721DAF page.
Hardware-verified on the RTL8721F EVB: output, input, and all interrupt
trigger/polarity combinations (rising/falling edge, level high/low).
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Remove CONFIG_FSUTILS_PASSWD from 31 sim configs that do not use NSH
login or other passwd features. These configs lacked a cryptodev
backend required by FSUTILS_PASSWD after the PBKDF2 Kconfig tightening,
causing olddefconfig normalization failures in CI.
Fixes#19573
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Bring up the last two RTL8721F feature blocks and wire them into the
nsh board configuration:
- littlefs on the on-chip flash MTD region (P2).
- WHC/INIC WiFi with the on-chip IPC control plane, NuttX net stack,
DHCP client and the wapi command tool (P3).
Two porting fixes were required for the WiFi control plane:
- ameba_ipc.c: the AP IPC device base (IPCAP_DEV) was carried over
verbatim from the RTL8720F template (0x40804000). On this SoC IPC0
lives at 0x40815000; using the wrong base makes ipc_table_init()
program the RX-full mask in the wrong register block, so the NP->AP
interrupt never fires and WiFi bring-up hangs waiting for the device
to answer. Point IPCAP_DEV at the correct 0x40815000 base.
- ameba_board.mk: the EVB silicon is B-cut, so link against the
ameba_rom_symbol_bcut*.ld ROM symbol tables (the A-cut tables resolve
the WiFi ROM helpers to the wrong addresses and fault at run time).
Validated on hardware: NSH comes up, wapi scan lists real APs, a WPA2
connect succeeds, the DHCP client obtains a lease and ICMP to the
public internet round-trips.
The board defconfig keeps SSID/passphrase as placeholders; real
credentials are supplied at run time via the wapi commands.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Wire the RTL8721F km4tz core up to a working NuttShell:
- irq.h: renumber the KM4TZ external vector table to the RTL8721F
APIRQn map (UART_LOG=24, IPC=5, +GPIOB/C, TIMER7/8, ...).
- ameba_loguart.c: fix the LOG-UART base to 0x40810000. The former
0x401C6000 belongs to a different Ameba part; the wrong base bus-
faulted on the RX interrupt-enable write while TX still worked
(LOGUART_PutChar uses its own ROM-internal base).
- ameba_app_start.c: adjust the MPU read-only / RAM regions for the
RTL8721F memory map and seed the RTC on first power-on so the
SDM32K-clocked SYSTIMER comes up (mirrors the SDK app_rtc_init).
- ameba_ipc.c: move the km4tz<->km4ns IPC to APIRQn 5 (IPC_CPU0).
- ameba_board.mk: pull in fwlib ameba_rtc.c for the RTC_* symbols.
- defconfig: RTL8721F RAM map, enable TIMER/TIMER_ARCH/ARMV8M_SYSTICK
for a live system tick, and drop the WiFi/NET stack for now.
- scripts/Make.defs: use the RTL8721F_NOR flash profile.
Boots cleanly to nsh> on hardware; tick, RX and builtin apps verified.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Add a P0 skeleton port for the Realtek RTL8721F (SDK codename Green2 /
amebagreen2). Structurally the RTL8721F is a twin of the RTL8720F -- the
AP/host core is km4tz (ARMv8-M.main, TrustZone secure) and the WiFi MAC/PHY
runs on the km4ns network-processor core -- so this port is modelled on the
RTL8720F one and shares the IC-agnostic ameba glue in
arch/arm/src/common/ameba.
This is the "configures and links" skeleton (rtl8721f_evb:nsh builds an
image end to end). Four differences from the RTL8720F template were needed
to make the empty shell link against amebagreen2:
* km4tz has no FPU (cmsis_cpu.h defines __FPU_PRESENT 0), so the chip does
not select ARCH_HAVE_FPU and the image is built soft-float.
* ameba_app_start.c matches amebagreen2's ram_km4tz silicon init: the
nocache MPU map, the non-secure ROM BSS clear, OSC4M (not OSC2M)
calibration gated on EFUSE cut >= B and CHIP_TYPE_ASIC_POSTSIM.
* amebagreen2 ships no lib_rom.a, so the ROM archive whole-archive link is
dropped; the WiFi/OS/non-secure ROM symbols come from the SDK
ameba_rom_symbol_acut{,_wifi,_os}.ld maps appended to the image2 linker
script, exactly as green2's own image2 link does.
* the AP WiFi security lib is lib_wifi_common.a (was lib_wifi_com_sec.a).
The per-chip IRQ vector table (irq.h) and the RAM_START/RAM_SIZE layout
still carry RTL8720F values and are refined in the follow-up bring-up work.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
BOARD_ETC_ROMFS_PASSWD_ENABLE now depends on FSUTILS_PASSWD and a
cryptodev backend so PBKDF2 passwd autogen cannot be enabled without
the runtime login stack. Fixes#19573.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Enable BOARD_ETC_ROMFS_PASSWD_ENABLE and software cryptodev options on
all sim configs with CONFIG_NSH_CONSOLE_LOGIN so PBKDF2 login works on
NuttX 13.0+. Fixes#19573.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
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>
A configuration for the Pimoroni Pico Plus 2 that mounts xipfs on the flash
MTD and builds everything that exercises it: the test suite with fault
injection, the xipfs command, and the NXFLAT execute-in-place demo.
Building an NXFLAT module needs mknxflat and ldnxflat, so name them in the
rp23xx board Make.defs files, which already carry the rest of the NXFLAT
flags but not these.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Give the QEMU boards the same directly addressable media the sim
configuration has: rammtd answers BIOC_XIPBASE with the base of its buffer,
so xipfs layered on it hands out real pointers and the in-place mmap path
can be exercised on an ARM target with no flash present. Registered as
/dev/rammtd and mounted at /mnt/xipfs when xipfs is configured.
Both mps2-an500 (Cortex-M7, armv7e-m) and mps2-an521 (Cortex-M33, armv8-m)
get it, which is what makes the filesystem testable on two different core
generations without either one needing flash.
Each board also gets a xipfs configuration that runs the test suite, so the
bringup above is exercised rather than only compiled. Both run the suite to
completion under QEMU 10.1, 90 checks apiece, the power loss sweeps included.
The an521 configuration carries CONFIG_CMSDK_UART0_RX_IRQ=48 and _TX_IRQ=49
rather than the reversed pair the an521 nsh configuration uses. That is the
SSE-200 order, receive first, and the one consistent both with the overflow
interrupt at 63 that nsh already has and with mps2-an500, which puts RX at 16
and TX at 17. With the pair reversed the TX interrupt reaches
uart_cmsdk_rx_interrupt, which acknowledges only UART_INTSTATUS_RX, so the
board live-locks on its first console write. Correcting nsh is left to a
separate change.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
rammtd answers BIOC_XIPBASE with the base of its RAM buffer, so it is a
usable stand-in for memory mapped NOR: extents are directly addressable and
the in-place mmap path can be exercised end to end without any flash. Mount
xipfs on it when it is the configured file system, and add a configuration
that runs the xipfs test suite, fault injection included.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The flash MTD device answers BIOC_XIPBASE, which is what xipfs needs to
serve mappings straight out of the memory mapped QSPI flash. Mount it at
/mnt/xipfs when both are configured, formatting on first boot, so a board
comes up with somewhere to download and run a module from.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
During the Toybox port to NuttX, Claude noticed that changes in the
menuconfig weren't taking affect. This issue exists for a long time on
NuttX, in fact BayLibre's presentation from 2017 make jokes about our
building system not been reliable:
https://www.youtube.com/watch?v=XUJK2htXxKw&t=320s
Stale archive members from $(AR)'s additive-only behavior can linger
after Kconfig toggles change which files provide a symbol, causing dead
weight or "multiple definition" link errors on incremental builds.
Fixed by splitting ARCHIVE into two macros: ARCHIVE keeps the original
additive behavior for apps/libapps.a, which many independent
subdirectories contribute to across a build, while the new
ARCHIVE_REBUILD deletes then archives for the far more common case
of a single Makefile building its own self-contained $(OBJS)
- all 39 such call sites now use it.
Assisted-By: Claude Sonnet 5
Signed-off-by: Alan C. Assis <acassis@gmail.com>
The rp23xx common board sources reference rp23xx_st7735.c from both
Make.defs and CMakeLists.txt under CONFIG_LCD_ST7735, but the file was
never added. Enabling CONFIG_LCD_ST7735 on any rp23xx board therefore
fails the build on the missing source.
Add the file, modelled on the existing RP2040 sibling
boards/arm/rp2040/common/src/rp2040_st7735.c and retargeted to
rp23xx/SPI1. It implements board_lcd_initialize(), board_lcd_getdev()
and board_lcd_uninitialize(): bring up SPI1, claim the D/C (shared with
the unused SPI1 RX pad, per the rp23xx common convention), RST and BL
pads as GPIO, pulse the panel reset and bind the ST7735 driver.
Validated on silicon on a Waveshare RP2350-LCD-0.96 (RP2350A + ST7735S
160x80 IPS): the panel powers up and displays correctly, painted at boot
with no console interaction. Build-tested raspberrypi-pico-2:nsh with
CONFIG_LCD_ST7735=y (compiles and links).
Assisted-by: Claude (Anthropic Claude Code)
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Update the NXDoom configuration to make use of the new PWM audio
support. Now RTTL music is played over the audio jack.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Add a shared Ameba high-speed UART driver on top of the GPIO driver's
common/ameba/ infrastructure, exposing UART0/UART1 through the NuttX
serial upper half.
- arch/arm/src/common/ameba/ameba_uart.c/.h: serial lower-half driver
built on the SDK fwlib UART register layer (ROM symbol table). RX/TX
dispatch through NuttX-native interrupts; TERMIOS get/set supported.
The pins are muxed to the direction-specific UART crossbar function
codes (TXD/RXD per controller) required by the amebadplus pinmux, and
RX is pulled high through the SDK ROM.
- arch/arm/src/common/ameba/Kconfig: AMEBA_UART option (selects SERIAL
and ARCH_HAVE_SERIAL_TERMIOS) plus RX/TX buffer-size knobs.
- arch/arm/src/rtl8721dx: wire ameba_uart.c into the Make/CMake builds
and pull the fwlib ram_common UART table into the fwlib link set.
- boards/arm/rtl8721dx/pke8721daf: board UART port table registering
UART0 at /dev/ttyS1 (PB18/PB19, 115200), bring-up hook, and a uart
NSH config with the serialrx/serialblaster examples.
- Documentation: describe the driver and the uart board config.
Verified on hardware (PKE8721DAF): pinmux routing, TX/RX and interrupt
paths, and the TERMIOS ioctl path via loopback.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
