Add board support for the EK-RA8M1 evaluation kit with nsh and
nsh-leds configurations, linker script, LED support and bring-up.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: leocafonso <leocafonso@gmail.com>
Add initial architecture support for the Renesas RA8M1 (Cortex-M85)
family: clock configuration, GPIO, ICU/IRQ handling, SCI serial,
system timer, option setting and start-up code, plus the Kconfig and
build system integration.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: leocafonso <leocafonso@gmail.com>
Indent the case labels of the esp_ioctl() switch one level deeper, as
nxstyle expects, fix the odd indentation of the TIOCSERGSTRUCT case
and add the missing blank lines after declarations. No functional
change.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Erik Englund <erik.englund@gmail.com>
In RS-485 mode the DIR (DE) pin was only released on TX_BRK_IDLE_DONE.
That interrupt is part of the UART break feature (UART_TXD_BRK), which
this driver never enables, so it does not fire after normal data: DIR
stayed asserted after the first transmit and the port never received
again.
TX_DONE is the right event, but the upper half calls txint(false) as
soon as its software buffer is empty, while the last bytes are still
in the FIFO (see #15888), so it has to outlive txint(false):
* txint(false) keeps TX_DONE enabled on an RS-485 port.
* On TX_DONE with the software buffer and TX FIFO empty, the handler
waits (bounded) for the transmitter to go idle, releases DIR and
disables TX_DONE.
* txempty() uses uart_hal_is_tx_idle() (FIFO count and FSM state).
The raw TXFIFO_EMPTY bit only means the FIFO is below its empty
threshold, so tcdrain() could return with data still in the FIFO.
Same approach as the ESP32-S3 fix in #20389.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Erik Englund <erik.englund@gmail.com>
The RS-485 tx_idle_num block in esp_setup() ends in a bare "else" that
binds to the next statement, which is now leave_critical_section(). On
an RS-485 port esp_setup() therefore returns with interrupts disabled.
uart_open() hides this behind its own critical section, but a
tcsetattr() that changes the line settings calls esp_setup() through
TCSETS and leaves the calling task running with interrupts off. On an
ESP32-C3 the system tick stops advancing in that task.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Erik Englund <erik.englund@gmail.com>
In RS-485 mode the driver released the direction (DE) pin only on
TX_BRK_IDLE_DONE. That interrupt belongs to the break feature
(UART_TXD_BRK), which this driver never enables, so it never fired and
DIR stayed asserted after the first transmit. The board then kept driving
the bus and collided with every reply. The interrupt was also never
cleared, so had it fired, the handler would have re-entered forever.
TX_DONE cannot simply replace it: the upper half calls txint(false) as
soon as its software buffer drains, which disabled TX_DONE while the last
bytes were still in the FIFO (see #15888).
* Keep TX_DONE enabled in txint(false) while in RS-485 mode.
* In the handler, on TX_DONE with the software buffer and TX FIFO empty,
wait (bounded) for the transmitter FSM to go idle so the last stop bit
is not clipped, release DIR and disable TX_DONE. This is how ESP-IDF's
RS-485 half-duplex mode handles it.
* Make txempty() use FIFO count and FSM state, as ESP-IDF's
uart_ll_is_tx_idle() does. The raw TX_DONE bit reads 0 before the
first transmission and is now cleared by the handler, which would
make tcdrain() wait for its full timeout.
Tested on an ESP32-S3 board with an SP3485 transceiver (DE/RE on GPIO21)
at 115200 baud, doing Modbus RTU reads against a servo drive: without the
patch every request timed out; with it DIR drops right after the last stop
bit and all reads succeed.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Max Kriegleder <max.kriegleder@gmail.com>
In a protected build a module loaded by exec() runs as a user task, and
the loader puts it in the text and data heaps, which on this chip are
SRAM2. Nothing gave user code access to SRAM2: the region that would have
done so, in arm_addregion(), exists only with CONFIG_MM_REGIONS > 1, and it
is built with mpu_user_intsram(), which on ARMv8-M is execute-never. So
the module faulted on its first instruction.
The protected build now maps SRAM2 for user code to read, write and
execute when either heap is in use. Privileged execution stays allowed,
since a kernel module loaded with insmod lands in the same heaps.
On mps3-an547:knsh under QEMU, with CONFIG_ELF, both heaps and the ROMFS
variant of examples/elf, errno faulted on its first instruction with an
instruction access violation at 0x21000001. Now every module of the
example runs to the end.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Whitespace only, and older than the changes that follow. nxstyle checks
every file a pull request touches in full.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Every NXFLAT module imports __nxflat_abi_v2, and the loader resolves it
against the symbol table exec() is given, like any other import. It was
defined in binfmt/libnxflat, which is enough for a flat build, where the
firmware and the applications are one image.
In a protected build the table comes from the application, in the user
image, which cannot see a kernel symbol: the user image fails to link with
an undefined reference to __nxflat_abi_v2 as soon as an application
generates its table from the modules' imports, as examples/nxflat does. A
kernel build is the same, with one image per process.
libc is linked into each of those images, so the marker is defined there
now. Nothing else changes: its value is still never used.
On mps3-an547:knsh under QEMU with CONFIG_NXFLAT and examples/nxflat, the
user image links, and errno, hello, mutex, pthread and struct run.
lm3s6965-ek:qemu-nxflat still runs every module to the end.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Whitespace only, and older than the change that follows it. nxstyle
checks every file a pull request touches in full, and this one had 37
errors: the case labels of the relocation switch sat at the column of its
brace, three assignments were one column short, and a declaration had no
blank line after it.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
CONFIG_UNWINDER_ARM compiles everything with -funwind-tables, modules
included, so each module carries .ARM.exidx and .ARM.extab. The NXFLAT
link scripts do not name them, and ldnxflat placed them in D-Space, where
the first R_ARM_PREL31 entry stopped the conversion:
ldnxflat: arm relocation 42 at D-Space 00000018 is not handled
That relocation cannot be handled: an exidx entry is an offset from itself
to a function in I-Space, and the distance between the two segments is only
known when the loader places them. Nothing unwinds through a module
either, since the unwinder only reads the firmware's own table.
So ldnxflat leaves both sections out of the images, and with them the
relocations against them, as it already does for sections it does not
place. A module without unwind tables converts exactly as before.
On mps3-an547:nsh under QEMU with CONFIG_UNWINDER_ARM and examples/nxflat,
the modules failed to convert; now they convert and errno, hello, mutex,
pthread and struct run. The eleven modules of tools/nxflat/testsuite.sh
convert to the same bytes as before.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Advertise NETDEV_TX_STAMP in dev.d_features during stm32_ethinitialize()
when CONFIG_STM32_ETH_TIMESTAMP_TX is enabled, indicating that the STM32H7
Ethernet driver provides hardware TX timestamping.
Assisted-by: Gemini:gemini-3.8-pro
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Advertise the NETDEV_TX_STAMP capability flag in stm32_ethinitialize()
when CONFIG_STM32_ETH_TIMESTAMP_TX is enabled, indicating that the driver
provides hardware TX timestamping.
Assisted-by: Gemini:gemini-3.8-pro
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Add the NETDEV_TX_STAMP capability flag to d_features, next to the
existing NETDEV_RX_STAMP, so a driver can declare that it delivers
hardware TX timestamps.
SIOCETHTOOL and ETHTOOL_GET_TS_INFO were already defined but not
implemented. Add struct ethtool_ts_info, with the same layout as
Linux, and handle SIOCETHTOOL in netdev_ioctl.c so that userspace (such
as ptpd) can query the timestamping capabilities of an interface the
same way linuxptp/ptp4l does on Linux:
- ETHTOOL_GET_TS_INFO fills so_timestamping from d_features:
RX_HARDWARE | RAW_HARDWARE with NETDEV_RX_STAMP, otherwise
RX_SOFTWARE | SOFTWARE (the stack stamps received packets with
CLOCK_REALTIME), and TX_HARDWARE | RAW_HARDWARE with NETDEV_TX_STAMP.
phc_index is -1, tx_types and rx_filters are zero.
- Any other ethtool command is passed to the driver's d_ioctl when
CONFIG_NETDEV_IOCTL is enabled, otherwise -ENOTTY is returned.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
All SOF_TIMESTAMPING_* flags currently alias 1 << SO_TIMESTAMPING, so
they cannot tell hardware from software or RX from TX. Give them their
distinct Linux values, and add SOF_TIMESTAMPING_RX_HARDWARE,
SOF_TIMESTAMPING_RX_SOFTWARE and SOF_TIMESTAMPING_SYS_HARDWARE, so that
they can also describe the timestamping capabilities of an interface
(so_timestamping of ETHTOOL_GET_TS_INFO).
This does not change behaviour: setsockopt(SO_TIMESTAMPING) only checks
for a non-zero value and getsockopt() returns 0 or 1, so existing users
and binaries built with the previous values keep working. The
individual flags are still not honoured.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
The EdgeLock Enclave offers a key store the mailbox driver did not
reach. A key generated in there is permitted one algorithm and one
usage, and export can be withheld, so the private half has no command
that returns it.
Adds the session, key store and key management services, key generation,
signing by handle, and the storage exchange that makes a key store
outlive a boot. Storage runs the other way round from every other
command: the enclave asks the host to write its key store down and to
give it back, and those requests arrive while a command of this side's
is still outstanding, so the reply tag is what tells them apart.
Two things a port has to know and neither reference nor header says.
Key store commands carry a trailing crc, the exclusive or of every word
including the header, without which the enclave answers rating 0xb9. And
a persistent key lifetime is a statement of intent: the strict flag on
key generation is what writes the key to the store, and without it a
store exported around the key comes back without it.
Every mailbox wait is bounded. An enclave that stops answering must not
take the calling thread with it, and a reply buffer is a kilobyte, which
does not belong on the stack of whatever task asked for a signature.
Tested on an i.MX93: a P-256 key generated in the enclave, signing a
digest whose signature verifies against the returned public half on a
host, and still doing so after the board has been powered off.
Signed-off-by: Royyan Zahir <royzah@gmail.com>
nxstyle reports fourteen errors in this file. The switch in
usbhost_hub_configdesc() puts its case labels level with the brace that
opens the switch rather than one step further in, and a declaration is
followed straight away by a statement.
CI checks every file a patch touches rather than only the lines it
changes, so these have to go before anything else in this file can be
altered.
Whitespace, three comments rewrapped to stay inside the line limit
after the extra indent, and one blank line. No code changes: git diff
-w shows only the comments.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
struct usbhost_roothubport_s carries the number of the controller its port
belongs to, so a port can be named on a system with more than one.
Nothing set it.
Take the number from whoever brings the controller up rather than counting
registrations, which would agree with the name the driver reports only
while controllers are registered in the order they are named.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The driver refused CONFIG_USBHOST_HUB outright. Everything needed to
describe a device behind a hub is now in place, so implement the rest.
- xhci_device_init() took a root hub port and read the slot, the control
endpoint and the device out of it, all of which belong to the device.
It now takes the hub port and the control endpoint, and records the
device on the root port only when that is where it sits: once a hub is
plugged in, the device a root port names is the hub. xhci_address_set()
and xhci_device_deinit() likewise work on a device, and
xhci_disconnect() finds the device by the port going away.
- The hub asks for a port's control endpoint before it reports the
connection, so xhci_epalloc() has nothing to attach one to. It returns
an endpoint with no slot, and xhci_connect() gives it one when it
creates the device.
- A hub must be described to the controller as a hub before anything
behind it can be reached, and nothing knows it is one when its slot is
created. xhci_hub_update() corrects the slot context with a Configure
Endpoint command the first time something appears behind it.
- A hub reports each changed port without waiting for the last to be dealt
with, so the connect method queues them; holding one pointer meant the
second report overwrote the first. No more can be outstanding than the
controller has slots.
- Report the root port and slot counts from HCSPARAMS1, and the port count
from a hub's descriptor.
Tested on an EIC7700X board with a hub on one controller and a keyboard on
the other. Behind the hub, a 59 GB mass storage device mounts and reads a
file back, and a composite CDC device gives four ttyACM nodes.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A controller reaches a device by the path to it and, for a slow device,
through the hub that translates for it. Neither was described, so a
device behind a hub was addressed as though it were on the root port.
The route string is that path: each hub between the device and the root
contributes a nibble holding the port the next thing down occupies, tier
nearest the root in the lowest nibble. Walking up from the device reaches
the deepest tier first, so shifting left by a nibble each time leaves them
in the order the field wants. The walk stops after five, which is what
the field holds and what USB allows, and a port above fifteen is clamped.
Slot context dword 2 names the transaction translator carrying a low or
full speed device behind a high speed hub. It reports the hub by slot,
where EHCI reports it by USB address, and it names the nearest high speed
ancestor rather than the immediate parent, since a full speed hub below a
high speed one is itself carried by the translator above it. The think
time comes from the hub descriptor by way of the hub class driver, in the
same units.
xhci_epalloc() carried a copy of sam_ehci.c's block, writing
epinfo->hubaddr and epinfo->hubport, which is how EHCI describes a split
transaction in its queue head. This driver never read either field, and
xHCI wants the information in the slot context. Both fields and the code
setting them are removed.
Multi-TT is not set, for the reason given in the previous commit.
No functional change: hubs cannot be enabled yet, and a device on a root
port has neither hubs above it nor a translator.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Some host controllers must be told about the hubs in a topology, not only
about the device at the end of it. xHCI is one: a hub's slot context
carries a hub flag, its downstream port count and the think time of its
transaction translator, and the controller routes to anything behind that
hub using them.
The hub class driver already reads both values from the hub descriptor and
keeps them privately. Publish them on the hub's own hub port, beside the
speed and function address that already describe the device attached
there. A driver setting up a device behind a hub finds them on that
device's parent.
They are written before the hub activates any downstream port, so they are
in place before there is anything behind it, and a port with no hub
reports zero ports because the hub class clears each child before use.
Nothing is required to read them.
Fields rather than a driver method: a method would need a null check at
the call site and would define an order it must be called in. Both are
inside CONFIG_USBHOST_HUB, as struct usbhost_hubport_s's parent pointer
already is.
Multi-TT is not included; it comes from the hub's interface protocol
rather than its descriptor, and driving a multi-TT hub as single-TT costs
bandwidth behind it but is correct.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The slot, the default control endpoint and the device context lived in
struct xhci_rhport_s, and anything needing a device reached it as
rhport->dev. That holds only while every device is plugged straight into
the controller; a hub puts several behind one root port, each with its own
slot and context.
Two keys replace it. An endpoint records the slot it was opened on, so
xhci_dev_from_ep() answers which device a transfer belongs to. A hub port
belongs to one device wherever it sits, so xhci_dev_from_hport() answers
which device is on a port when there is no endpoint to ask yet.
The functions converted here used both at once: xhci_ep0configure() issued
Evaluate Context for epinfo->slot while filling in rhport->dev's context,
and xhci_ctrl_xfer() reached the endpoint ring through the port and back.
xhci_slot_init() read the speed and control ring through the port, which
would fail quietly, since the slot context speed field has no valid zero
and a low speed device behind a high speed hub does not share its speed.
No functional change for a directly attached device: its port's slot and
its endpoint's slot are the same, and its hub port is the root port's own.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Add the blank line required by nxstyle after the SMP-local declaration in
the profiling timer handler.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
Round the usable profiling buffer size down to complete unsigned short
counters before deriving highpc. Without this, an odd-sized buffer can
allow the timer handler to increment a counter that extends one byte past
the buffer.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
When waitpid(-1) finds an exited child in the retained status list, honor
WNOWAIT instead of unconditionally removing and freeing the child entry.
This makes the any-child path consistent with the specific-PID and SIGCHLD
paths.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
Add CMake build support for the stm32l476vg-disco board by introducing
board and source CMakeLists.txt files.
This allows the stm32l476vg-disco:nsh configuration to build successfully
with the CMake build system.
Fixes: #20366
Signed-off-by: Ahmed Ashraf NourEldeen <a.programmer55559@gmail.com>
The SAADC internal sample timer only works with a single enabled
channel, so hardware-timed multi-channel scan was not possible. Add
NRF52_SAADC_TIMER_PPI, a third trigger mode in which a general-purpose
TIMER compare event is routed to TASKS_SAMPLE over PPI. All enabled
channels are scanned, and the TIMER prescaler allows much lower sample
rates than the internal timer, which is limited to 16MHz/CC with CC in
80..2047.
NRF52_SAADC_CONTINUOUS is no longer tied to the internal timer and
works with either source. Its EasyDMA buffers now hold
NRF52_SAADC_CONTINUOUS_BUFLEN whole scans rather than that many single
samples, so MAXCNT becomes chan_len * BUFLEN. Samples are interleaved
scan by scan, so a channel map is built once at configure() time and
passed to the upper half with the batch; the upper half already accepts
a per-sample channel array. A single-channel configuration produces
the same MAXCNT and the same delivery as before.
Because both features want a PPI channel, add a build-time check that
NRF52_SAADC_PPI_CHANNEL and NRF52_SAADC_CONTINUOUS_PPI_CH differ, and
constrain the latter under the SoftDevice controller like the former.
NRF52_SAADC_CHANNELS gains a default and range for the new mode, and
documents that the internal timer is restricted to one channel.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
Publishes /proc/pinctrl on both boards, which lists every pad with the
function it currently carries. The startup banner counts how many pads
differ from their reset values, once, at boot; this answers the same
question at any later moment, which is what is wanted when a driver has
just reconfigured a pad and the result is not what was expected.
PINCTRL_PROCFS depends on FS_PROCFS_REGISTER, the entry registering
itself at run time rather than being one of the built in ones. Neither
board set it, and 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 the pinctrl get_pad method, so /proc/pinctrl and
PINCTRLC_GETPAD carry what this block is actually holding: each layout's
common fields with their validity bits, and the layout's own fields, the
RGMII and mode-select voltage bits and the oscillator tuning, as
key:value text.
Names every pad and every documented function select in one
PINCTRL_PADNAME() table, so func:2 on S_MODE reads as GPIO94 rather than
as a number. The names are the manual's own; a pad's name describes its
default function, not its current one. The table costs about 9 KiB and
is built only with the file that reads it; the name helpers return NULL
without it and the strings stay empty.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Log one line from board start up with the pad count and how many differ
from their reset defaults, through eic7700x_pinctrl_count(). A helper
holds its locals so nothing stays on the stack for the bring up that
follows.
Turn the pinctrl driver's error output on for both boards, so a refused
pad write says why rather than merely failing.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Every ball on this SoC is shared between several functions, and nothing
in this port could see which function a pad carried or change it. A
driver that finds nothing cannot tell a dead block from a pad still
pointed somewhere else.
Registers the CLMM pad multiplexer with the pinctrl framework and defines
every pad and every function select the manual documents, across the
straps, JTAG, PCIe, HDMI, Ethernet, I2S, SPI, GPIO, USB, I2C, UART, fan
and MIPI CSI groups. Writes nothing at start up: a pad only moves when a
driver asks.
eic7700x_pinctrl_count() reports how many pads currently differ from
their reset defaults, which after boot is the set the boot loader and the
drivers have configured; the board start up logs it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Nine of the seventeen configurations that set CONFIG_NXFLAT are on the CI
blacklist, and they are exactly the ones that build a module: the converter
they need was not in the tree. ldnxflat is in it now, so eagle100:nxflat and
lm3s6965-ek:qemu-nxflat come off the list. Both were built with the toolchain
CI uses.
The other seven stay off for reasons of their own. The thttpd configurations
need CONFIG_BOARDCTL_ROMDISK, which their defconfigs do not set, and the older
boards define their own CPICFLAGS without filtering --fixed-r9 out, so the
compiler refuses r9 as the PIC register.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Building an NXFLAT module takes four tools in sequence, and there was no way
to exercise them without a board. testsuite.sh builds every module of
apps/examples/nxflat/tests for cortex-m3 against a configured tree's headers,
and reports the stage each one stopped at and the relocations it carried.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
ldnxflat is the last piece of the NXFLAT toolchain that NuttX cannot carry.
It descends from elf2flt through four sets of copyright holders, so it is GPL
by that descent and not merely by its libbfd dependency. This is a new
implementation, written from include/nxflat.h, from what binfmt/libnxflat does
with the container, and from the ELF specification. The relocation arithmetic
is that of libs/libc/machine/arm/armv7-m/arch_elf.c, which the ELF loader runs
on the target for the same relocations, and which brings R_ARM_TARGET1 with
it.
NXFLAT is not an ARM format. Its loader only adds a base to a 32-bit word, so
the segments, the GOT, the relocation records and the header are common to
every architecture. An architecture supplies a table entry, an entry-point
convention and a relocation handler; an object for a machine with no entry is
refused by name.
The GOT is built here, because ld -r emits none: one entry per symbol that a
GOT-relative reference names, at the start of D-Space, each with a relocation
record of its own. An entry may hold a function, which is what makes a
function pointer reached through the GOT work.
Two defects of the out-of-tree tool do not survive. A GOT entry naming a .bss
object lost its section's address and pointed at the start of D-Space, the GOT
itself, so on lm3s6965-ek:qemu-nxflat the longjmp test panics with PC 0 and
the five tests after it never run. The alignment gap before .bss went missing
from h_bssend as well, leaving D-Space short.
The tool is built and named like the rest of the toolchain. Makefile.host
builds it, Unix.mk makes a configuration that sets CONFIG_NXFLAT depend on it
beside mknxflat, and LDNXFLAT points at the tool in the tree rather than one
on PATH.
All eight C modules of apps/examples/nxflat/tests convert and run to
completion under qemu-system-arm -M lm3s6965evb.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The converter that follows reads the same objects as mknxflat, so the reader
goes into a file of its own before it gains a second user. nxflat_elf.c
normalises the tables that describe the object -- the headers, the symbols,
the relocation entries -- into the host's order, and leaves the section
contents alone, because those are the target's bytes and the tools write them
out again. A tool reads a field without knowing whose order it arrived in.
The -d option goes with it. It chose a dynamic symbol table, which the ld -r
object these tools convert does not have, and which the NXFLAT loader cannot
use anyway: imports reach a module through the array mknxflat generates.
The output is unchanged. The thunk mknxflat generates for each of the eleven
modules of apps/examples/nxflat/tests is byte identical to the one the
previous version generated.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
A module's D-Space is separate from its I-Space, so its read-only data is not
at a fixed offset from its text. GCC assumes that it is and loads a string
literal PC-relative, which reads I-Space at run time. A module could
therefore carry no string and reach no static.
lm3s6965-ek has had -mno-pic-data-is-text-relative in its own Make.defs since
2021 (issue #3737), and the CMake build gives it to every PIC configuration,
so the flag moves to where it belonged and the board's copy goes. That copy
also probed for GCC older than 4.9.4, which NuttX no longer supports. Clang
has no such option, hence the guard.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The i.MX9x platform page carried only a board toctree, so there was nowhere
describing what the chip supports.
Add a peripheral table and a section on the random number generator: the
Kconfig chain, which of DEV_RANDOM and DEV_URANDOM come on by themselves,
and the health checks a block must pass before a read returns it.
Signed-off-by: Royyan Zahir <royzah@gmail.com>
The i.MX9 has a true random number generator behind the EdgeLock Enclave
and imx9_ele_get_random() to reach it, but nothing registers a character
device for it, so the entropy pool is never seeded from hardware. stm32h7,
nrf52, lpc54xx and rp23xx all provide one; imx9 does not.
imx9_ele.c was built only for CONFIG_IMX9_BOOTLOADER, putting the enclave
out of reach of the application core. It moves behind a new CONFIG_IMX9_ELE
that the bootloader selects, so existing configurations build as before.
A transfer that never lands is silent, so the buffer is prefilled with a
pattern and a block still holding it is refused, as is an all-zero block
and, by the FIPS 140-2 continuous test, a repeat of the one before.
Compiles for imx93-evk:nsh with CONFIG_IMX9_RNG=y.
Signed-off-by: Royyan Zahir <royzah@gmail.com>
Suppress the peer notifications while a ring keeps delivering work, batch
the receive completions into one kick per burst and drop the redundant
txdone signal from the transmit path. Validate the peer controlled frame
lengths, accept descriptor chains on both lanes, keep every ring access on
the upper half's work thread so the interrupt context callbacks stay lock
free, and prefer the MAC from the configuration space, falling back to the
Kconfig address or a random one.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Clarify that wd_start_next() requires a positive delay so callers do not
attempt to schedule the next expiration at the previous expiration time.
Assisted-by: OpenAI Codex <noreply@openai.com>
Signed-off-by: yushuailong <yyyusl@qq.com>
wd_start_next() schedules relative to the previous expiration. A zero
value reuses that expiration, so a callback can immediately reinsert an
already expired watchdog and make wd_expiration() loop without advancing
time.
Reject non-positive delays to guarantee that the next expiration advances.
Assisted-by: OpenAI Codex <noreply@openai.com>
Signed-off-by: yushuailong <yyyusl@qq.com>
Describe kernel_oct and kernel_n8r2 next to the other configurations of this
board.
The entry for kernel_oct carries what a user needs and cannot guess: a KERNEL
build is the only mode with fork() on this chip, the page pool is reached
through a scratch mapping rather than a permanent window, the ROMFS is linked
into the kernel image so a change to an application needs the whole
export-import-mkromfsimg-relink chain, how to confirm that the ROMFS is really
in the image, and that the shell needs the full path of a program.
The entry for kernel_n8r2 states its limit. Each region of a process is 2
pages, ostest has 115 KiB of text against a 128 KiB text region, and a larger
program needs a module with more PSRAM.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
kernel_oct targets a WROOM-2 N32R8V: octal flash, and 8 MB of PSRAM for the
page pool. The defaults size the pool for that part, with 8 pages of 64 KiB
for each of the text, data and heap regions, so 1.5 MB per process. fork()
duplicates the address environment, so a parent and a child need 3 MB at once
and a module with 2 MB of PSRAM cannot do it.
kernel_n8r2 sizes the same build for such a module. Each region is 2 pages,
so a process takes 384 KiB and a fork() peaks at 768 KiB, inside a 1.5 MB pool
placed at 0x80000 to leave the start of the PSRAM alone.
The flash is quad and runs in DIO mode, so this configuration also exercises
the CONFIG_ESP32S3_FLASH_MODE_OCT guard in kernel-space.ld from the quad side,
which kernel_oct cannot.
This is tight by construction. ostest has 115 KiB of text against a 128 KiB
text region. A larger program needs a module with more PSRAM, not a larger
pool.
Verified on an ESP32-S3-DevKitC with an N8R2 module, 8 MB flash in DIO mode
and 2 MB of embedded quad PSRAM. ostest reports "Parent and child had
independent memory" and exits with status 0.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
up_addrenv_fork() duplicates an address environment into freshly allocated
pages mapped at the same virtual addresses. The text, data and heap regions
of the source are walked one page at a time and copied into fresh pages hung
off the child's own directory, using the two kmap slots that
CONFIG_ARCH_KMAP_NPAGES reserves for exactly this.
xtensa_fork.c already took both paths: a child that keeps the parent's stack
addresses needs no relocation, which is what a duplicated address environment
gives it. Only the hook and the Kconfig default were missing.
fork() is offered on a kernel build, which is the only mode with per-process
address environments.
Verified on an ESP32-S3-WROOM-2 with esp32s3-devkit:kernel_oct. ostest
reports "Parent and child had independent memory" and exits with status 0.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The page pool is carved out of the PSRAM that user processes run from, and
the external memory permissions are indexed by physical address, so a
permanent kernel window onto the pool is a window onto every process, which
no permission setting can close.
Stop mapping the pool. The kernel reaches a pool page through a small
scratch region instead, mapped for one operation and invalidated afterwards.
esp32s3_pgmap() takes a slot, esp32s3_pgunmap() releases it, and
ARCH_KMAP_VBASE and ARCH_KMAP_NPAGES describe the region. Two slots are
enough, because the deepest user is up_addrenv_fork(), which holds a source
and a destination page at once.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The common Xtensa BUILD_KERNEL support needs the chip to say what it can do
and where its memory goes.
The chip selects the address environment options it now implements, keeps the
kernel and user heaps apart, and the linker scripts separate kernel from user
text and data so the two worlds can be given different permissions.
kernel_oct configures a board for it, with the user-program layout and the
boot ROMFS a kernel build loads its programs from. The ROMFS placeholder is
rebuilt with the image, the generated copy is ignored, and the programs are
given stack sizes and room for a fork() child.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The loader packs the allocatable sections of a fully linked program into the
text and data regions in section header order, and on a chip that selects
ARCH_HAVE_TEXT_HEAP_WORD_ALIGNED_READ every section that is not executable
goes to the data region. The template left .rodata in the text region, so
the addresses the program carries did not say where it would be loaded.
.rodata now leads the data region on such a chip, .eh_frame is placed rather
than left an orphan, and the Xtensa literal pools are gathered with the text
they belong to: a literal section is not executable, so an orphan one would
be loaded into the data region, away from the code that reads it.
The ESP32-S3 needs all three. With them the shared template lays out a user
program exactly as the board script it replaces did, section for section.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Give the ESP32-S3 the arch_addrenv_t machinery that BUILD_KERNEL needs: a
per-process page directory built from the 64 KiB MMU pages of the chip, with
allocation, teardown, and the vaddr-to-paddr translation that the kernel uses
to reach a user buffer.
The MMU, PMS and WCL primitives are exposed as an arch API first, because the
address environment code and the protected user split both need them and
neither owns them.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The protected kernel linker (kernel-space.ld) placed the octal (OPI)
flash bring-up helpers -- esp_rom_spiflash / esp_rom_opiflash_*,
spi_flash_oct_flash_init, mmu_hal, mspi_timing_*, bootloader_flash*,
efuse_hal/efuse_utility, esp_mmu_map and esp32s3_spi_timing -- in mapped
flash. During configure_cpu_caches() / spi_flash_init_chip_state() in
__start these run while the flash mapping is being reconfigured, which
faults (illegal instruction) on octal-flash modules such as the
ESP32-S3-WROOM-2. Quad-flash parts never exercise the OPI path, so the
problem was latent.
Place those functions in .iram0.text (mirroring the flat sections
script) so they are safe to execute during flash reconfiguration.
Assisted-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
