Skip to work product
Google Summer of Code 2026

Building an application distribution layer for Apache NuttX

My GSoC project turned NuttX's ELF loader into a usable path for discovering, validating, installing, updating, and running applications after the firmware has already been flashed.

Read the final reportSee how it works
Project
Apache NuttX · Apache Software Foundation
Contributor
Aviral Garg
Mentors
Alan Carvalho de Assis · Halysson Carvalho
Snapshot
August 21, 2026
18GSoC pull requests
13merged upstream
5open at snapshot
10,783GitHub additions
How it works

What happens after someone chooses an application?

The project is a four-stage path around NuttX's existing ELF loader. Choose a stage below to see its input, what nxpkg owns, and what becomes possible next.

Stage 01

Read a package catalog

nxpkg starts with a local or network catalog rather than hard-coding applications into the firmware image.

InputCatalog and package metadata
nxpkg doesParse names, versions, platforms, dependencies, and artifact locations
ResultA package that can be inspected before anything is installed

Select a stage to follow one package from catalog to running application.

View the detailed architectureRepository input, package state, NXStore, and the NuttX runtime.

One owner for package state, one runtime path

The command line and NXStore call the same nxpkg service. Repository input is checked before it reaches the package root; the loader and supervisor then own execution and shutdown.

Architecture diagram showing a static package repository flowing through nxpkg into persistent package state, NXStore, and the NuttX loader and supervisor
Repository input, verified package state, and supervised applications remain separate concerns.
01Repository input is untrusted

Catalogs and artifacts are checked before they affect installed state.

02nxpkg owns package state

The shell and NXStore use one lifecycle API instead of separate state.

03NuttX owns execution

The loader and supervisor remain responsible for application processes.

What I built

Three pieces make the workflow usable

The package lifecycle, NXStore, and Library.mk are now upstream. Together they provide the device-side experience and a way for applications to package shared dependencies. Open each outcome for implementation details and source links.

nxpkg grew from a local installer into a recoverable lifecycle: sync, install, update, rollback, remove, and list. It supports local and network catalogs, validates metadata and paths, verifies SHA-256 digests, uses configurable versioned storage, and handles locks and interrupted state changes.

Initial implementationHardening seriesFinal lifecycle
Proof and source

Tested on hardware, documented in public

I kept hardware, simulator, and environment-limited evidence separate. The primary final workflow ran on an ESP32-S3 800 × 480 touchscreen board; the NuttX simulator helped isolate NXDoom's display path, and the earlier package fixtures ran on a XIAO ESP32S3 Sense.

NXStore catalog running on an ESP32-S3 touchscreen board
NXStore reading the catalog on the target device.
NXDoom title screen running as a supervised module on the ESP32-S3 touchscreen board
NXDoom reaching the title screen inside the supervised view.

Validation checks

Filter the results by where each check was run.

Showing 8 of 8 checks. Hardware, simulator, and environment-limited evidence stay explicitly separated.

Valid and invalid ELF fixturesPassHardware
Bad digest and staging cleanupPassHardware
Update, rollback, removePassHardware
Live and stale package locksPassHardware
NXStore launch and close loopPassHardware
NXDoom RGB565 outputPassSimulator + hardware
Shared-library load and unloadPassHardware
Fresh network re-testEnvironment-limitedActive image lacked Wi-Fi/loopback

Public pull requests

Merged work appears first. Use the filters to view all 18 pull requests or the work that was still under review on August 21.

Upstream snapshot13 merged · 5 in review

Showing 13 pull requests accepted into Apache repositories.

  1. nuttx-apps #3474Basic package lifecycle helperMerged+2,920 · 15 files
  2. nuttx-apps #3519Module metadata for executable toolsMerged+32 −18 · 11 files
  3. nuttx-apps #3526Packaged shared-library fixturesMerged+729 −31 · 8 files
  4. nuttx-apps #3531ELF and nxpkg validation fixturesMerged+687 −3 · 6 files
  5. nuttx-apps #3642Configurable, crash-aware package storageMerged+522 −57 · 5 files
  6. nuttx-apps #3718Catalog, path, and version validationMerged+355 −56 · 2 files
  7. nuttx-apps #3719Network catalog and artifact fetchingMerged+734 −1 · 4 files
  8. nuttx-apps #3720Lifecycle, rollback, locks, and recoveryMerged+628 −111 · 2 files
  9. nuttx-apps #3659LVGL touchscreen diagnosticMerged+266 · 5 files
  10. nuttx-apps #3643NXStore touchscreen frontendMerged+1,941 −87 · 7 files
  11. nuttx-apps #3662Brickmatch touchscreen and module supportMerged+324 −17 · 4 files
  12. nuttx-apps #3730Declarative shared-library supportMerged+257 −27 · 8 files
  13. nuttx #19888Shared-library declaration documentationMerged+25 · 1 file

Diff totals describe the GitHub review surface, not lines written from scratch.

Future work

From a working prototype to a real NuttX distro

The package core, NXStore, and shared-library declaration are upstream, and the product path runs on hardware. The next milestone is a store that explains each application before installation and a distribution that another person can reproduce on a supported board.

  • Integrate the remaining application, metadata, and documentation pull requests.
  • Display application icons and compact previews in NXStore before installation.
  • Publish a reproducible ESP32-S3 reference distro with a maintained catalog and recovery path.
  • Port the same distribution contract to STM32H7 and other capable boards.
  • Add signed metadata, repository policy, storage limits, and dependency rules.
  • Extend the merged shared-library support, then investigate CMake and FDPIC separately.
Original project issueApache NuttX AppsFinal report