A single failed burst read of FIFO_DATA_OUT was enough to take the board
down.
The drain path gave up on error, unlocked and returned, leaving the FIFO
above its watermark. INT1 is level triggered on exactly that condition,
so the line stayed asserted, the worker was re-entered the instant the
IRQ was re-enabled, failed again, and that hot loop starved every other
task until the board wedged -- console cut off mid-line, no crash dump.
Observed killing a board within seconds of the first failure.
Fix: if the read fails, empty the FIFO through Bypass and restore the
previous mode bits, which deasserts INT1. That costs one batch of
samples and acquisition resumes on the next watermark. Restoring the
saved bits rather than recomputing them preserves the FIFO-only ODR set
by fifo_configure().
Losing a batch is a far better outcome than losing the board.
The underlying cause of these timeouts on esp32s3 was light sleep cutting
the transfer in half; that is fixed separately in esp32s3_i2c.c. This
commit is the driver recovering gracefully from a failed read whatever
its cause, which it was not before.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The worker declared its drain buffer as int16_t raw[FIFO_MAX_WORDS], and
FIFO_MAX_WORDS scales with CONFIG_SENSORS_LSM6DS3TRC_FIFO_WATERMARK.
At the Kconfig default watermark of 8 that is 192 bytes and nobody ever
noticed. At the watermark this collar uses, 250, it is 6000 bytes inside
an 8192-byte HPWORK stack -- 73% of it, before the call frame and the
whole I2C stack underneath. Any board raising the watermark walks into a
stack overflow in a shared work queue, which is about the worst place to
find one.
Allocated once at registration so the drain path stays allocation-free,
and the driver fails registration cleanly if it cannot get the memory.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
lsm6ds3trc_register() attached the INT1 handler without ever putting the
sensor into a known state, which made every reboot a coin toss.
The LSM6DS3TR-C has its own supply and its own reset. An MCU reset --
watchdog, RTS pin, esptool, a plain "reboot" -- does not reset it, so it
comes back still holding whatever the previous session configured: for
this driver, INT1_CTRL.INT1_FTH still set and a FIFO still over its
watermark, i.e. INT1 already asserted at registration time.
With the (correct) ONHIGH level trigger, arming an already-active line
storms immediately. The board then wedges during bring-up with no
console output and no crash dump -- it looked like a boot that stopped
right after Wi-Fi init and never reached NSH. That symptom cost a long
detour: it was blamed in turn on a stuck I2C bus, on corrupted NVS/Wi-Fi
calibration, and finally on a failing USB-serial adapter, because the one
thing that reliably cleared it was unplugging the board -- which is
simply the only way to power-cycle the *sensor*.
SW_RESET (CTRL3_C bit 0) clears INT1_CTRL and FIFO_CTRL back to 0, which
deasserts INT1. It self-clears in ~50 us; poll for it rather than
assume, and retry the write a few times, since the bus has been seen to
return -EIO on the very first transaction after a cold boot.
Carry on if the reset never takes. An unreset sensor risks the storm
this exists to prevent, but refusing to register leaves the application
with no /dev/uorb/sensor_accel0 at all, which is fatal to it -- a single
-EIO here took the whole collar down once. Losing the sensor to guard
against a maybe-storm is the wrong trade.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
esp_gpio_irq() registers per-pin GPIO interrupts through
gpio_isr_handler_add(), never through esp_setup_irq(), so
esp_get_handle() never finds them and up_disable_irq()/up_enable_irq()
silently no-op for any GPIO-derived irq number. Fall back to
esp_gpioirqdisable()/esp_gpioirqenable() (translating irq back to a
pin via ESP_IRQ2PIN()) when the normal interrupt-matrix lookup misses.
This surfaced through drivers/sensors/lsm6ds3trc_uorb.c: its ISR
schedules a worker to drain the sensor's FIFO over I2C and disables
its own IRQ until the worker re-enables it, so a level-triggered
source (e.g. a PM GPIO wake source left in level mode) doesn't
refire continuously and starve every task, HPWORK included, before
the worker ever gets to run. That disable/enable only works now that
up_disable_irq()/up_enable_irq() actually do something for GPIO irqs.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Add 8 missing AF4 I2C2/I2C4 pin remap defines to
stm32h56xxx_pinmap.h, per ST's datasheet. Needed by boards that wire
I2C2/I2C4 to these pins; without them such configs fail to compile.
Reduced from a larger internal patch; the stm32_i2c.c part of that
patch is already upstream, so only this pinmap gap remained.
Co-authored-by: David Vidrie Leon <davidvidrie@geotab.com>
Signed-off-by: Marwan Madkour <marwanmadkour@geotab.com>
Light sleep gates the APB clock the I2C peripheral runs on. A transfer
in flight stops mid-message and never raises its completion interrupt, so
the caller blocks in i2c_sem_waitdone() until ESP32S3_I2CTIMEOTICKS
expires and gets -ETIMEDOUT for a bus that was working perfectly.
The caller is what causes it. Blocking in i2c_sem_waitdone() is exactly
what makes the idle task runnable, and the idle task is what decides to
sleep -- so the longer the transfer, the likelier it is to be cut in half
by its own wait. Nothing about this is driver-specific.
Seen on an esp32s3-xiao reading an LSM6DS3TR-C FIFO: 6000 bytes in one
transaction, some 135 ms of bus time at 400 kHz, failing with -110 over
and over. A WHO_AM_I probe and the FIFO status read, both short, never
failed once in the same runs -- only the long burst did.
The consequences went well past one failed read. With the FIFO left
undrained the sensor's level-triggered INT1 stayed asserted, the worker
was re-entered the moment the IRQ was re-enabled, and that hot loop
starved every other task until the board wedged with no console output
and no crash dump.
pm_stay(PM_IDLE_DOMAIN, PM_IDLE) is the lightest lock that suffices:
greedy_governor_checkstate() walks up from PM_NORMAL and stops at the
first state holding a wakelock, so a stay at PM_IDLE keeps the domain out
of PM_STANDBY and PM_SLEEP while still allowing the plain WFI idle.
There is no early return between the stay and the relax.
Validated over 3 h 45 of continuous acquisition across two sessions:
wakes and drains stayed 1:1 (302/302, then 375/375), zero I2C failures of
any kind, and light sleep itself unaffected -- 11.8% of wall time asleep
in both, median sleep 2.08 s.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-opus-5
libelf_uninit() only called libelf_freesymtab() when the module had an
uninitializer. But the exported symbol table is built by
libelf_insertsymtab() for every loaded module, and nothing in the tree
sets modinfo.uninitializer anymore: modules have registered their
teardown through .fini_array since a9cb28cd23. The condition is
therefore always false and every rmmod()/dlclose() leaks the exports
array together with the strdup-ed symbol names.
Call libelf_freesymtab() unconditionally, and clear the exports
pointers next to it instead of under a vestigial procfs guard that
dates back to the removed module initializer field.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
libelf_remove() takes the module out of the registry but never frees
the registry entry, so every successful rmmod()/dlclose() leaks
sizeof(struct module_s), the name included. The lib_free() call was
dropped by e9550783d3 when the removal path was reworked.
Free the entry after the registry lock is released.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
/proc/pm/state0 reported a flat 0 s in its SLEEP column on a board that
was demonstrably light-sleeping, because this port never told the PM core
it had slept.
pm_stats() (drivers/power/pm/pm_changestate.c) splits the time since the
last transition into dom->wake[state] or dom->sleep[state] depending on
whether the state it is handed is PM_RESTORE. up_idlepm() called
esp_pmstandby() and carried straight on, so every second -- including the
ones spent in light sleep -- was billed to wake[]. The statistics
CONFIG_PM_PROCFS advertises were simply never true here.
Read from an esp32s3-xiao that had just spent 89 s in PM_STANDBY:
DOMAIN0 WAKE SLEEP TOTAL
standby 89s 83% 0s 0% 89s 83%
Only PM_STANDBY needs this. PM_SLEEP is deep sleep and does not return
at all -- the chip resets -- so there is nothing to attribute on its way
back.
pm_changestate(domain, PM_RESTORE) is the documented way to say this: it
skips the driver prepare/veto phase, records the statistic, notifies
drivers of the restore, and deliberately does not overwrite the domain's
state, so the domain stays in PM_STANDBY as it should.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-opus-5
up_idlepm() put the domain back in PM_NORMAL with pm_changestate() but
left its local oldstate holding whatever it was before sleeping, usually
PM_STANDBY. The pm_checkstate() below then returned PM_STANDBY again,
the "newstate != oldstate" test compared PM_STANDBY against a stale
PM_STANDBY, and the whole block was skipped -- including the
esp_pmstandby() call that is the only thing in here that ever sleeps.
So after the very first wakeup the board reported PM_NORMAL essentially
forever, and light-slept only when something else happened to perturb
oldstate, such as an application taking and releasing a PM_IDLE wakelock
around a transmission window.
Measured on the esp32s3-xiao collar before this fix: 4.1 s of actual
light sleep in 2 h of near-total idleness, a 1780:1 awake-to-asleep
ratio. After it: ~13.5% of wall time asleep, thousands of sleeps, no
storms.
The dead "newstate = PM_NORMAL" assignment that used to sit here was
presumably meant to be this; it is overwritten by pm_checkstate() a few
lines below and never had any effect.
Note that fixing this is what exposed two further bugs that had been
dormant behind a board that never slept: the systimer double-count in
esp_pmstandby(), and I2C transfers being cut in half by sleep. Both are
fixed in their own commits.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-opus-5
Increase MOD_LINELEN from 64 to 256 so complete /proc/modules lines fit the formatting buffer on 64-bit targets.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
Add the required blank line between the intcount declaration and the
following statement.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
irq_callback() passed snprintf()'s would-have-written length to
procfs_memcpy(). If an IRQ line exceeded IRQ_LINELEN, the copy could read
beyond the formatting buffer.
Use procfs_snprintf() so the copy is limited to the bytes actually written.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
modprocfs_callback() formatted each line into line[64] with snprintf()
and passed snprintf()'s return value, the length the line would have
had, to procfs_memcpy() as the source length. A module name longer
than a few characters therefore made the copy read past the end of
the line buffer and hand kernel heap memory to the reader, and grew
totalsize by the difference.
Use procfs_snprintf(), which returns the length actually written, as
the other procfs entries already do.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
Follow-up to apache/nuttx#20194. The KissFFT page only described how
NuttX vendors the package. State that it is a small open-source FFT
implementation used in many embedded projects.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Support STM32_ETH_TIMESTAMP_TX on the STM32H7, as the legacy STM32 do,
with the timestamp returned through SO_TIMESTAMPING.
When a packet socket asks for the transmit timestamp of a frame, keep a
copy of the frame and ask the MAC to timestamp it in the descriptor. When
the transmission is done, take the timestamp from the descriptor and give
the copy back to the network stack with it, that delivers it to the error
queue of the socket. The MAC writes the timestamp over the address of the
buffer in the descriptor, so the driver keeps the buffer of these
descriptors. The copies that still wait for their timestamp are released
when the interface goes down.
With a PTP daemon using the peer-to-peer delay mechanism against a
grandmaster clock, the path delay measured was between 9.0 and 9.1 us.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Record the vhost-net link in the board's Peripheral Support list and
describe the netnsh configuration alongside nsh, including how to bring
the interface up on both sides.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
nsh plus networking over the rptun/virtio-net link to the A53: enables
DRIVERS_VHOST_NET with the buffer sizing the link needs (IOB pool and chains,
NET_LL_GUARDSIZE covering the ethernet and virtio-net headers) and ICMP
sockets for ping. Also gives CI an in-tree configuration that compiles the
vhost-net driver.
Verified on t3-gem-o1: ifup, then ping from the peer with 0% loss.
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Implements the device end of virtio-net, so a peer running the stock
virtio-net driver sees this side as a network card, and registers a netdev
lowerhalf.
Ring layout follows the peer's numbering: vq[0] is its RX queue, which we fill
to transmit, and vq[1] its TX queue, which we harvest. No features are
negotiated, so every frame carries the zeroed legacy virtio_net_hdr.
Peer buffers are reached by raw 64-bit address through an arch-provided
translation window -- the AM67 RAT, identity mapping elsewhere -- splitting
copies that straddle it.
Also gives DRIVERS_VHOST a prompt; it was promptless and so unselectable
without a driver forcing it.
Verified on t3-gem-o1 against an unmodified Linux virtio_net: eth0 registers,
ifup brings it to RUNNING, and the peer pings it 5/5 at 0.27 ms and 60/60 with
0% loss.
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
vhost_get_vq_buffers() converts descriptor addresses through the shared-memory
I/O region, which truncates silently when the CPU cannot address all of the
peer's memory -- a 32-bit remote core against a 64-bit host, where
metal_phys_addr_t is 32-bit and Linux posts buffers above 4 GB.
Returns the raw 64-bit address and length instead, so class drivers can
translate through platform window hardware. Completion is unchanged.
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Adopt the zbus message bus on the linum-stm32h753bi (first adopter
board):
- scripts/flash.ld: include the iterable sections common fragments
(2 lines: common-rom.ld inside .text, common-ram.ld inside .data).
- configs/zbus/defconfig: board configuration enabling zbus with all
observer types, the zbus example and its cmocka test suite
(./tools/configure.sh linum-stm32h753bi:zbus).
- Board documentation: describe the new configuration.
Validated on hardware: the 16-test cmocka suite passes twice in the
same boot and the zbus example produces the expected output.
Assisted-by: Claude Code
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
NuttX-side support for the zbus message bus port (apps/system/zbus in
nuttx-apps), built on the link-time iterable sections infrastructure
added in a companion PR:
- include/nuttx/linker/common-rom.ld and common-insert.ld: register the
zbus channel, observer and channel observation iterable sections
(ITERABLE_SECTION blocks guarded by CONFIG_ZBUS, no-op otherwise) for
the include and the zero-touch INSERT modes respectively;
common-ram.ld: note that zbus needs no RAM sections.
- Documentation/applications/system/zbus: Sphinx documentation for the
zbus application, with the upstream Zephyr diagrams (Apache-2.0).
- .codespellrc: skip the reused zbus SVG diagrams (embedded base64
raster data trips the spell checker).
Assisted-by: Claude Code
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
NuttX emits no AES instruction on any arm64 core. There is no runtime
feature dispatch in arch/arm64, so every AES goes through crypto/rijndael.c
or crypto/aes.c, and the table-driven one indexes memory with key-dependent
values, so its timing follows the cache.
Provide aes_cypher() for ECB, CBC and CTR built on AESE, AESD and the
MixColumns pair, and register it with /dev/crypto as a hardware driver
alongside the existing stm32h7, sam34 and esp32 modules.
ID_AA64ISAR0_EL1.AES is read on every call, which returns -ENOTSUP rather
than trapping on a core without the extension.
Verified against the NIST SP 800-38A appendix F vectors for ECB-128,
ECB-256, CBC-128, CBC-192 and CTR-128, encrypt and decrypt, in place and
out of place.
Signed-off-by: Royyan Zahir <royzah@gmail.com>
platform_autoconf.h is a hand-maintained minimal header that provides the
SDK #defines required by the fwlib sources compiled during PREBUILD. Unlike
the other Ameba ICs (which use ameba_gen_autoconf.sh to regenerate it from
SDK menuconfig), RTL8730E uses a static file because the amebasmart SDK
does not ship a pre-generated autoconf and running menuconfig in CI is not
feasible.
The file was previously gitignored along with all other prebuilt/ artifacts,
so CI had no platform_autoconf.h on a clean clone, causing:
fatal error: platform_autoconf.h: No such file or directory
Fix: add !platform_autoconf.h exception to prebuilt/.gitignore and track
the file in git. Local clean build verified (nuttx.bin 550 KB generated).
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Two CI issues in the RTL8730E (AmebaSmart CA32) port:
1. PREBUILD used $(ARCHOPTIMIZATION) which injects --param=min-pagesize=0
on GCC>=12. arm-none-eabi-gcc in CI does not recognise this flag.
Fix: replace $(ARCHOPTIMIZATION) with explicit -Os -ffunction-sections
-fdata-sections in both the fwlib and wifi PREBUILD loops, matching the
pattern already used by the other Ameba ICs (rtl8721dx/8720f/8721f).
2. boards/arm/rtl8730e/rtl8730e_evb/configs/nsh/defconfig was out of sync
with `make savedefconfig` output (missing CONFIG_ARCH_CHIP_RTL8730E_CA32,
wrong ordering of several NETUTILS options, and redundant entries that
are auto-selected by Kconfig). Regenerated with olddefconfig+savedefconfig.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Add the rtl8730e_evb (RTL8730E Evaluation Board) with an nsh configuration
that demonstrates the RTL8730E baseline feature set:
- Dual-core SMP (CONFIG_SMP=y, CONFIG_SMP_NCPUS=2)
- Wi-Fi station and SoftAP via wapi
- DHCP client (wlan0) and DHCP server (wlan1/AP mode)
- littlefs persistent storage at /data on SPI NOR flash
- iperf2 TCP/UDP throughput measurement
- NSH console over the LOG-UART
Board formerly named ca32-evb; renamed to follow the rtlXXXX_evb
convention used by all other Ameba boards.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Replace the CMake skeleton with full SDK build machinery, mirroring
the make-side ameba_board.mk. RTL8730E differs from the KM4-based
ICs in three ways that prevent a direct include(ameba_board.cmake):
- No SDK autoconf / image2 ldscript generation: the board uses its own
dramboot.ld and a static prebuilt platform_autoconf.h
- No NP firmware build: KM0/KM4 are prebuilt blobs in prebuilt/
- No -mcmse: CA32 is ARMv7-A, not Cortex-M33; uses -DCONFIG_ARM_CORE_CA32
The ameba_build_lib() helper (adapted from ameba_board.cmake) compiles
SDK sources with an isolated flag set into libameba_fwlib.a and
libameba_wifi.a, avoiding NuttX header conflicts.
Key additions:
- libameba_fwlib.a: arch.c + log.c + sscanf_minimal.c always; IPC for
WiFi/FlashFS; ameba_flash_ram.c for FlashFS
- lib_rom.a linked for GPIO or FlashFS (GPIO_Init, Pinmux_Config, etc.)
- libameba_wifi.a + prebuilt WHC host libs for WiFi
- VFS1 geometry extracted from platform_autoconf.h via
target_compile_definitions (set_property(SOURCE) has scope issues in
NuttX's include()-based CMake structure)
- `flash` target calls ameba_smart_flash.sh
Verified: gpio (1186 targets) and nsh (1530 targets) configs both
build cleanly; /data mounts at correct 2 MB partition size.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com>
RTL8730E has dual Cortex-A32 cores (CA32) in the AP domain. Core1 is
powered off by default and requires an explicit HSYS power-on sequence
before ATF SP_MIN can service the PSCI CPU_ON call. Without it, SP_MIN
writes the entry point to the mailbox and times out waiting for Core1 to
poll it.
Add rtl8730e_core1_power_on() that mirrors SDK smp.c:rtk_core1_power_on():
assert reset, assert isolation, two-stage power-on with up_udelay() for
correct 50/50/500/50 us timing, then release isolation and reset. Call it
from up_cpu_start() before psci_cpu_on().
Enable CONFIG_SMP / CONFIG_SMP_NCPUS=2 / CONFIG_ARM_PSCI in the nsh
defconfig.
Enabling SMP also exposed a latent WHC skb alignment bug: the Realtek
WHC WiFi driver keeps the AP/NP DDR views coherent with by-VA
DCache_Clean/Invalidate at SKB_CACHE_SZ (64 on RTL8730E) granularity,
which requires every skb buffer to be cache-line aligned. The port had
omitted CONFIG_MM_DEFAULT_ALIGNMENT (defaulting to 8; the 8721Dx parts
set 32), so heap-allocated skb buffers were unaligned and the cache
maintenance spilled onto the neighbouring skb struct, corrupting its
immutable buf pointer (seen as skb->buf = 0x05 and a TX memcpy data
abort on "renew wlan0"). This was harmless on single core -- the
non-shareable DDR mapping made the stray maintenance a no-op -- but the
SMP shareable mapping plus real dual-core concurrency turned it into a
hard fault. Set CONFIG_MM_DEFAULT_ALIGNMENT=64 in the nsh defconfig.
Hardware verified on RTL8730E (C-cut): /proc/cpuinfo shows both processor 0
and processor 1; getprime 2 completes two concurrent threads in ~573 ms
(same as single-thread), confirming true parallel execution across both cores.
"renew wlan0" now obtains a DHCP lease (192.168.1.101) without faulting.
Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
On AmebaSmart the standard WHC_API_WIFI_GET_MAC_ADDR pull API times out:
the KM4 NP firmware snapshot linked into this image does not register a
handler for it, so wifi_get_mac_address() blocks ~12s per call and cannot
be used to fill the netdev MAC.
The NP does, however, PUSH its real efuse MAC to the host at wifi-on time
via WHC_API_SET_NETIF_INFO, which lands in the host-side
lwip_wlan_set_netif_info() glue. Previously that glue discarded the
address and ameba_wifi_get_mac() synthesised a random locally-administered
MAC, which then diverged from the MAC the NP actually associates with (the
NP's 802.11 RX filter drops unicast frames addressed to the random MAC, so
DHCP OFFERs never arrive).
Cache the pushed efuse MAC in lwip_wlan_set_netif_info() and return it from
ameba_wifi_get_mac(); the random MAC remains only as a fallback for the
window before the NP has pushed. ameba_wifi_connect() then mirrors it to
the NP with wifi_set_mac_address() so both sides agree. The per-IC guard
uses CONFIG_AMEBASMART, not CONFIG_ARCH_CHIP_RTL8730E: these files are
compiled by the board PREBUILD step with the vendor SDK autoconf, where
NuttX Kconfig symbols are invisible. The other Ameba parts keep their
working GET_MAC efuse path unchanged.
Verified end to end: ifconfig shows the real Realtek OUI MAC
(00:e0:4c:..), association and DHCP complete in a single round.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Add NuttX support for the Realtek AmebaSmart (RTL8730E) running on the
CA32 (Cortex-A32) application core, with the KM4/KM0 cores kept as
vendor firmware (KM4 acts as the WiFi network processor over WHC IPC).
Stage 1 bring-up, hardware verified:
- CA32 boot / exception vectors / MMU + page allocator / heap
- LOGUART console (RX via KM0-owned IPC + shared memory)
- IRQ controller, timer, serial
- On-chip SPI NOR flash MTD -> littlefs mounted at /data
- WHC-host WiFi netdev (STA): scan / connect / DHCP, verified end to
end (association -> 4-way -> DHCP -> ping, bidirectional TCP)
IC-agnostic Ameba glue is shared from arch/arm/src/common/ameba via a
relative VPATH entry (matching the rtl8721dx pattern), which also avoids
the empty mkdeps --dep-path that a leading-":" VPATH entry produced and
which intermittently broke parallel .ddc dependency generation.
The FIP packaging / flash image assembly is driven by
common/ameba/tools/ameba_smart_flash.sh from the board scripts.
Vendor blobs and build artefacts under the board prebuilt/ directory are
kept out of the tree via prebuilt/.gitignore.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Makes /proc/reset available, so which peripherals are held can be read
while the board is running rather than only for the eight lines the
startup report names.
RESET_PROCFS depends on FS_PROCFS_REGISTER, which neither board set.
Without it the symbol is dropped when the configuration is regenerated
and the entry never appears, which is silent: the defconfig still reads
as though the feature were on.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Implements get_line, so /proc/reset names all 324 lines and gives the
register and bit each lives in. The framework asks status() for the
asserted state.
The names do not survive compilation: they live in the enumeration, so
without a table a listing gives only numbers, and working back from one
to a peripheral means counting through the header. The table costs
about 8 KiB and is built only when the procfs entry is.
The ids are sparse, 324 lines across a space of 1952, so the table is
sorted by id and searched rather than indexed, and an id naming no line
returns -ENODEV. The framework skips those, which is what leaves the
listing dense.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A peripheral held in reset reads like one that is absent, and the boot
loader does not leave the same lines released on every board or every
boot. One line at startup says how much is held:
reset: 324 lines, 117 held
Beside the clock tree's line and for the same reason: the summary is
worth seeing on every boot, and the detail belongs in /proc where it can
be read when it is wanted.
The driver's error output is enabled, matching the clock driver. Info
level is not, since nothing at that level prints on a healthy boot.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The Clock and Reset Generator holds the reset line for every block on
the SoC. This registers all 324 of them with the NuttX reset framework
as a provider implementing assert, deassert, reset and status.
A line is addressed as its control register index times thirty two plus
its bit, across 61 registers, so the ids are sparse in a space of 1952
and decoding one is arithmetic rather than a lookup.
Each register carries three masks over the same bits: which bits are
lines at all, which the hardware will not let software drive, and which
would take down the system that asserted them. The last are still
registered and can be read and released; only assert and reset refuse
them. Where each line falls, and why, is recorded beside the table.
The lines are active low, which the manual never states. It is inferred
from the field naming, the reset defaults and both vendor Linux drivers.
If that inference is wrong then deassert asserts, so the evidence for it
is written out in full rather than left as a convention.
Several lines are absent from the manual, the GPIO resets at offset
0x438 among them. They were recovered from the vendor device tree and
confirmed by asserting each one and watching the block stop responding.
Registration writes nothing to the hardware.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The mailbox handler drained the FIFO without checking the message body.
That caused shutdown messages to be lost, hence being unable to start/stop
the R5 cores from the Linux side.
The additions allow checking messages for control and virtqueue types.
Shutdown messages fall to the control branch, which ACKs the shutdown
request and parks the core in WFI.
Virtqueues still work as intended; the only difference is that control
messages are now handled correctly.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Record the rptun/rpmsg link to the Linux A53 in the board's Peripheral
Support list.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
J722S maps DDR above the first 2 GB at 0x8_8000_0000, out of reach of the
32-bit R5F, while a 64-bit Linux peer posts virtio buffers there.
Dedicates RAT region 0 as a 16 MB window at 0xFE000000. am67_rat_map() re-aims
it and returns a pointer plus the bytes left before the edge, so callers can
split copies that straddle it.
The window is Non-cacheable, since it retargets at runtime and cached lines
would alias across physical blocks. A mapping is valid only until the next
call; the sole user, vhost-net, is serialised on the netdev work thread.
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Connects the R5F to Linux remoteproc over the NAVSS mailbox.
The mailbox ISR only drains the FIFO and acknowledges; OpenAMP delivery is
deferred to HPWORK, because the rpmsg rx path takes mutexes and allocates.
The resource table publishes two vdevs, rpmsg and virtio-net, leaving every
vring address FW_RSC_ADDR_ANY: Linux allocates them from the R5F DMA pool and
rejects fixed addresses outside it.
Shared IPC memory is mapped Non-cacheable, since the R5F is not coherent with
the A53 and cached mappings leave NuttX reading stale vring state.
Also drops the duplicate arm_mpu.c from CHIP_CSRCS.
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Add STM32_ETH_TIMESTAMP_RX for the STM32H7, as the one of the legacy
STM32 that provides the timestamp of the frames received.
Timestamp the PTP version 2 messages, over Ethernet and over UDP, except
for the announce, management and signaling messages. The MAC writes the
timestamp in a context descriptor after the last descriptor of the frame.
The driver reads it before giving the frame to the network stack and
passes it in d_rxtime, in the time of the system time of the MAC, the same
as /dev/ptp0. A frame that is not timestamped has a time of zero.
The timestamp goes over the address of the buffer of the context
descriptor, and the code that dropped the context descriptors used a
pointer that was never set. Keep the address of the buffer of each RX
descriptor, and restore it when a context descriptor is given back.
The timestamps of the PTP frames of a grandmaster clock were checked on
hardware against the system time of the MAC, and were within the delay of
the reads.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The STM32H7 page did not say anything about the Ethernet MAC.
- Describe the time counter of the MAC, the STM32_ETH_PTP option and its
behavior when the interface goes down.
- Describe the pulse-per-second output and the pins it can use.
- Describe the /dev/ptp0 clock the driver registers and the operations it
offers, and show a configuration that enables all of it.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The MAC has a system time that is the base of the PTP hardware
timestamps, but the driver never started it, and STM32_ETH_PTP only
printed a warning.
Add the registers of the timestamp unit and start the system time with
the fine update method and the digital rollover, so that the nanoseconds
count up to 10^9. The increment is 2 * 10^9 / HCLK ns, and the addend
makes the update rate half of HCLK, which leaves room to trim the
frequency in both directions. The time starts at zero right after the MAC
reset, not with the MAC configuration, so it does not depend on the PHY
having a link. The reset clears it, so it starts again each time the
interface goes up.
With STM32_ETH_PTP_GPIO, start the pulse-per-second output as a pulse
train with a period of one second and a width of half of it, at the whole
seconds of the system time. The fixed frequency mode of the MAC gives a
pulse too short to be seen, so the flexible mode is used. The interrupt
of the timestamp unit is not enabled in the MAC: it is set each time the
target time of the PPS output is reached and is cleared by reading
MACTSSR, which the interrupt handler does not do, so it would stay
pending and keep the handler running until the network stops.
Register /dev/ptp0 when CONFIG_PTP_CLOCK is set, so that a PTP daemon can
read and set the system time and correct its frequency and its phase.
The frequency is corrected by changing the addend, by up to 50% each way.
A step of the time is added or subtracted with the update register; with
the digital rollover a subtraction is programmed with the negated seconds
and with 10^9 minus the nanoseconds. The pulse train counts by itself, so
it does not follow a step of the system time and would be displaced by the
same amount: after the time is set or stepped, it is started again at the
next whole second.
With HCLK at 200 MHz the system time advanced 10.0018 s while a host
clock advanced 10.002 s, and the pulse train was seen on the pin. Reading,
setting, steps of +0.5 s and -1.25 s and a change of 100 ppm were done
through /dev/ptp0 on hardware, and the edges of the PPS output stayed at
the whole seconds of the system time.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The driver configured the pulse-per-second pin whenever STM32_ETH_PTP
was set, so a board that uses the timestamp unit without the pin still
had to define GPIO_ETH_PPS_OUT, and the pin was taken away from other
uses. The STM32F4 driver configures the pin with STM32_ETH_PTP_GPIO,
the option meant for it, but that option could not be selected on the
STM32H7, because it depended on the legacy STM32 families.
Configure the pin only with STM32_ETH_PTP_GPIO, and allow that option
on the STM32H7 and STM32H5.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
- Under CONFIG_NET_PROMISCUOUS, forward all control frames
(ETH_MACFFR_PCF_ALL) instead of only non-PAUSE ones, so link-local
PTP multicast reaches the DMA.
- Move ptp_to_timespec() above its first user so the TX timestamp path
can call it.
- stm32_receive(): do not log frames already delivered to packet
sockets (PTP, IPv6) as "Dropped, Unknown type".
- stm32_txtstamp_flush(): clear io_conn before freeing the looped-back
IOB.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Implement hardware TX timestamping support for STM32 Ethernet MAC
(stm32_eth_m3m4_v1.c) following the upstream SO_TIMESTAMPING loopback
architecture (PR #20161).
When an outgoing packet is flagged with SO_TIMESTAMPING (dev->d_iob->io_conn != NULL):
- Clone the IOB and hold a reference in priv->txmeta[txindex]
- Set ETH_TDES0_TTSE on the transmit DMA descriptor
- On transmission completion (stm32_freeframe), retrieve the hardware
timestamp from TDES6/TDES7, convert to timespec via ptp_to_timespec(),
and enqueue the clone onto priv->txtstampq
- Deliver pending TX timestamp clones back to netdev RX path in stm32_receive
using pkt_input(), where net/pkt intercepts the frame and delivers it to
userspace via recvmsg(..., MSG_ERRQUEUE)
- Properly drain pending queues and clones on interface down (stm32_ifdown)
Assisted-by: Gemini:gemini-3.8-pro
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
The Drop Transmit Status field of the MTL operation mode register is
bit 1, but it was defined as bit 0. The driver does not use it.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
