Hello everyone, In August 2025, I wrote to this list while working on my first port. While I still consider myself a beginner, at the time I was battling a HardFault in sched_unlock on the DA1470x, armed with only basic GPIO and a write-only serial console.
Fast forward a year: the HardFault is long gone, and the project escalated significantly. I would now like to officially contribute a comprehensive port of NuttX to the Renesas DA1470x family (DA14701/05/06/08, formerly Dialog Semiconductor) and the DA14706-00HZDEVKT-P development kit. Before I start opening pull requests, I'd love your guidance on how to best split up a contribution of this size, along with two questions. === What the port covers === (All verified on the devkit unless noted) - Core: Clocks (XTAL32M, PLL160, RCHS; XTAL32K/RCLP low-power clock), power domains, interrupts, GPIO with wake-up controller, UART0-2, SysTick or a tickless time base on a low-power timer, and factory trim values from OTP. - Power: CONFIG_PM lower half (clock lowering, deep sleep, wake-up controller), and optional PD_SYS power-off with context save (experimental). - Peripherals: SPI, I2C, DMA, RTC with alarm, watchdog, OQSPI flash as MTD (XiP-safe), QSPI PSRAM, general-purpose ADC, battery charger, timer PWM, PWM LED sinks, and microphone capture with voice activity detector. - Graphics: Display controller as a framebuffer (QSPI panels, tearing-effect sync, double buffering, brightness; JDI parallel panels compiled only, untested). Also includes a register-level driver for the D/AVE 2D GPU. - Sensor Node Controller (SNC): The part's second Cortex-M0+ core, which keeps running while the M33 sleeps. Its firmware is built from source with the same toolchain as part of the NuttX build (no binaries in the tree). The M33 loads and supervises it, exchanging messages through rings in shared RAM and hardware doorbells (/dev/snc0 and a kernel API). Either side can wake the other, and the SNC survives its power domain being switched off. An input firmware debounces pins for the M33 (used for the board's buttons). - Board: DA14706-00HZDEVKT-P with an "nsh" configuration and documentation under Documentation/platforms/arm/da1470x. (Left out on purpose: Bluetooth LE, which requires the vendor's controller firmware binary, and a touch controller driver, which I will propose separately as a generic driver under drivers/input.) === Size and Status === The port is roughly 43k lines, almost entirely contained in new directories (arch/arm/src/da1470x, arch/arm/include/da1470x, boards/arm/da1470x). The only shared files touched are arch/arm/Kconfig and boards/Kconfig. The code passes nxstyle and checkpatch.sh, and builds with Make and CMake against current master and nuttx-apps master. === Questions for the Maintainers === 1. How would you like the PR? split or a single one? split like: a first PR with the chip core and the board (nsh over UART, RTC, watchdog, PM, tickless), followed by one PR per group: - Storage and memory (OQSPI MTD, PSRAM) - Analog and power (ADC, charger, PWM) - Display (LCDC, panel, always-on mode, GPU) - Audio - Sensor Node Controller I am also perfectly happy to send it as one single PR with one commit per group if reviewers prefer that workflow. Please let me know what is easiest for you. 2. Register definitions provenance The register headers in arch/arm/src/da1470x/hardware/ were generated via script from the CMSIS device header in the Renesas SDK (DA1470x-00.h). That source file is marked "Copyright (C) 2021-2022 Dialog Semiconductor ... Confidential, Proprietary Information ... All Rights Reserved". However, the generated headers contain only register names, addresses, bit positions, and masks, rewritten in NuttX style under the Apache license header. This exact same information is available in the public DA1470x datasheet. Is this acceptable as-is or Renesas asked for explicit permission? 3. Vendor firmware for Bluetooth LE The Bluetooth controller (CMAC) runs a firmware binary that exists only inside the Renesas SDK, which does not permit redistribution. For a later PR, would a driver that loads a firmware file supplied by the user at build time (via Kconfig path, BLE disabled by default, strictly no binaries in the tree) be acceptable? I've seen some other ports handle vendor blobs this way. === Process Notes === - ICLA: I have not yet signed an ICLA, but I am happy to do so if required for a contribution of this size - AI Assistance: I initially started this port manually, but later this year, using an AI coding assistant (Claude Fable) helped me unlock the project and finally complete the port. I have reviewed most of the generated code, and tested it on the devkit. I wanted to ask explicitly: is this level of AI usage accepted? You can preview the work on my fork here: https://github.com/AlmAck/nuttx/tree/da1470x-upstream <https://www.google.com/search?q=https://github.com/AlmAck/nuttx/tree/da1470x-upstream&utm_source=gemini> (three commits on top of current master: chip, board, documentation). Thank you all for your time, your help last year, and any guidance you can provide on upstreaming this! Best regards, Luca Giambonini
