On Sat, Oct 31, 2026 at 5:00 PM Luca Giambonini <[email protected]> wrote: > > 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.
Hi Luca, Out of curiosity (and because it could help other developers struggling with HardFaults in the future, and they might search this mailing list for clues), do you remember what ended up being the cause of the HardFault? Thanks, Nathan > 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
