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>
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>
Without this the build says "arm-uclinuxfdpiceabi-ld: Command not found",
which does not say what that is, where to get it, or that the prefix can be
changed.
The make build reports at the link rather than while parsing, so that a tree
configured for FDPIC on a host without the linker can still be cleaned and
reconfigured: an error at parse time takes make distclean with it. The
cmake build reports while configuring, where nothing is built yet.
Both name FDPIC_CROSSDEV, so a linker under another prefix can be used.
Checked on mps3-an547:picostest with CONFIG_FDPIC and the linker off PATH:
make distclean succeeds, and a module link stops with the message. With the
linker present the modules build as before.
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The same two differences as in common/Toolchain.defs: the compiler is told
-mfdpic -fPIC, and the module link is done by an arm-uclinuxfdpiceabi
linker.
That linker is not the one that links the firmware, so the module link needs
a variable of its own. CMAKE_ELF_LD is the ordinary linker unless the
architecture sets it, which arm does under CONFIG_FDPIC.
The linker script needs nothing here: it is generated from
libs/libc/elf/gnu-elf.ld.in, which both build systems preprocess, and the
FDPIC segments are already in it.
-r is now conditional on CONFIG_PIC being off, which is what
common/Toolchain.defs has always done and the cmake build did not: a
position independent module is linked as an executable, and an FDPIC one as
a shared object, so neither wants it.
-fno-use-cxa-atexit mirrors CXXELFFLAGS for the same reason it was added
there.
Configured and built mps3-an547:picostest with CONFIG_FDPIC through cmake and
ninja: the modules in bin/ are ARM FDPIC with two PT_LOAD segments.
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
With CONFIG_FDPIC selected, a module built by apps/Application.mk is now an
FDPIC shared object. Nothing about how a module is written or built
changes: the same MODULE = m in the same Makefile, the same crt0 and the
same linker script.
Two things differ from the position independent build beside it. The
compiler is told -mfdpic -fPIC, and the link is done by an
arm-uclinuxfdpiceabi linker. The stock arm-none-eabi compiler emits correct
FDPIC objects for both C and C++, so only the link needs it: the stock
linker carries the armelf emulation alone and would turn every import into
an R_ARM_JUMP_SLOT, one word, where the ABI wants an R_ARM_FUNCDESC_VALUE,
which is two, a code address and the data base that goes with it. Such a
module links cleanly and then calls out of itself with the caller's data
base still in r9. That linker is in the CI image.
gnu-elf.ld.in gains the two segments an FDPIC module needs, under
CONFIG_FDPIC, because the loader places its read-only and writable segments
independently, and names .dynamic, because a shared object is bound through
it. The sections themselves are untouched and so are the symbols crt0.c
walks, so one script serves both and both build systems get it.
.bss moves to the end of the script, for every configuration and not only
FDPIC. It held no file content but sat ahead of .got and .dynamic, which
do, so the writable segment's p_filesz had to span it and the module file
carried the whole of .bss. A module with 16 KiB of .bss went from 26724 to
10340 bytes, and its writable segment from p_filesz 0x40ac to 0xac against
an unchanged p_memsz. The loader reads p_filesz off the media, so it read
those bytes too.
Built for mps3-an547:picostest with apps/examples/elf, CONFIG_FDPIC both
ways. With it on, every module in apps/bin is ARM FDPIC with two PT_LOAD
segments and enters at _start; hello++3, which has a static C++ object,
carries DT_INIT_ARRAY and DT_FINI_ARRAY. With it off the generated script
has no PHDRS and the modules are what they were.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
HID class devices fetch the HID Report Descriptor with a
GET_DESCRIPTOR setup packet whose recipient is an interface
(bmRequestType 0x81, wValue 0x2200). stm32_ep0out_stdrequest() only
dispatches device-recipient descriptor requests and stalls the rest,
so HID class devices cannot enumerate. Dispatch interface-recipient
requests to the class driver as well.
Signed-off-by: Huskya <itshusky01@gmail.com>
An ET_DYN object is loaded into one allocation with its data behind its
text, because its data references sit at a fixed distance from the code
that makes them. An FDPIC object does not work that way: it reaches its
data through a base register, so the two segments can be placed wherever
suits, and the point of the format is that the read-only one is left on
the media and executed there while only the writable one is copied. One
copy of the text then serves every instance.
So libelf_load() grows a second case. The object announces itself in the
OS/ABI byte, which is noted once in libelf_loadhdrs() rather than
re-derived; e_flags cannot be used for this, as an FDPIC object's are an
unremarkable EABI version and testing them would reject every valid
module. Text is taken from the media address plus the segment's own file
offset -- the same arithmetic the ET_REL path already does with
sh_offset -- and libelf_loadfile() does not read it. If the filesystem
cannot show its media, the loader copies the text to RAM instead. The
module then loses the shared text and the flash saving, but it runs.
Obtaining that address needs two mechanisms, and they are not
interchangeable. A compacting filesystem can move a file's blocks, so it
hands out an address only with a pin that holds them still and expects
the pin back; xipfs is the one in tree. A filesystem whose layout never
changes has nothing to hold and answers FIOC_XIPBASE with a bare address;
romfs and tmpfs are those. libelf_xipacquire() asks for the pin first,
because a filesystem that needs one is not safe without it, and
libelf_unload() gives it back. The loader asks for a pin only if it can
hold one, or the pin would stay for ever.
The pin is thus not specific to FDPIC. Any module that executes in place
from a compacting filesystem takes one, and gives it back at unload.
mmap() is not used, though both filesystems implement it. The mapping
would be recorded against whichever task called the loader, while the
release happens when the module's own task exits, which is a different
group -- so the pin would outlive the module and the extent would never
become movable again.
Unloading has to change with placement: the existing path frees only
textalloc because ET_DYN had a single allocation, which would leak an
FDPIC object's data and free media the filesystem only lent us.
Nothing here runs for a non-FDPIC object; every branch is behind the flag
and the single-allocation path is untouched. Built and booted
mps3-an547:picostest, which is CONFIG_ELF with CONFIG_PIC, with no change
in behaviour.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The commits that follow teach the ELF loader to load an FDPIC object. This
puts the option they hang off and the definitions they share in one place
first, so each of them builds on its own.
CONFIG_FDPIC depends on ARCH_HAVE_ELF_FDPIC, which an architecture selects
when it has a PIC base register and the FDPIC relocations. Only armv7-m
and armv8-m select it today, and it defaults off, so nothing changes for
anyone who does not ask for it.
include/nuttx/fdpic.h holds what both sides of the loader need: the two
word function descriptor an FDPIC module passes instead of a code address,
the test for whether the caller is such a module, and the call sequence
that enters one with its own data base. All of it is behind CONFIG_FDPIC,
thus the header is empty without it and a file may include it
unconditionally.
The call sequence itself is architecture specific, so arch/arm/include/arch.h
supplies it as up_fdpic_invoke(), beside the other PIC base register macros.
up_setpicbase() cannot serve here: the register has to hold the module's
base for exactly one call and then go back, and nothing in C tells the
compiler the register is live across that call, so the save, the install,
the branch and the restore have to be one sequence.
Built for mps3-an547:bl and mps3-an547:picostest, with CONFIG_FDPIC off,
which is every configuration in the tree.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
rp2040_allocep() indexes the endpoint's DPSRAM buffer/control
registers via RP2040_DPINDEX(eplog) and RP2040_EPINDEX(eplog), both
of which take the transfer direction from the direction bit of
'eplog' itself instead of trusting the explicit 'in' argument that
is also passed to this function.
This is harmless for callers that always encode the direction bit
into 'eplog' (e.g. CDC/ACM's CDCACM_MKEPBULKIN()/MKEPINTIN(), which
OR in USB_DIR_IN), since 'in' then always agrees with that bit. But
drivers/usbdev/usbdev_fs.c (the generic ADB/fastboot class driver)
calls DEV_ALLOCEP() with a bare endpoint number in 'eplog' (no
direction bit) and passes the direction only via the separate 'in'
parameter - matching this function's own "direction bit ignored"
contract for 'eplog' (see its Input Parameters doc, and the
pre-existing "Ignore any direction bits in the logical address"
comment, both dating back to the original driver in b860e3c4ad).
For such a bare-number IN endpoint, USB_ISEPOUT(eplog) always
evaluates true (the IN bit is never set on a plain number), so
RP2040_DPINDEX(eplog) silently pointed the endpoint's buffer/control
registers at its OUT slot instead of its IN slot. The real IN slot
was left unconfigured, so the SIE responded to every IN token on
that endpoint with a STALL - confirmed on real hardware via usbmon:
'C Bi:1:050:6 -32 0' (EPIPE) on every attempt, while the paired OUT
endpoint (which "accidentally" resolved to the correct slot for the
same reason) worked fine.
Fix: normalize 'eplog' to agree with the explicit 'in' argument
before it is used by RP2040_EPINDEX()/RP2040_DPINDEX(), so both
macros keep their original, single-argument form and every use of
eplog's direction bit below this point is consistent with 'in'.
Existing 0x80-encoded callers (EP0, CDC/ACM) already agree with 'in'
and are unaffected by the normalization.
Also fix two pre-existing nxstyle violations in this same file
(a misaligned comment block under USB_REQ_SYNCHFRAME, and a bare
';' body instead of empty braces on a while loop), both dating back
to the original driver in b860e3c4ad as well; CI runs nxstyle on
the whole file whenever it is touched.
Assisted-by: OpenCode:claude-sonnet-5
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Remove the per-arch testset implementation from the spinlock layer.
The testset abstraction predates the unified spinlock.h API and is no
longer used now that all arches provide spin_lock_irqsave()/
spin_unlock_irqrestore() directly. Drop the per-arch *_testset.{c,S}
implementations and spinlock.h files for arm, sim, sparc, tricore,
x86_64, and xtensa, along with the CXD56_TESTSET,
CXD56_TESTSET_WITH_HWSEM, and CXD56_ATOMIC_WITH_HWSEM Kconfig options
in arch/arm/src/cxd56xx, and simplify the CXD56 semaphore pool loop
in cxd56_sph.c to a single unconditional range.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
stm32_c22_read() and stm32_c22_write() waited for the MACMDIOAR busy bit
with up_mdelay(5) between checks. A Clause 22 frame takes about 30 us,
so the first check always sees the bus busy and every PHY register
access costs a 5 ms busy-wait, roughly 150 times the transfer.
stm32_phyinit() waits for link-up with PHY_RETRY_TIMEOUT (6552) MSR
reads. With no cable attached that is 33 s of CPU spent in
up_mdelay() inside ifup, with the network lock held: on an STM32H753
the netinit thread pinned the core at 44% for the first 65 s after
boot and every socket operation on other threads blocked until it gave
up. Before the MDIO bus refactor, stm32_phyread() polled the busy bit
in a tight loop.
Poll every 10 us instead, with the timeout expressed in microseconds so
the total bound stays at 10 ms, and report the timeout from the result
rather than the loop counter so a transfer that completes on the last
iteration is not logged as timed out.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Add reset_usb_boot ROM function typedef and wire it into
board_reset() so that 'nsh> reboot bootloader'
(BOARDIOC_SOFTRESETCAUSE_ENTER_BOOTLOADER) on RP2040 boards enters
BOOTSEL USB mass-storage mode directly, matching the behavior
already available on rp23xx boards. All other status values keep
the existing up_systemreset() behavior.
This affects all boards under boards/arm/rp2040/common (pico,
pico-w, feather-rp2040, xiao-rp2040, w5500-evb-pico, etc.) since
the change is in the shared board_reset() implementation.
Assisted-by: GitHubCopilot:claude-4.6-opus
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Add APIs to toggle the dual-bank flash mapping and reload the option bytes. Reject bank swapping when BOOT_LOCK is enabled and leave the swap operation as a no-op on single-bank devices.
Assisted-by: OpenAI Codex <codex@openai.com>
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
A C++ module with a static object does not link. GCC registers each such
object's destructor with __cxa_atexit(dtor, obj, &__dso_handle), and
__dso_handle comes from crtbegin, which a module does not link:
hello++3.cxx:119: undefined reference to `__dso_handle'
It is reachable today with CONFIG_PIC, where a module is linked as an
executable and the symbol has to resolve. Without it the link is
relocatable, the symbol stays undefined and nothing complains until
something makes it resolve.
-fno-use-cxa-atexit registers the destructors with atexit() instead, which
puts them in .fini_array. That is also where libelf_uninit() looks for them
when the module is unloaded, so the flag that makes the link work is also
the flag that makes the destructors run.
The option goes wherever CXXELFFLAGS is defined, which is the architecture
Toolchain.defs and the boards that reassign it. The toolchains that are not
GCC or Clang are left alone: ceva, tricore, z16 and the z80 family.
The CMake build sets it once, next to where the architecture elf.cmake is
included. A generator expression keeps it off the C compiles, because the
option is valid for C++ alone and GCC warns about it otherwise, and the
compiler id gates it so that a toolchain which is neither GCC nor Clang does
not see it. It cannot go in the toolchain file itself: CMake reads that file
again inside try_compile, in a project that has not included the NuttX
extensions, so the call is an unknown command there.
Reproduced with apps/examples/elf on mps3-an547:picostest with CONFIG_PIC
enabled: hello++3 fails to link before and links after.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The nRF5340 application core comes out of reset with its flash cache
disabled and nothing in the tree turns it on. nrf53_start() does call
nrf53_enable_icache(), but that drives NVMC ICACHECNF and is gated on
NRF53_FLASH_PREFETCH, which depends on NRF53_NETCORE -- so it is not
even compiled for an application core build.
The nRF5340 places the application core cache in a separate CACHE
peripheral at 0x50001000. NRF53_CACHE_BASE is already defined in
hardware/nrf53_memorymap_cpuapp.h, but there was no register header and
no enable. Add both, behind a new NRF53_CACHE option.
The option defaults to n, matching ARMV7M_ICACHE and
ARMV8M_ICACHE/DCACHE, so that upgrading does not silently change the
behaviour of an existing configuration.
Measured on nrf5340-dk at 64 MHz with apps/benchmarks/scbench:
protected-build syscall round trip 64.1 us -> 29.6 us
userspace sem wait + post pair 4.75 us -> 1.95 us
Flat builds benefit equally; the gain is on any flash-resident code
path.
Per the nRF5340 Product Specification, 'CACHE - Instruction and data
cache', 'both instruction and data accesses towards flash memory or XIP
code regions are cached'. The cache does not observe NVMC programming,
so nrf53_flash.c has to account for it: both up_progmem_eraseblock() and
up_progmem_write() read back what they just programmed to verify it, and
up_progmem_ispageerased() reads a whole page, so lines covering the
region being programmed are commonly resident. Bypass the cache for the
duration of an erase or a write and invalidate it before re-enabling, so
the verify reads the array and later readers do too. That file is built
only when NRF53_PROGMEM is selected, which is not the default.
Signed-off-by: AlmAck <gluca86@gmail.com>
The flash page number follows the logical memory mapping, but BKER selects a physical flash bank. Account for the nSWAP_BANK option when selecting BKER so erasing a logical address targets the corresponding physical bank after a swap.
Assisted-by: OpenAI Codex <codex@openai.com>
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The F412 has 256KiB of system SRAM at 0x20000000 and no CCM. The F2/F4
heap map had no F412 entry, so it used the 128KiB default at
0x20020000 and left the upper half unused.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Wire the RTL8721F (amebagreen2) into the shared Ameba timer driver
(arch/arm/src/common/ameba/ameba_timer.c), registered at /dev/timer0
(TIM1) and /dev/timer1 (TIM2). Only the per-chip base addresses, RCC
masks and IRQs differ, so this adds a small ameba_timer_chip.h (the two
32-bit basic LTIM timers at 0x40819200 / 0x40819400, 32.768 kHz,
APBPeriph_LTIM1/2, IRQ_TIMER1/2, verified against the SoC hal_platform.h
/ sysreg_lsys.h / vector table) plus the Make.defs/CMakeLists build
hooks, the fwlib ram_common/ameba_tim.c RAM source (now also pulled in
by CONFIG_AMEBA_TIMER, matching the PWM rule), the board bring-up
registration and a timer defconfig. The shared driver is unchanged.
TIM0 is left untouched because the boot ROM claims it as the always-on
system timer; reprogramming it would break every SDK delay.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Wire the RTL8720F into the shared Ameba timer driver
(arch/arm/src/common/ameba/ameba_timer.c), registered at /dev/timer0
(TIM1) and /dev/timer1 (TIM2). Only the per-chip base addresses, RCC
masks and IRQs differ, so this adds a small ameba_timer_chip.h (the two
32-bit basic LTIM timers at 0x40808200 / 0x40808400, 32.768 kHz,
APBPeriph_LTIM1/2, IRQ_TIMER1/2, verified against the SoC hal_platform.h
/ sysreg_lsys.h / vector table) plus the Make.defs/CMakeLists build
hooks, the fwlib ram_common/ameba_tim.c RAM source (now also pulled in
by CONFIG_AMEBA_TIMER, matching the PWM rule), the board bring-up
registration and a timer defconfig. The shared driver is unchanged.
TIM0 is left untouched because the boot ROM claims it as the always-on
system timer; reprogramming it would break every SDK delay.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Add a parameterised NuttX timer lower-half for the Realtek Ameba
general-purpose timers, sitting on the SDK fwlib RTIM register layer and
registered at /dev/timerN. The shared driver
(arch/arm/src/common/ameba/ameba_timer.c) reads a per-chip instance
table (ameba_timer_chip.h) for each timer's base, input clock, RCC gate
masks and IRQ; the period is programmed directly in microseconds and
converted to the 32-bit auto-reload with one clkfreq formula.
On the pke8721daf two of the 32.768 kHz "basic" (LTIM) timers are
exposed: /dev/timer0 is TIM1 and /dev/timer1 is TIM2. TIM0 is left
untouched because the boot ROM claims it as the always-on system timer
(SYSTIMER); reprogramming it would break every SDK delay. The RTIM
time-base entry points resolve to ROM, while the interrupt-clear and
period-change helpers come from the fwlib RAM source ameba_tim.c (shared
with the PWM driver).
Verified on hardware with examples/timer against both devices: the
update interrupt fires at the requested 1 s interval (measured with the
independent ROM SYSTIMER = 32768 ticks = 1.000 s).
Also whitelist the vendor RTIM_ symbol prefix in tools/nxstyle.c,
alongside the existing RCC_/SYSTIMER_ Ameba SDK entries.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Whitespace only: blank lines after declarations, misindented switch
bodies and brace alignment. nxstyle runs over the whole of any file a
change touches, and merging the CAN ioctl options renames a config in
every SocketCAN driver.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
TX-complete and the deadline watchdog each queued their own callback on
the same work_s, and work_queue() cancels whatever is pending when a
work_s is reused, so whichever ran second was dropped: deadlines were
left set, the TX interrupt mask stayed off, or expired frames were never
aborted. Both now queue imxrt_tx_work(), which retires completions
before it aborts expired mailboxes.
Add SIOCGCANERRORS so a socket can read fault confinement, TEC/REC, a
monotonic bus error count and the RX mailbox overrun count. SIOCGCANSTATE
reports sleep/operational, not fault confinement, hence a new command.
The error count is sampled from the clear-on-read ESR1 error flags at
every driver entry rather than from ERRINT, which fires per error frame
and storms at bus rate once the bus is dead. Frames the CAN socket layer
drops for want of an IOB now count as rx_dropped in the netdev
statistics as well as in the global CAN statistics.
Tested on an i.MX RT1176 (ARK FMU-v6XRT) running PX4 with two DroneCAN
nodes: unplugging one node the ioctl reports error-passive, TEC 128,
REC 0 and a monotonic error count, matching ECR/ESR1 read over SWD at
20 Hz, while the other interface stays error-active with zero errors.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
NETDEV_CAN_BITRATE_IOCTL, NETDEV_CAN_FILTER_IOCTL and
NETDEV_CAN_STATE_IOCTL guarded identical option blocks, and every
SIOCxCANxxx case in netdev_ifr_ioctl() forwarded a member of the same
ifr_ifru union to d_ioctl(). One option and one case block now cover
all of the CAN commands; drivers and defconfigs are updated to the
new name.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The SIOCxCANxxFILTER cases in fdcan_netdev_ioctl() call
stm32_addextfilter(), stm32_delextfilter(), stm32_addstdfilter() and
stm32_delstdfilter(), none of which exist anywhere in the tree. The
block only ever compiled because no stm32h7 config enables
NETDEV_CAN_FILTER_IOCTL; enabling it breaks the link. The commands now
fall through to the existing -ENOTSUP default, which is also what a
caller observed before.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
48-pin 1MB F412. CE was the only 48-pin part listed, so boards using
STM32F412CGU6 had to select a 512KB chip. Feature counts are identical
to CE, so it shares the block.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
100-pin 1MB F412 (LQFP/UFBGA). Without this, boards using
STM32F412VGH6 have to select the 48-pin 512KB CE.
STM32_NGPIO is 113 rather than the real 81 I/Os because
STM32_NGPIO_PORTS is (N+15)>>4 and 81 yields six ports A-F, so
PH0/PH1 could not be configured. 113 matches ZG and gives A-H.
CE/ZG chip.h counts and the family HAVE_* list are corrected in
the same change: CE has no FSMC, the die has TIM6/7/9-14 and
SPI4/5, ZG USART is 4, I2S is 5. FSMC is only bonded on 100/144-pin,
so HAVE_FSMC is selected on VG/ZG and not on CE.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Pre-existing violations in this file, reported by checkpatch because the
preceding commit touches it:
nrf53_gpiote.c:185: Missing blank line after declarations
nrf53_gpiote.c:213: Bad alignment
nrf53_gpiote.c:216: Bad alignment
nrf53_gpiote.c:259: Bad right brace alignment
Add the blank line after the declarations in the channel-callback block,
indent the two `break;` statements into their case bodies, and align the
brace closing the per-port `for` loop with its opening at line 209 (it
sat at seven spaces, so neither the loop's eight nor anything else).
Whitespace only — no functional change, brace count unchanged.
Signed-off-by: AlmAck <gluca86@gmail.com>
The driver presents a single channel space of GPIOTE_CHANNELS entries
across the application core's two GPIOTE peripherals, and splits it:
inst = (channel < GPIOTE_PER_CHANNEL) ? 0 : 1;
rchan = (inst == 1) ? channel : (channel - GPIOTE_PER_CHANNEL);
rchan is the channel index within the selected instance, used to build
the per-channel register offsets, so it must be
rchan = channel - GPIOTE_PER_CHANNEL * inst
The ternary has the two arms the other way round: a channel on instance
0 gets rchan = channel - GPIOTE_PER_CHANNEL, which is negative, and a
channel on instance 1 gets an index still offset by a full instance.
The interrupt handler in this same file already applies that mapping in
the opposite direction, converting a per-instance channel back to the
global one:
off = i + GPIOTE_PER_CHANNEL * inst;
so the two were inconsistent, and it is the rchan sites that were wrong.
Per the nRF5340 Product Specification, 'GPIOTE - GPIO tasks and
events', the application core has two GPIOTE instances, GPIOTE0 (secure,
base 0x5000D000) and GPIOTE1 (non-secure, base 0x4002F000), each with
eight channels and its own CONFIG[n] array at offset 0x510 + 4n for
n = 0..7. This matches GPIOTE_PER_CHANNEL == 8, the two base addresses
in hardware/nrf53_memorymap_cpuapp.h, and NRF53_GPIOTE_CONFIG_OFFSET()
in hardware/nrf53_gpiote.h, so rchan is required to be in 0..7 and a
negative value cannot address a CONFIG register.
With a negative rchan the CONFIG register write for a channel on
instance 0 lands below the instance base instead of in CONFIG[n], so the
channel is never configured and its GPIOTE interrupt is never enabled.
On nrf5340-dk this makes the board buttons dead.
Both call sites are corrected.
Signed-off-by: AlmAck <gluca86@gmail.com>
STM32_NGPIO_PORTS is (N+15)>>4. 81 (the real pin count) yields six
ports A-F, so PH0/PH1 cannot be configured. 113 matches the F40x
100-pin entries and gives A-H.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Fixed all the issues reported by checkpatch.sh in stm32_eth_m3m4_v1.c,
stm32f7/stm32_ethernet.c, stm32h5/stm32_ethernet.c, stm32h7/stm32_ethernet.c
Signed-off-by: alexcekay <alexander@auterion.com>
The STM32 Ethernet MAC drivers hard-code a 60-second TX watchdog
timeout. While this is a reasonable general default, certain board
designs and use-cases require a shorter or longer value.
Introduce CONFIG_STM32_ETH_TXTIMEOUT via the shared Kconfig.eth
with a #ifndef fallback. The default is kept at 60 seconds
to preserve existing behavior.
Assisted-by: Claude Code:claude-sonnet-5
Signed-off-by: alexcekay <alexander@auterion.com>
Wire the RTL8721F (amebagreen2) into the shared Ameba watchdog driver
(arch/arm/src/common/ameba/ameba_wdg.c), registered as /dev/watchdog0.
Only the per-chip base address and IRQ differ, so this adds a small
ameba_wdg_chip.h (WDG2 non-secure system watchdog at 0x4080AD80,
CPU0_NS_WDG IRQ 69, verified against the SoC hal_platform.h and
ameba_vector_table.h) plus the Make.defs/CMakeLists build hooks, the
board bring-up registration, and a wdg defconfig. The shared driver is
unchanged.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Wire the RTL8720F into the shared Ameba watchdog driver
(arch/arm/src/common/ameba/ameba_wdg.c), registered as /dev/watchdog0.
Only the per-chip base address and IRQ differ, so this adds a small
ameba_wdg_chip.h (WDG2 non-secure system watchdog at 0x40801D80,
KM4TZ_NS_WDG IRQ 52, verified against the SoC hal_platform.h and
ameba_vector_table.h) plus the Make.defs/CMakeLists build hooks, the
board bring-up registration, and a wdg defconfig. The shared driver is
unchanged.
Also corrects the RTL8720F row in the rtl8721dx chip-header reference
table (the non-secure system WDG IRQ is KM4TZ_NS_WDG = 52).
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Add a NuttX watchdog lower-half for the Ameba KM4 non-secure system
watchdog (WDG2), registered as /dev/watchdog0. The fwlib WDG API is
ROM-resident, so no board.mk change is needed.
The hardware cannot be stopped once enabled, so stop() is emulated via
the early interrupt (EI) auto-refreshing the counter, and capture()
delivers a pre-timeout callback through the same EI. The EI has a
three-part timing contract, all handled here: it must be armed with
EIMOD=ENABLE at WDG_Init, its EIE gate only takes effect after
WDG_Enable, and -- because the EI is level-based -- a pure capture path
must mask EIE after the one-shot callback to avoid re-entrant storming
while the reset is pending. The EI flag is cleared twice per the slow
WDG clock.
Per-chip base address and IRQ live in ameba_wdg_chip.h so the shared
driver needs no change to port to another Ameba IC.
Verified on pke8721daf: timeout reset (BOOT REASON WDG2), stop()
suppressing the reset, and capture() firing ~EICNT ms before the reset.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Implement PM STANDBY. Loosely based on stm32h7 with
simpler registers.
Implement PM STOP. Using a similar parameter to stm32h7's
LPDS mode bool. There is no LPDS on stm32h5 but there is
the same lower-power voltage scaling value, so rename the parameter
for stm32h5 and use SVOS5 without LPDS present.
Add arm_pminitialize implementation with default
pm subsystem initialization.
Co-authored-by: Austin.Chen <Austin.Chen@wnc.com.tw>
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Add missing blank lines after declarations and fix one bad alignment
in hostfs/rpmsgfs-related files. These are pre-existing style issues
flagged by CI's whole-file nxstyle check when our PR touches these
files. No logic change (git diff -w is blank-line-only additions).
Signed-off-by: yukangzhi <yukangzhi@xiaomi.com>
