aviralgarg05 opened a new issue, #18380:
URL: https://github.com/apache/nuttx/issues/18380
### Description
# [GSoC 2026] Create a NuttX Distribution with Dynamic Binary (ELF) Loading
(350h)
## Dear NuttX community,
I am proposing the GSoC 2026 project **“Create a NuttX Distribution with
Dynamic Binary (ELF) Loading.”** NuttX already supports **dynamic loading of
ELF binaries** via the BINFMT/ELF loader, and shared-module loading via `dlfcn`
(see `examples/elf` and `examples/sotest`). However, the current end-to-end
experience is mostly “demo-level”: you manually place an ELF into a filesystem
and execute it.
The goal of this proposal is to turn NuttX’s dynamic loading capabilities
into a **practical, repeatable, distribution-like workflow**, where **apps and
libraries are shipped as packages** that can be
installed/updated/removed/rolled back on-device—without reflashing the entire
firmware.
This proposal is aligned with:
* **Jira:** NUTTX-20 (ELF loading validation, on-board application update,
library support)
* **GitHub feature issue:** `apache/nuttx#17351` (LVGL-based validation
steps, package manager, demo distro hosting)
---
## 1) Summary
This project builds a lightweight **“NuttX distro” layer** on top of
existing ELF/dynamic-loading support:
* A standard **package format** for apps and libraries (manifest + payload +
checksums; signatures as a stretch goal)
* A simple **HTTP repository** (index + downloadable artifacts)
* An on-device **package manager** (`pkg`) to install / update / remove /
rollback
* A **library distribution workflow** (initially using LVGL as the reference
library, as suggested in `#17351`)
* A **reference distro configuration** that is reproducible on **`sim`** and
validated on a local target (**ESP32 DevKit v1**) for real HTTP
download/install/update/rollback (with optional community/mentor hardware
testing if available)
Outcome: safe, atomic, rollback-friendly **field updates for installable
apps**, and a foundation for distributable libraries.
---
## 2) Motivation
Common pain points in embedded/RTOS deployments:
* The base firmware must remain stable, while apps/features evolve rapidly
* Security fixes, UI improvements, and feature updates should be possible
**without full reflashing**
* Power loss is possible in the field → updates must be atomic and
rollback-able
NuttX provides runtime mechanisms for ELF module execution (BINFMT) and
documents post-release updates via ELF programs. What is missing is a
**standardized distribution workflow**: packaging + repository + installer +
robust update semantics.
---
## 3) Research / prior art (what I studied)
### NuttX docs / in-tree examples
* **Binary Loader (BINFMT):** dynamic loading model + linking with base
firmware in FLASH
*
[https://nuttx.apache.org/docs/latest/components/binfmt.html](https://nuttx.apache.org/docs/latest/components/binfmt.html)
* **`examples/elf`:** relocatable ELF programs installed in a filesystem and
executed at runtime (`CONFIG_ELF`)
*
[https://nuttx.apache.org/docs/latest/applications/examples/elf/index.html](https://nuttx.apache.org/docs/latest/applications/examples/elf/index.html)
* **`examples/sotest`:** shared module loading using relocatable ELF +
`dlfcn` (`CONFIG_LIBC_DLFCN`)
*
[https://nuttx.apache.org/docs/latest/applications/examples/sotest/index.html](https://nuttx.apache.org/docs/latest/applications/examples/sotest/index.html)
* **ELF programs with symbol tables:** post-release extension model; symbol
tables & ELF from filesystem
*
[https://nuttx.apache.org/docs/latest/guides/partially_linked_elf.html](https://nuttx.apache.org/docs/latest/guides/partially_linked_elf.html)
* **Updating a release system with ELF programs:** guidance for released
firmware updates
*
[https://nuttx.apache.org/docs/latest/guides/updating_release_system_elf.html](https://nuttx.apache.org/docs/latest/guides/updating_release_system_elf.html)
* **Out-of-tree app builds (`make export`):** export headers/libs/startup
objects as a zip for external build environments
*
[https://nuttx.apache.org/docs/latest/guides/building_nuttx_with_app_out_of_src_tree.html](https://nuttx.apache.org/docs/latest/guides/building_nuttx_with_app_out_of_src_tree.html)
### Project-specific trackers
* Feature request / step list (LVGL validation, package manager, demo
hosting):
*
[https://github.com/apache/nuttx/issues/17351](https://github.com/apache/nuttx/issues/17351)
* Jira goals for the GSoC 2026 idea:
*
[https://issues.apache.org/jira/browse/NUTTX-20](https://issues.apache.org/jira/browse/NUTTX-20)
### Proposal styles used as references (NuttX issues)
* Long, design-heavy discussion style:
[https://github.com/apache/nuttx/issues/11979](https://github.com/apache/nuttx/issues/11979)
* Short proposal with spec background + verification checklist:
[https://github.com/apache/nuttx/issues/16158](https://github.com/apache/nuttx/issues/16158)
* Ongoing progress reporting issue format:
[https://github.com/apache/nuttx/issues/16503](https://github.com/apache/nuttx/issues/16503)
---
## 4) Goals and non-goals
### 4.1 Goals (must-have + stretch)
#### Must-have goals (as defined by the official GSoC idea / Jira NUTTX-20)
These deliverables map 1:1 to the idea list and the Jira issue:
1. **Test ELF loading in the current NuttX mainline** (baseline configs +
reproducible instructions)
2. **Create an application that can be downloaded and used to update an
existing version on the board** (v1 → v2 field update demo)
3. **Add library support on NuttX/NuttX-Apps** (using the **Android
Makefile** shared-library build pattern as a reference)
#### Stretch goals (from the longer feature proposal `apache/nuttx#17351`)
* A user-facing package manager (`pkg`) with install/update/remove/rollback
UX
* A demo distro repository (index + artifacts) hosted over HTTP
* Optional signatures (Ed25519) in addition to SHA-256 integrity checks
* Optional “remote maintenance” add-on: Dropbear (SSH) porting
### 4.2 Non-goals (to keep scope realistic)
* Full Linux-style dynamic linker parity (`ld.so` feature parity)
* Supporting every board/architecture in v1
* Complex dependency solving equivalent to `apt`/`dnf`
* A full “secure boot” redesign (signatures are a stretch goal, not a full
security framework)
---
## 5) Proposed architecture
### 5.1 High-level components
* **Repo (HTTP):** serves `index.json` and package artifacts
* **`pkg` manager (`nuttx-apps`):**
download/verify/unpack/transaction/rollback
* **Package store (writable FS):** `/data/pkgs/...`
* **Execution path (`nuttx`):** BINFMT/ELF loader executes installed app ELFs
* **Library support:** packaged shared modules + standardized search policy
for `dlopen`-style use cases
### 5.2 Architecture diagram
<img width="7557" height="2895" alt="NuttX Target
Application-2026-02-11-071118"
src="https://github.com/user-attachments/assets/c93586cb-41b6-491c-85cf-3ca2eab5c2ea";
/>
### 5.3 Distro data layout diagram (Mermaid)
```mermaid
flowchart TB
Data[/data/]
Pkgs[/data/pkgs/]
RepoDir[/data/repo/]
TmpDir[/data/tmp/]
Data --> Pkgs
Data --> RepoDir
Data --> TmpDir
Pkgs --> Name[/data/pkgs/<name>/]
Name --> Ver1[/.../<version-A>/]
Name --> Ver2[/.../<version-B>/]
Name --> Cur[current -> <version>]
Name --> Prev[previous -> <version>]
RepoDir --> Index[index.json]
TmpDir --> Downloads[downloads/]
```
---
## 6) Packaging format and repository
### 6.1 Package file format (v1)
A package is a single file (`.npkg`) using a `tar` container (simple and
tooling-friendly):
```
<name>-<version>-<arch>.npkg
manifest.json
payload/
bin/<app>.elf
lib/<libname>.so (optional)
share/... (optional)
checksums.txt (SHA-256)
signature.ed25519 (optional, stretch)
```
### 6.2 Manifest schema (example)
```json
{
"name": "lvgl-demo",
"version": "1.0.0",
"arch": "armv7m|riscv32|xtensa|sim",
"min_nuttx": "12.x",
"requires": {
"compat_id": "<firmware-exported-compat-id>",
"configs": ["CONFIG_ELF", "CONFIG_BINFMT"],
"libs": ["liblvgl.so>=1.0.0"]
},
"entry": "bin/lvgl-demo.elf",
"description": "LVGL demo app as a dynamically installable ELF",
"license": "Apache-2.0"
}
```
### 6.3 Repository index format (v1)
Repository is plain HTTP hosting:
* `index.json`
* `*.npkg` files
Example `index.json` (excerpt):
```json
{
"repo": "nuttx-demo-repo",
"generated": "2026-..-..",
"packages": [
{
"name": "lvgl-demo",
"versions": [
{
"version": "1.0.0",
"arch": "armv7m",
"url": "https://example.org/pkgs/lvgl-demo-1.0.0-armv7m.npkg";,
"sha256": "...",
"compat_id": "..."
}
]
}
]
}
```
### 6.4 Why `tar`? (alternatives considered)
* **tar:** simple, widely supported, easy to implement with minimal code,
works well for “manifest + payload”
* **zip:** also possible but may require additional footprint depending on
available libs
* **custom binary container:** possible but increases design/maintenance
cost for v1
For v1, tar-based `.npkg` keeps the project focused on robust update
semantics and on-device UX.
---
## 7) Update semantics (atomic install/update/rollback)
### 7.1 Transaction model
Key invariant: **the currently working version must never be broken**.
* Download → verify → unpack into a new version directory
* Switch the `current` pointer using atomic rename OR symlink swap
* Keep the last known-good version for rollback
Rollback:
* Switch `current` back to `previous` (or an earlier version)
### 7.2 State machine
<img width="5488" height="3420" alt="NuttX Target
Application-2026-02-11-071337"
src="https://github.com/user-attachments/assets/7df8e523-f6af-430e-bfc7-358e09280e5b";
/>
### 7.3 Update sequence diagram
<img width="5120" height="4815" alt="NuttX Target
Application-2026-02-11-071357"
src="https://github.com/user-attachments/assets/c397b5e8-3c9c-4c1b-8563-a3bf98fb1024";
/>
---
## 8) Technical design details (deep dive)
### 8.1 Execution model (how installed ELFs are run)
NuttX’s BINFMT framework loads the ELF from a filesystem path. The proposal
adds a consistent, distro-like path resolution:
* `pkg run <name>` resolves `/data/pkgs/<name>/current/payload/bin/<entry>`
and invokes execution
* Alternatively, users can execute the ELF directly if they prefer
**Design note:** v1 focuses on “installable apps executed via ELF loader.”
This keeps the runtime model close to existing NuttX examples and documentation.
### 8.2 Compatibility strategy (`compat_id`)
Dynamic ELF programs may depend on symbols exported by the base firmware.
Relocation failures due to mismatched symbols are unacceptable in a
package-update workflow.
**Proposal:** each firmware build exports a **compatibility identifier**
(`compat_id`) that packages must match.
**How `compat_id` will be computed (v1):**
* Hash of an ordered list of exported symbol names (and optionally
additional build fingerprints)
* Plus a small set of “must-match” flags: architecture, ABI-relevant configs
This ensures:
* A package built for one firmware export set will not be installed on an
incompatible system
* Failures happen early (install-time) rather than at runtime
#### `compat_id` generation flow
<img width="2184" height="1940" alt="NuttX Target
Application-2026-02-11-071630"
src="https://github.com/user-attachments/assets/a9f337a1-9920-4bde-94ad-8d5dcd16de29";
/>
**Expose `compat_id`:**
* Prefer a lightweight mechanism (e.g., procfs/sysinfo node or an API) so
`pkg` can read it.
### 8.3 Library support (LVGL reference) + `dlopen` path policy
The official idea requires **library support** in NuttX/NuttX-Apps and
explicitly suggests using the **Android Makefile** shared-library build
approach as a reference (see NUTTX-20 / `#17351`). The proposal follows that
guidance: I will implement a minimal, reviewable library build + packaging
workflow first, then layer a package-manager UX on top.
For library MVP:
* Libraries are packaged under `payload/lib/`
* Apps declare required libraries in `manifest.json`
* A minimal library search policy is implemented so `dlopen()` can resolve
packaged modules
#### Library search order (v1)
1. `/data/pkgs/<app>/current/payload/lib` (app-local libs)
2. `/data/pkgs/*/current/payload/lib` (global installed libs; configurable)
3. Existing system library paths (if any)
This approach is intentionally conservative and configurable via Kconfig.
### 8.4 Package manager CLI (command set)
`pkg` will live under `nuttx-apps/system/pkg`.
Planned commands:
* `pkg repo add <url>`
* `pkg update-index`
* `pkg search <pattern>`
* `pkg install <name>`
* `pkg install-url <url>`
* `pkg update <name>`
* `pkg remove <name>`
* `pkg list`
* `pkg run <name> [args...]`
* `pkg rollback <name>`
### 8.5 Security and integrity
**v1 (must):** SHA-256 verification for packages (from repo `index.json` or
sidecar)
**Stretch:** Ed25519 signatures
* Trust model: baked-in repo public key, or user provisioned key file
* Signature check performed before unpack
### 8.6 Build and packaging pipeline
A key part of making this “distro-like” is a reproducible build pipeline.
#### Two supported packaging workflows
1. **In-tree build:** build ELF apps using the NuttX build system, then
package artifacts
2. **Out-of-tree build (`make export`):** export headers/libs/startup
objects and build packages externally (recommended for a “distro builder”
experience)
#### Build pipeline diagram
<img width="7114" height="885" alt="NuttX Target
Application-2026-02-11-071720"
src="https://github.com/user-attachments/assets/2138215e-4717-477a-a328-a3da135b8e44";
/>
### 8.7 Demo distro hosting
A demo repository will be hosted via plain HTTP. v1 requires:
* a directory with `index.json` and `*.npkg`
* any static web server (Apache server, GitHub Pages, simple python http
server for development)
---
## 9) Implementation plan (structured as a PR series) (Tentative)
This section is intentionally written as a **sequence of reviewable PRs**,
aligning directly with the must-have goals from NUTTX-20 and the detailed step
list in `apache/nuttx#17351`.
**PR 1 — Baseline ELF loading validation (Goal #1)**
* Reproducible `sim` config for ELF loading + filesystem layout
* Bring-up notes for local hardware validation on **ESP32 DevKit v1**
* Document how to run `examples/elf` and `examples/sotest` reliably
**PR 2 — Reference “field-updatable” application v1 (Goal #2 setup)**
* Create the initial reference application (LVGL-based if feasible;
otherwise a smaller fallback app)
* Ensure it is buildable as an installable ELF and runnable from a
filesystem path
**PR 3 — Reference application v2 + on-board update mechanism (Goal #2)**
* Create the updated version of the reference application (v2)
* Implement a minimal on-board updater flow that:
* downloads the new ELF from an HTTP server,
* verifies integrity (SHA-256),
* atomically replaces/switches the active version,
* and keeps the previous version for rollback
* Validate end-to-end: v1 → v2 update on `sim` and on ESP32 where possible
**PR 4 — Library build support in NuttX-Apps (Goal #3 groundwork)**
* Add minimal support for building shared libraries in `nuttx-apps`
(following the **Android Makefile** library-building pattern as a reference)
* Produce a first shared library artifact suitable for runtime loading
**PR 5 — Library loading MVP (Goal #3)**
* Package and load one shared library module and one dependent app
* Validate runtime loading using `dlfcn` / `examples/sotest` style flows
* Document the expected directory conventions and the minimal search policy
**PR 6 — `pkg` skeleton + CLI parsing (stretch foundation)**
* Add `nuttx-apps/system/pkg` with `pkg --help` and stub subcommands
**PR 7 — Repo index fetch + cache**
* Implement `pkg repo add` + `pkg update-index`
* Save cached `index.json` under `/data/repo/index.json` with atomic write
**PR 8 — Package download + install pipeline**
* Implement `pkg install-url` download → verify (SHA-256) → unpack
* Install into `/data/pkgs/<name>/<version>/` and atomically switch `current`
**PR 9 — Update + rollback UX**
* Implement `pkg install <name>` / `pkg update <name>` selecting compatible
versions
* Keep previous version(s) and support `pkg rollback <name>`
**PR 10 — Demo repository + docs + integration tests**
* Provide a demo repo generator script (creates `index.json` + `.npkg`
artifacts)
* Host a small demo repo (HTTP) and document the setup
* Add an end-to-end integration script for `sim`: install → run → update →
run → rollback → run
---
## 10) Testing and validation
### 10.1 Targets
* **Primary:** `sim` (fast iteration + CI-friendly, full end-to-end coverage)
* **Secondary (local hardware available):** **ESP32 DevKit v1**
* Used to validate the real device workflow: HTTP download → verify →
unpack → run → update → rollback
* UI/LVGL validation will be demonstrated on `sim` if display hardware is
not available locally
* **Build/repo host (infrastructure):** **Raspberry Pi 5 (4GB)**
* Used to build packages, generate `index.json`, and host the demo HTTP
repository locally
* **Optional:** QEMU/emulated targets or community/mentor-provided boards
for additional confirmation
### 10.2 Test plan
1. **Unit-level components:**
* manifest parsing
* checksum verification
* pointer switching
2. **Integration:**
* install → run → update → run → rollback → run
3. **Negative testing:**
* wrong checksum
* wrong arch
* wrong `compat_id`
* interrupted install (simulate power loss by rebooting mid-transaction)
### 10.3 Definition of success
* Update failures never break the existing working version
* Clear diagnostics for incompatibility and loader failures
---
## 11) Timeline and milestones (12 weeks coding, 350h) (Tentative Plan)
> Dates will match the GSoC 2026 calendar; below is week-based.
### Community bonding
* Finalize the primary target (`sim`) + base configuration, and set up
automated end-to-end tests
* Bring up **ESP32 DevKit v1** with networking + a writable `/data`
filesystem for package storage
* Set up **Raspberry Pi 5** as the local build + repo host (serve
`index.json` + artifacts over HTTP)
* Confirm the `compat_id` strategy (hash inputs + exposure mechanism)
* Finalize package format v1 + repository schema
### Week 1–2: Baseline + `pkg` skeleton
* Validate `examples/elf` / `examples/sotest`
* `pkg` CLI skeleton + index download/cache
### Week 3–4: Install pipeline MVP
* download + SHA-256 verify + unpack
* install layout + atomic activation
* `pkg run` for installed apps
### Week 5–6: Update + rollback
* repo-based `pkg install` / `pkg update`
* rollback support + keep previous versions
* integration script for `sim`
### Week 7–8: LVGL (or fallback lib) packaging
* library package + dependent app
* minimal `dlopen` search policy
### Week 9–10: Field update demo (v1 → v2)
* create v1 + v2 of an app package
* demonstrate on-device replacement via `pkg update`
### Week 11: Hardening + documentation
* negative tests + interrupted install behavior
* developer docs: build firmware, build packages, host repo
### Week 12: Upstream polish
* split/rebase PRs as needed
* finalize integration tests
* final report
---
## 12) Risks and mitigations
1. **Hardware validation primarily on ESP32 DevKit v1 (single local target)**
* **Risk:** Some behaviors (storage characteristics, networking edge cases,
memory pressure) are best validated on hardware; with only one local board,
platform diversity is limited.
* **Mitigation:**
* Treat `sim` as the **reference correctness target** (deterministic,
CI-like, full E2E coverage).
* Use **ESP32 DevKit v1** to validate the real flow: HTTP download,
checksum verification, unpacking, and rollback robustness under constrained
resources.
* Keep MVP **target-agnostic** (packaging/update/rollback) and avoid
hardware-specific features as dependencies.
* If available, request optional community/mentor validation on additional
boards; MVP remains deliverable with `sim` + ESP32.
2. **ELF ABI / relocation / toolchain differences**
* **Risk:** Different architectures and toolchains can expose relocation
limitations, PIC requirements, or symbol-resolution edge cases.
* **Mitigation:**
* Start with a single well-defined baseline (e.g., `sim`) and lock a
consistent toolchain for package builds.
* Enforce install-time compatibility checks (arch + `compat_id` + minimum
required configs).
* Improve loader diagnostics (in `nuttx` only if necessary) to make
failures actionable.
3. **Firmware export-set drift (compatibility drift over time)**
* **Risk:** Packages that depend on base firmware exported symbols can break
if the firmware’s export set changes.
* **Mitigation:**
* Define and implement a clear **compatibility contract** using
`compat_id` (hash/fingerprint of exported symbol set + key ABI-relevant
settings).
* Make incompatibility a **hard install-time failure** (never a runtime
surprise).
* Document expected upgrade paths (e.g., packages must be rebuilt for a
new `compat_id`).
4. **Filesystem semantics and atomic activation**
* **Risk:** Some filesystems may lack symlinks, have differing rename
semantics, or behave unpredictably under power loss.
* **Mitigation:**
* Provide two activation mechanisms: symlink swap **and** pointer-file +
atomic rename fallback.
* Use a transaction-style flow: download → verify → unpack to versioned
dir → validate → atomic switch.
* Always preserve a last-known-good version for rollback.
* Add failure-injection tests (simulate interruption mid-install) to
verify “current remains runnable.”
5. **Storage/RAM footprint constraints**
* **Risk:** Package manager features (tar extraction, JSON parsing, download
buffers) can increase flash/RAM usage.
* **Mitigation:**
* Keep `pkg` minimal and configurable via Kconfig.
* Prefer streaming operations (download to file, extract incrementally)
and avoid large in-memory buffers.
* Implement retention policy (keep N previous versions, prune old
versions).
6. **Network reliability and (optional) TLS footprint**
* **Risk:** Downloads may fail intermittently; TLS may be heavy or
unavailable on some configs.
* **Mitigation:**
* Use checksums (SHA-256) to guarantee integrity and allow retries.
* Support both repo installs and offline/local installs (e.g., `pkg
install-url` from local FS).
* Make HTTPS/TLS support optional; HTTP is acceptable for a demo repo
while signatures are a stretch goal.
7. **Library loading policy complexity / safety**
* **Risk:** Global search paths for libraries can cause accidental conflicts
or unexpected dependency resolution.
* **Mitigation:**
* Use a conservative, documented search order with app-local libs first.
* Make “global lib search” configurable and disabled by default if
maintainers prefer.
* Keep library MVP limited: one library + one dependent app to validate
the mechanism.
8. **LVGL feasibility (size, dependencies, target constraints)**
* **Risk:** LVGL may be too heavy for the ESP32 target (or require display
hardware not available locally), which could complicate an on-device LVGL
demonstration.
* **Mitigation:**
* Validate the **core distro layer** (ELF install/update/rollback +
library support) independently of LVGL.
* Demonstrate LVGL-based app/library packaging on **`sim`** (where UI is
feasible), and keep ESP32 validation focused on network/update correctness.
* Maintain a fallback smaller library/app pair for the “library +
dependent app” proof if LVGL becomes impractical on hardware.
9. **Upstream acceptance / review load**
* **Risk:** Large changes are harder to review and may stall.
* **Mitigation:**
* Deliver as a structured PR series with small, reviewable units.
* Keep changes to `apache/nuttx` minimal and justified; most functionality
lives in `apache/nuttx-apps`.
* Include documentation and integration tests to make behavior and
regressions visible.
10. **Scope creep (turning into a full distro/apt-like system)**
* **Risk:** Over-expanding into complex dependency solving, security
frameworks, or multi-arch support can jeopardize delivery.
* **Mitigation:**
* Lock an MVP scope early: install/update/rollback + basic repo index +
minimal library proof.
* Clearly separate stretch goals (signatures, richer dependency
resolution, broader arch support).
---
## 13) Communication plan
* Weekly progress updates in a GitHub issue (progress-log style)
* Small PRs with clear scope and review-friendly diffs
* Decisions tracked publicly (schema changes, compat strategy, etc.)
### Weekly update template
* What I did this week
* PRs opened/merged
* What is blocked / questions
* Plan for next week
---
## 14) About me / contributions
I have been contributing to Apache NuttX with a focus on correctness and
toolchain compatibility.
* PR: `apache/nuttx#18308` — C++ `<cmath>` / external toolchain
compatibility improvements
* Few more PRs ready to merge
---
## 15) Verification checklist
### Baseline (before coding starts)
* [ ] I can build and boot `sim` with a writable `/data` layout suitable for
installs/updates.
* [ ] I can run `examples/elf` successfully on `sim`.
* [ ] I can run `examples/sotest` successfully on `sim` (or I have
documented why the config cannot support it).
* [ ] **ESP32 DevKit v1** boots NuttX and I have a writable `/data`
filesystem available for `/data/pkgs` (or an equivalent writable mount).
* [ ] **ESP32 DevKit v1** can access the network sufficiently to fetch over
HTTP.
* [ ] **Raspberry Pi 5** is ready as the build + demo repo host (serves
`index.json` + artifacts over HTTP).
### Package system MVP (must-have)
* [ ] `pkg update-index` downloads and atomically stores
`/data/repo/index.json`.
* [ ] `pkg install-url <url>` downloads a `.npkg`, verifies SHA-256, and
unpacks into `/data/pkgs/<name>/<version>/`.
* [ ] `pkg list` shows installed packages and the active `current` version.
* [ ] `pkg run <name> [args...]` resolves the active entry path and executes
the installed ELF via the ELF loader.
* [ ] `pkg remove <name>` removes an installed package without breaking
other packages.
### Update + rollback (must-have)
* [ ] `pkg install <name>` selects a compatible version from `index.json`
(arch + `compat_id` + `min_nuttx`).
* [ ] `pkg update <name>` installs a newer version and switches `current`
atomically.
* [ ] `pkg rollback <name>` switches back to the previous version and the
previous version runs successfully.
* [ ] If an install/update fails (bad checksum/incompatible `compat_id`),
the currently working version remains runnable.
### Library support MVP
* [ ] At least one library package (LVGL preferred, fallback acceptable) is
installable under `payload/lib/`.
* [ ] At least one app package depends on that library (declared in
`manifest.json`) and runs successfully.
* [ ] A minimal and documented library discovery policy exists for
`dlopen`-style loading (paths and configuration).
### Documentation + reproducibility
* [ ] Documentation exists for: base firmware config, building packages,
hosting the demo repo, and running install/update/rollback demos.
* [ ] A demo repository (HTTP) is available with `index.json` and at least:
app v1, app v2 (update demo), and one library package.
* [ ] An end-to-end integration script exists for `sim`: install → run →
update → run → rollback → run.
---
## Links
* Idea tracker (GitHub):
[https://github.com/apache/nuttx/issues/17351](https://github.com/apache/nuttx/issues/17351)
* Jira item (GSoC 2026):
[https://issues.apache.org/jira/browse/NUTTX-20](https://issues.apache.org/jira/browse/NUTTX-20)
* BINFMT docs:
[https://nuttx.apache.org/docs/latest/components/binfmt.html](https://nuttx.apache.org/docs/latest/components/binfmt.html)
* ELF example:
[https://nuttx.apache.org/docs/latest/applications/examples/elf/index.html](https://nuttx.apache.org/docs/latest/applications/examples/elf/index.html)
* Shared module example (`sotest`):
[https://nuttx.apache.org/docs/latest/applications/examples/sotest/index.html](https://nuttx.apache.org/docs/latest/applications/examples/sotest/index.html)
* Partially linked ELF guide:
[https://nuttx.apache.org/docs/latest/guides/partially_linked_elf.html](https://nuttx.apache.org/docs/latest/guides/partially_linked_elf.html)
* Release update guide:
[https://nuttx.apache.org/docs/latest/guides/updating_release_system_elf.html](https://nuttx.apache.org/docs/latest/guides/updating_release_system_elf.html)
* Out-of-tree build (`make export`):
[https://nuttx.apache.org/docs/latest/guides/building_nuttx_with_app_out_of_src_tree.html](https://nuttx.apache.org/docs/latest/guides/building_nuttx_with_app_out_of_src_tree.html)
### Verification
- [x] I have verified before submitting the report.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
