esp_wifi_event_handler() held esp_wifi_lock() across the whole event
switch, including the esp_wlan_*_hook() calls
(WIFI_EVENT_STA_CONNECTED/_DISCONNECTED, WIFI_EVENT_AP_START/_STOP).
Those hooks reach netdev_lower_carrier_on()/_off(), which take the
per-device netdev_lock().
Every other path into esp_wifi_lock() acquires the two locks in the
opposite order -- the netdev ifdown path holds netdev_lock() around
its own call into esp_wifi_api_stop(), which calls esp_wifi_lock().
An application that disconnects Wi-Fi (wpa_driver_wext_disconnect()
immediately followed by wapi_set_ifdown()) races the resulting
WIFI_EVENT_STA_DISCONNECTED callback against its own ifdown call, and
the two lock orders wedge each other permanently.
Confirmed on real ESP32-S3 hardware (XIAO ESP32-S3,
CONFIG_ESPRESSIF_WIFI + CONFIG_PM + CONFIG_SCHED_TICKLESS): the
disconnecting task and the low-priority work-queue thread each waited
on a mutex held by the other (checked live via JTAG/GDB, not inferred
from code reading alone). Reproduced 4/4 times before this fix, 0/2
after.
Fix: esp_wifi_lock() is now taken only around the specific calls that
reach into the Wi-Fi driver API (esp_wifi_scan_event_parse(),
esp_wifi_set_ps()), never spanning a esp_wlan_*_hook() call --
netdev_lock() first (or absent), esp_wifi_lock() last, on every path.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-sonnet-5
This patch addresses two issues in the single-timer capture/compare
tickless OS drivers for STM32 families (common m3m4 v1 for F1/F2/F3/F4/G4,
F7, H7, and WB):
1. Zero-period handling: when up_timer_start() is called with a zero or
negative duration (or period converts to 0 ticks), the driver now
enables the compare match interrupt and immediately fires an event
via EGR (CCxG), avoiding missed events or unexpected counter behavior.
2. Compare-match race condition: after programming CCR and enabling the
compare interrupt, a post-check validates whether the free-running
counter already reached or passed count + period during register
configuration. If elapsed, the interrupt is forced immediately via EGR,
preventing the counter from missing the match and hanging until a full
32-bit rollover (approx. 71 minutes at 1 MHz).
Verified on real hardware:
- STM32H743ZI (IED R550): validated with ping, sleep, and usleep.
- STM32G431KB (Nucleo-G431KB): validated with uptime, sleep, and usleep.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
up_idlepm() (esp32s3_idle.c/esp32_idle.c/esp32s2_idle.c and the
shared risc-v esp_idle.c for esp32c3/esp32c6) has a recovery branch
that forces the domain back to PM_NORMAL when oldstate is not
PM_NORMAL and nothing is currently staying at it:
pm_stay(PM_IDLE_DOMAIN, PM_NORMAL);
pm_changestate(PM_IDLE_DOMAIN, PM_NORMAL);
newstate = PM_NORMAL;
pm_stay() here has no matching pm_relax() anywhere in any of the
four files. The first time this branch runs, the stay count for
PM_NORMAL never returns to 0, and pm_checkstate() (called
unconditionally right after this block) can never recommend
anything deeper than PM_NORMAL again for the rest of uptime -- the
idle loop keeps running, but the governor is permanently pinned at
full power, with no further light or deep sleep.
Confirmed on real ESP32-S3 hardware (XIAO ESP32-S3,
CONFIG_ESPRESSIF_WIFI + CONFIG_PM + CONFIG_SCHED_TICKLESS): reading
g_pmdomains[0] live via JTAG/GDB showed a "system" wakelock stuck at
state=PM_NORMAL, count=1, acquired a few seconds after boot (right
when Wi-Fi coming up briefly moves the domain off PM_NORMAL and this
branch then forces it back). Reproduced 4/4 times before this fix
(never a single PM_STANDBY transition or light-sleep-return log line
across a 40+ minute run), 0/4 after.
The trigger is timing-dependent (whether anything else already
holds PM_NORMAL at the moment this branch runs), which is likely why
it does not reproduce on every single boot.
Fix: release the stay right after the one pm_changestate() call it
exists to force, matching the comment already there ("Keep working
in normal stage") -- a one-shot nudge, not a standing hold.
Touching the switch statement right below the fix in all four files
exposed a pre-existing nxstyle violation (case labels indented level
with the switch's opening brace instead of one level in from it, per
NuttX style); reindented alongside since checkpatch lints the whole
file. esp32s3_idle.c also had two unrelated stray-indented lines
("Perform IDLE mode power management" / up_idlepm()) in up_idle();
fixed those too, same reason.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Moves EPWM initialization from am67_bringup.c to am67_pwm.c. Initialization
now requires only a function call in bringup.c.
Nxstyle checked, builds same.
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Adds a PWM lower-half for EPWM0 and EPWM1, covering both output channels of
each. The CTRL_MMR EPWM clock enables are unlocked once during board bring-up.
t3-gem-o1 registers /dev/pwm0 and /dev/pwm1 with PWM_NCHANNELS=2.
Verified on t3-gem-o1: all four outputs (EPWM0 A+B, EPWM1 A+B) drive physical
pins, jumpered into a Linux GPIO input -- 50% and 20% duty read back at the
expected sample ratios, and gpiomon timed a 50 Hz half-period at 9.998-10.002
ms. examples/pwm starts and stops a 1 kHz train cleanly.
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
openeth_receive() (arch/xtensa/src/common/espressif/esp_openeth.c)
tracks the next expected RX descriptor in priv->cur_rx_desc, an int
initialized to 0 exactly once, in esp_openeth_initialize(). QEMU's
esp32s3 machine models the OpenCores MAC's DMA ring pointer as
resetting to descriptor 0 every time RXEN is toggled off and back on
(openeth_disable()/openeth_enable(), called from ifdown()/ifup()), but
nothing rewinds the driver's own index to match. On the very first
bring-up both start at 0, so nothing looks wrong; from the second
ifup() onward the two permanently disagree, openeth_receive() keeps
inspecting the wrong descriptor, finds it still marked "owned by HW"
(e=1), and silently drops the notification. This breaks all inbound
traffic on the interface, not just application sockets -- ARP replies
and ICMP echo replies are RX frames too, so ping breaks identically.
Re-run the same descriptor initialization esp_openeth_initialize()
does at boot -- re-arm every RX/TX descriptor, rewind
cur_rx_desc/cur_tx_desc to 0 -- inside openeth_ifup(), under the same
critical section that already toggles RXEN.
Board-independent code, and open_eth only exists as a QEMU peripheral,
so there is no real-hardware regression risk.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The x86 CPP definition used `gcc -E -x c` without `-P`, unlike every
other arch's Toolchain.defs (arm, risc-v, avr, mips, misoc, or1k, z16,
z80 all pass `-E -P -x c`). Without `-P`, cpp emits GNU linemarker
lines (e.g. `# 0 "file"`) into its preprocessed output.
boards/Board.mk's PREPROCESS macro runs RCSRCS init.rc files through
$(CPP) before feeding them to apps/system/nxinit's parser. The parser
(apps/system/nxinit/parser.c) matches each line against known section
keywords ("on", "service", ...) with strncmp(); a leading linemarker
line does not match any keyword and the parser returns -EINVAL, so
any board that preprocesses an nxinit init.rc under x86 fails to
parse it at boot.
Reproduced independently on the host toolchain: `gcc -E -x c` on a
minimal init.rc emits `# 0 "file"` lines; `gcc -E -P -x c` on the
same input produces clean `service`/`on` lines only.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Simpleboot on espressif changes the location of irom and drom segments
in the image. Instead of correcting in `map_rom_segments` a routine
is introduced that corrects the load addresses before calling
`map_rom_segments`.
Signed-off-by: Laczen JMS <laczenjms@gmail.com>
Record the WKUP_I2C0 master in the board's Peripheral Support list.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Adds an I2C master driver for the AM67 I2C instances, completing transfers on
ARDY as the K3 controller signals.
Bring-up is deferred to the first transfer, because the Linux Device Manager
enables the I2C clocks late and touching the bus during early board init is not
safe here. The last reference drop clears the flag so the next transfer
re-initialises the hardware.
t3-gem-o1 registers WKUP_I2C0 as /dev/i2c2.
Verified on t3-gem-o1: i2c dev finds 0x30, 0x40, 0x51 and 0x68, the RTC at
0x68 reads a ticking BCD seconds register, repeated reads are consistent, and
NACK recovery returns the bus to a usable state.
Assisted-by: Claude Code:claude-fable-5
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
esp_openeth_initialize() (arch/xtensa/src/common/espressif/esp_openeth.c)
attaches the MAC interrupt with esp_setup_irq() but never calls
up_enable_irq(OPENETH_IRQ_MAC), unlike every other Espressif driver in
this tree. Left masked, openeth_isr_handler() never runs and received
frames are only picked up when the netdev work thread happens to run
for some other reason (a transmit). A guest can therefore send but
effectively not receive: ping still works because each request is
itself a transmit, while a socket blocked in recvfrom() waits on a
wake-up that never comes.
Confirmed with a GDB breakpoint counter on openeth_isr_handler():
zero hits before the fix, dozens after, under QEMU's esp32s3 machine
(the open_eth NIC it emulates). With the interrupt enabled, TCP
retransmits over a fixed test window dropped from 86 to 4.
Separately, openeth_ifdown() calls openeth_enable() right under a
comment that says "Disable TX and RX" -- it should call
openeth_disable(), which is what actually disables the two DMA
descriptor rings. Fixed alongside since it's the same function and
the same class of mistake.
Board-independent (arch/xtensa/src/common/espressif), not specific
to any one esp32s3 board; open_eth itself only exists as a QEMU
peripheral, so there's no real-hardware regression risk from either
change.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Assisted-by: Claude:claude-sonnet-5
up_switch_context() and up_exit() released the critical section and then
kept using the outgoing task's stack: a call/ret through
nxsched_switch_context() and the call into x86_64_fullcontextrestore().
Once the lock is released the outgoing task can be woken and run by
another CPU on that same stack, so those accesses race with it.
Release the critical section as the last step and enter
x86_64_fullcontextrestore() with a jmp so nothing is read from or
written to the outgoing stack after the release.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
x86_64_fullcontextrestore() built the iretq frame by pushing onto the
current stack. When called from up_switch_context()/up_exit() that is
the outgoing task's stack, and the outgoing task may already be running
on another CPU, whose pushes clobber the frame before iretq consumes it,
causing a #GP/#PF panic under SMP load.
REG_RIP..REG_SS are contiguous and match the iretq frame layout, so
point RSP at the register save area and iretq from there without
touching the stack at all.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
The initial IDLE RSP was placed inside the IDLE register save area that
up_initial_state() later carves out of the stack top, so the idle thread
ran on its own saved context and corrupted it, causing a #GP/#PF panic
under interrupt load. Compute the save area position exactly and start
RSP below it.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
The -16 in g_idle_topstack put the derived CPU0 idle stack base at
_ebss - 16, and tls_init_info() writes the TLS info there, corrupting
the last 16 bytes of .bss. Start the stack at _ebss like other
architectures.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
Fix a potential deadlock in the DMA driver. DMA completion callbacks
may immediately submit another transfer, for example:
imx9_dmaterminate()
-> imx9_dma_txcallback()
-> imx9_dma_txavailable()
-> uart_xmitchars_dma()
-> imx9_dma_send()
-> imx9_dmach_stop()
-> imx9_dmaterminate()
Resulting dmaterminate to take the same spinlock again. Fix this by moving
the spin_unlock_irqrestore_nopreempt before calling the callback. It is not
necessary to keep dma channel locked during the callback; the channel is
already free at this point.
This doesn't directly affect arch/arm/imx9 (the cortex-m version) because
it is not SMP (the spinlock is reduced to blocking irqs), but it is worth
fixing at the same to keep drivers in sync.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
The compilation of stm32_mpuinit.c is guarded by CMakeLists.txt and
Make.defs, so this is unneccessary.
Signed-off-by: Darryl Ring <darryl@bluerobotics.com>
If CONFIG_ARM_MPU and CONFIG_STM32_ICACHE are set, this will configure an
MPU region marking the OTP flash as non-cacheable. This prevents hard faults
when accessing the 4K OTP region from software.
Signed-off-by: Darryl Ring <darryl@bluerobotics.ca>
This adds MPU initialization code based on the STM32U5. Unlike the
STM32U5 code, though, this allows the MPU to be used outside of
PROTECTED build mode.
PROTECTED build mode is still not yet supported.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Darryl Ring <darryl@bluerobotics.com>
Add a Peripheral Support section to the board page listing the GPIO and
MCU_MCSPI0 drivers, and replace the "UART console only" warning on both
the chip and board pages -- it no longer describes the port. The
replacement states what actually constrains the port: NuttX runs on the
R5F under RemoteProc and depends on the bootloader or Linux Device
Manager having powered and clocked the peripherals, because there is no
TISCI client yet.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Adds the AM67 GPIO lower half and a polled MCU_MCSPI0 master driver, with the
pad configuration both need. The K3 instance is not the OMAP2 layout: an HL
header block precedes the functional registers.
Chip select is released only after CHSTAT.EOT, since a high SCLK otherwise
drops it mid-word and truncates the write, and CHCTRL.EN stays asserted between
transfers.
t3-gem-o1 registers /dev/spi0 for its ICM-20948 (CS3) and LPS22DF (CS1), and
raises NSH_MAXARGUMENTS to 16 so the spi tool can address a device.
Verified on t3-gem-o1: WHO_AM_I reads 0xEA on CS3 and 0xB4 on CS1, and the
ICM-20948 streams continuous accelerometer samples over the bus.
Co-authored-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Assisted-by: Cursor
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
APB1 bit 16 is CRS, not CRC (CRC is on AHB). RCC_CRRCR only holds the
HSIUSB48 calibration; the HSIUSB48 enable lives in RCC_CR.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
Gate the 32-bit USB DRD FS path of the common M0 usbdev driver on
STM32_HAVE_IP_USBDEV_M0_V2 instead of the STM32G0 family symbol.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
Allow sim HCI socket users to select the host-side HCI target at runtime
with --bt-dev. Passing --bt-dev=hciN overrides CONFIG_SIM_HCISOCKET_DEVID
for the BlueZ HCI user channel, while omitting the option keeps the existing
configured default behavior.
Also allow --bt-dev=/path/to/socket to connect to an H:4 stream exposed
through a Unix-domain socket. This lets sim applications use a controller
provided by another host process or by a UART-to-Unix-socket bridge without
requiring BlueZ raw HCI privileges for the NuttX process.
Use host-side output for early --bt-dev parse errors, since NuttX stdio is
not initialized before nx_start().
Document the BlueZ and Unix socket modes, including the capability
requirements for BlueZ and the socat bridge example for Unix socket mode.
Testing:
Host: Ubuntu 22.04 x86_64
Board/config: sim:bthcisock
Style checks:
git diff --check HEAD~2..HEAD
PATH=/home/mi/bsim-auto-test/.venv/bin:$PATH \
./tools/checkpatch.sh -c -u -m -g HEAD~2..HEAD
Clean build:
make distclean
./tools/configure.sh -l -a ../../nuttx-apps sim:bthcisock
kconfig-tweak --file .config --set-val STACK_USAGE_WARNING 0
make olddefconfig
make -j16
Invalid runtime argument smoke test:
./nuttx --bt-dev=invalid
Verified the command exits with status 1 and reports the invalid target
without crashing before nx_start().
Unix socket HCI smoke test:
socat -d -d UNIX-LISTEN:/tmp/hci.sock,fork,reuseaddr \
/dev/ttyACM2,b1000000,raw,echo=0,crtscts=1
printf 'ifconfig\nbt bnep0 info\npoweroff\n' | \
timeout 20s ./nuttx --bt-dev=/tmp/hci.sock
Verified the sim registers the Bluetooth network device as bnep0 and
bt bnep0 info reads the controller state through the Unix-socket HCI
path, including BDAddr aa:bb:cc:dd:ee:ff from the attached controller.
Assisted-by: OpenAI Codex
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Start the simulated HCI socket receive watchdog only after the host HCI
socket has been opened successfully. The previous code armed the watchdog
immediately after driver registration, before the Bluetooth stack opened the
driver and before the device had a valid host fd.
Cancel the watchdog on close/free and close any opened host fd during
allocation-failure cleanup. This keeps the polling path tied to the actual
socket lifetime and prevents the watchdog from polling an invalid host fd.
Testing:
Host: Ubuntu 22.04 x86_64
Board/config: sim:bthcisock
Style checks:
git diff --check HEAD~2..HEAD
PATH=/home/mi/bsim-auto-test/.venv/bin:$PATH \
./tools/checkpatch.sh -c -u -m -g HEAD~2..HEAD
Clean build:
make distclean
./tools/configure.sh -l -a ../../nuttx-apps sim:bthcisock
kconfig-tweak --file .config --set-val STACK_USAGE_WARNING 0
make olddefconfig
make -j16
Default startup smoke test:
printf 'poweroff\n' | timeout 10s ./nuttx
Verified the sim still reaches NSH and powers off cleanly. When no
host HCI controller is available through the default BlueZ target, the
board reports sim_bthcisock_register() failure and continues booting;
no invalid-fd watchdog crash occurs.
Assisted-by: OpenAI Codex
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Add support for using a BabbleSim PHY as the monotonic time source for
the Linux sim target. When CONFIG_SIM_BSIM_TIME is enabled, the sim
host build links a small host-side time helper against the BabbleSim
PhyCom and Util libraries. The helper joins the BabbleSim PHY wait
protocol and advances NuttX monotonic time through PB_MSG_WAIT requests
instead of Linux wall-time sleeps.
A SIM binary built with CONFIG_SIM_BSIM_TIME enabled joins BabbleSim time
at startup. Runtime options allow the test runner to select the
BabbleSim simulation id, PHY id, and device number:
--sim-bsim-sid=<simulation-id>
--sim-bsim-pid=<phy-id>
--sim-bsim-dev=<device-number>
Keep the integration inside the sim host time path rather than exposing
a new application API. RTC/realtime reads still use the host realtime
clock; the BabbleSim source is used only for monotonic time after the sim
has joined the PHY. The Kconfig option depends on the sleep based
walltime mode and is disabled for SMP and non-Linux hosts.
The build requires BSIM_COMPONENTS_PATH for headers and either
BSIM_OUT_PATH or BSIM_LIBS_DIR for shared libraries. The path checks are
skipped for clean, distclean, clean_context, and context targets so a
tree with CONFIG_SIM_BSIM_TIME enabled can still be cleaned without
exporting the BabbleSim environment first.
Document the configuration, build environment, runtime options, and the
requirement that the BabbleSim PHY process is started separately by the
test runner.
Testing:
Host: Ubuntu 22.04 x86_64
Board/config: sim:nsh
Style check:
git diff --check
Default sim build and smoke test:
./tools/configure.sh -l -a ../nuttx-apps sim:nsh
make -j16
printf 'help\npoweroff\n' | timeout 20s ./nuttx
BabbleSim-enabled build:
kconfig-tweak --file .config \
-e SIM_WALLTIME_SLEEP \
-d SIM_WALLTIME_SIGNAL \
-e SIM_BSIM_TIME
make olddefconfig
BSIM_OUT_PATH=/tmp/bsworld/build/babblesim/bsim \
BSIM_COMPONENTS_PATH=/tmp/bsworld/build/babblesim/bsim/components \
make -j16
Verified actual BabbleSim PHY time integration without a controller by
starting bs_2G4_phy_v1 and running NSH usleep through the PHY wait
barrier:
bs_2G4_phy_v1 -s=<sid> -D=1 -defmodem=BLE_simple -nodump
printf 'usleep 1000000\npoweroff\n' | \
./nuttx --sim-bsim-sid=<sid> \
--sim-bsim-pid=2G4 \
--sim-bsim-dev=0
The same 1 second simulated sleep completed in 19 ms wall time when no
handbrake device was present. With handbrake registered as device 1:
bs_2G4_phy_v1 -s=<sid> -D=2 -defmodem=BLE_simple -nodump
bs_device_handbrake -s=<sid> -p=2G4 -d=1 -pp=50000 -r=1
the same NuttX usleep test completed in 985 ms wall time. A shorter
200 ms check showed the same behavior: 27 ms without handbrake and
172 ms with handbrake. This verifies that NuttX sim time advances
through the BabbleSim PHY and that the handbrake affects the NuttX sim
device.
Also verified make distclean succeeds after CONFIG_SIM_BSIM_TIME was
enabled and without exporting BSIM_COMPONENTS_PATH.
BSWorld out-of-tree native BLE examples:
./tools/configure.sh -l /path/to/bsim-auto-test/tests/nuttx/native_ble/source/advertiser/config
make -j16
exodus --tarball -o /path/to/bsim-auto-test/tests/nuttx/native_ble/source/advertiser/prebuilt/nuttx.tgz nuttx
./tools/configure.sh -l /path/to/bsim-auto-test/tests/nuttx/native_ble/source/scanner/config
make -j16
exodus --tarball -o /path/to/bsim-auto-test/tests/nuttx/native_ble/source/scanner/prebuilt/nuttx.tgz nuttx
pytest tests/nuttx/native_ble -q --no-ellisys
Assisted-by: OpenAI Codex
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
A function pointer under FDPIC is not a code address. Because each
PT_LOAD segment is placed independently, a pointer has to carry the data
base its callee will need, so it is a two-word descriptor: the entry
point, and the base to install in the PIC register before branching.
R_ARM_FUNCDESC_VALUE says "the thing you are patching is such a
descriptor", and R_ARM_FUNCDESC says "manufacture one and give me its
address".
Both need state a relocation cannot carry. A descriptor's second word is
the *object's* data base, from DT_PLTGOT, and R_ARM_FUNCDESC carves
descriptors from a pool whose cursor has to survive from one relocation
to the next. up_relocate() is handed only a relocation, a resolved
symbol and an address to patch.
arch_data is the existing channel for exactly this -- RISC-V already uses
it to remember a HI20 relocation while its LO12 partner is processed --
but nothing has ever put loader state into it: it is declared zeroed and
written only by up_relocate() itself. So ARCH_ELFDATA_INIT and
ARCH_ELFDATA_FINI are added, seeding the block from the loadinfo before
the relocation loop and reading the cursor back after. Both default to
nothing, so an architecture that does not define them is unaffected, and
RISC-V's use of arch_data is untouched. libelf_relocatedyn() walks both
dynamic tables under one arch_data, so the cursor spans the whole object.
The addend handling is the part that is easy to get wrong. REL format
keeps the addend in place, in the word about to become the entry point,
and a pointer to a static function is referenced through its *section*
symbol -- the value is the section base and the offset, including the
Thumb bit, is entirely in the addend. Dropping it yields an even address
and the core faults trying to execute it as ARM code.
The GOT written into a descriptor is the loading object's own, even for
an imported function, which is what makes a callback work: when the base
firmware's qsort() calls back into a module's comparison function, the
module needs its own data base in the PIC register.
libelf_relocatedyn()'s imported-symbol path needed a change to suit. It
stores the resolved address directly and never calls up_relocate(), which
cannot produce a two-word descriptor, so under FDPIC the resolved value
now goes through up_relocate() and the relocation type decides what to
write.
Implemented for armv7-m and armv8-m, the profiles FDPIC targets; the
other ARM variants gain the arch_data block but no new relocations.
Built and booted mps3-an547:picostest and lm3s6965-ek:qemu-nxflat, the
ELF PIC and NXFLAT users of this code, both unchanged.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
When executing in place from flash, the XIP FlexSPI clock must not be
reconfigured during the initial clock setup. The boot ROM configures the
clock for its flash read sequence, and changing it before the board installs
a suitable high-speed read sequence can break instruction fetch. The board's
flash setup may reconfigure the clock afterward.
Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
LDREX/STREX to Shareable memory needs an external exclusive monitor, and this
Cortex-R5F has none on the path to DDR; Non-shareable uses the core-local
monitor instead. Every atomic compiles to inline LDREX here, since the chip
selects no LIBC_ATOMIC_* backend and falls back to LIBC_ATOMIC_TOOLCHAIN.
Verified on t3-gem-o1: without this the core runs but the console never
appears; with it the same image boots and ostest exits with status 0.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Add what a kernel build needs on Xtensa: a crt0 for a user process, the
kernel stack allocation that a system call switches to, the syscall entry and
return path for an unprivileged caller, and the initial register state that
starts a user task at EL0 with its save area on the kernel stack.
On the ESP32-S3 the arch code that runs while the flash mapping is in flux
moves to IRAM, and the kernel heap is placed above the user .bss so that
up_allocate_kheap() and the user address environment do not overlap.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
intel64_oneshot_handler() cleared oneshot->handler and oneshot->arg
after picking them up, without holding g_oneshot_spin, while
intel64_oneshot_start() re-arms the timer under that lock from another
CPU. Now that the HPET ISR stays attached across a re-arm, a stale
interrupt can interleave with start(): it reads the freshly installed
handler, clears it, and start() then sets running = true again, so the
genuine expiry that follows finds running == true with a NULL handler
and jumps to address zero from interrupt context (page fault at RIP 0
in the CPU0 IDLE task while the LTP lio_listio tests were running), or
the alarm is simply lost and the tickless system stops.
The handler and its argument are owned by start() and cancel(); the ISR
only needs to read them. Leave them alone in the ISR and skip the call
if none is installed. The remaining effect of a stale interrupt is an
early invocation of the alarm callback, which is harmless: the tickless
scheduler re-evaluates its expirations and re-arms the timer.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
