Skip to content

[Discussion][GSoC 2026] Create a NuttX Distribution with Dynamic Binary (ELF) Loading (350h) #18380

Open
Open
[Discussion][GSoC 2026] Create a NuttX Distribution with Dynamic Binary (ELF) Loading (350h)#18380
Labels
Community: QuestionFurther information is requestedgsoc2026

Description

@aviralgarg05
aviralgarg05
opened on Feb 11, 2026

Description

[GSoC 2026] Create a NuttX Distribution with Dynamic Binary (ELF) Loading (Proposal V2)

Thanks for the feedback on February 11 and February 12, 2026.
I have rewritten this proposal to keep the scope tighter and practical for GSoC.

1) Goals (NUTTX-20)

I want to deliver these 3 goals first:

  1. Test ELF loading on current NuttX mainline.
  2. Build an app update flow where a new version is downloaded and replaces the old one on-board.
  3. Add library support in NuttX/NuttX-Apps (using Android Makefile shared-library approach as reference).

2) Scope for GSoC

In scope:

  • Reproducible ELF and shared-library validation.
  • Minimal package workflow: install, update, remove, rollback.
  • Integration with NuttX build systems (Makefile + CMake).

Out of scope for core delivery:

  • Full apt/dnf-style dependency solver.
  • Full dynamic linker parity.
  • Secure-boot redesign.
  • Optional extras like signatures or Dropbear (only if time allows).

3) Package manager direction

Command set will follow familiar package-manager style:

  • pkg search
  • pkg install
  • pkg update
  • pkg remove
  • pkg list
  • pkg rollback

I removed pkg run from the primary command set.

4) ppkg decision

I checked ppkg as suggested.

  • It is promising and license-compatible.
  • But for this GSoC timeline, I think a full on-device ppkg integration is higher risk.

So for this proposal, I am choosing a minimal native pkg MVP first, and I will reuse ideas from ppkg where useful.

5) Minimal design

Package layout

flowchart TB
  Root["/data/pkgs"] --> Name["package-name"]
  Name --> V1["version-A"]
  Name --> V2["version-B"]
  Name --> Cur["current -> active version"]
  Name --> Prev["previous -> last known good"]
Loading

Atomic update flow

stateDiagram-v2
  [*] --> Download
  Download --> Verify
  Verify --> Unpack
  Unpack --> Activate
  Activate --> Success
  Success --> [*]

  Verify --> Fail
  Unpack --> Fail
  Activate --> Fail
  Fail --> Rollback
  Rollback --> Success
Loading

Main rule: if update fails, the current working version must still run.

6) Validation plan and hardware

Primary validation:

  • sim for reproducible end-to-end testing.

Hardware validation:

  • I will buy an LCD + network board.
  • Preferred target: stm32h745i-disco.

Hardware already available:

  • ESP32 DevKit v1 (extra network/update-path checks).
  • Raspberry Pi 5 (local build and HTTP demo repo hosting).
  • I will also coordinate validation with related ongoing distro/ELF efforts in the community so testing is not isolated.

7) Planned PR sequence

  1. Baseline ELF/shared-module validation (examples/elf, examples/sotest) with reproducible docs/configs.
  2. Reference app v1 and v2 for field update demo.
  3. Atomic install/update/rollback pipeline.
  4. Shared-library build support groundwork in NuttX/NuttX-Apps.
  5. Library loading MVP (one library + one dependent app).
  6. End-to-end integration script and docs for sim.

8) Success criteria

  • ELF baseline is reproducible on current mainline.
  • v1 -> v2 update works on sim and hardware target.
  • rollback restores last working version.
  • one packaged shared library + dependent app runs.
  • Makefile/CMake integration is documented and reproducible.

9) Feedback request

Please confirm if this revised scope looks right:

  1. Native minimal pkg MVP first (instead of full ppkg port).
  2. Validation strategy: sim + purchased stm32h745i-disco, with extra ESP32 DevKit v1 checks.

@acassis @halyssonJr @michallenc

References

Verification

  • I have verified before submitting the report.

Activity

  1. aviralgarg05
    added
    Community: QuestionFurther information is requested
    on Feb 11, 2026

  2. michallenc commented on Feb 11, 2026

    @michallenc
    michallenc
    on Feb 11, 2026
    Contributor

    @acassis

  3. acassis commented on Feb 11, 2026

    @acassis
    acassis
    on Feb 11, 2026
    Contributor

    @aviralgarg05 I think the scope is well defined, but seems there is too much AI generated data. Remember that you will need to create a proposal to GSoC, so it is better to understand the steps and create a document by yourself.

    In #17351 we proposal to use the existing ppkg project to implement the package management, but of course you can create a new pkg mngt as proposed here. Just evaluate the pros and cons of each approach.

    For pkg commands, I suggest to use opkg and apt as reference: pkg search, pkg install, etc. ("pkg run" is really strange).

    I think you highlighted the most important points, just some other details to keep in mind:

    • the distro should be a solution totally integrated into our build system, than an external distro. The idea is that using NuttX anyone can enable the right commands and create their own "distro". (So keep in mind Makefile and CMake compatibility)

    • I liked the idea of using sim for testing/validation, it simplifies tests and allow everybody to test the distro, but I think we need to have a candidate board as real target. This board should have a LCD screen and network compatibility. A good candidate should be stm32h74[5,7]i-disco (it has good driver support, LCD, Audio, Network, etc), ESP32-S3 (like https://aliexpress.com/item/1005007203795807.html it has LCD and WiFi, but this board needs to be added to mainline).

    @michallenc @halyssonJr @raiden00pl @xiaoxiang781216 any other suggestion?

  4. halyssonJr commented on Feb 12, 2026

    @halyssonJr
    halyssonJr
    on Feb 12, 2026
    Contributor

    @acassis, great suggestions.
    Considering the proposed roadmap, it's important to delegate some resources to each other and see how that can work. At the moment, we have different projects related to the NuttX distribution, and we need to test them together, for example, @liamHowatt creates and synthesizes an ELF file from scratch.

    @aviralgarg05, I liked your roadmap, the details are super important.

  5. aviralgarg05 commented on Feb 16, 2026

    @aviralgarg05
    aviralgarg05
    on Feb 16, 2026
    ContributorAuthor

    Thanks again for the feedback on this proposal.

    I’ve revised the issue body (Proposal V2) and tried to keep it more focused and practical.

    What I changed:

    • Tightened scope to the 3 NUTTX-20 goals.
    • Switched CLI plan to familiar package-manager commands (search/install/update/remove/list/rollback).
    • Removed pkg run from the main command set.
    • Made Makefile + CMake integration an explicit core requirement.
    • Kept ppkg as reference, and proposed a minimal native pkg MVP first.
    • Clarified validation plan: sim first, plus purchased LCD+network board (stm32h745i-disco preferred), and ESP32 DevKit v1 for extra network/update checks.

    If this direction looks right, I’ll use this scope for the final GSoC proposal draft.
    @acassis

  6. acassis commented on Feb 16, 2026

    @acassis
    acassis
    on Feb 16, 2026
    Contributor

    Thanks again for the feedback on this proposal.

    I’ve revised the issue body (Proposal V2) and tried to keep it more focused and practical.

    What I changed:

    * Tightened scope to the 3 NUTTX-20 goals.

* Switched CLI plan to familiar package-manager commands (`search/install/update/remove/list/rollback`).

* Removed `pkg run` from the main command set.

* Made Makefile + CMake integration an explicit core requirement.

* Kept `ppkg` as reference, and proposed a minimal native `pkg` MVP first.

* Clarified validation plan: `sim` first, plus purchased LCD+network board (`stm32h745i-disco` preferred), and ESP32 DevKit v1 for extra network/update checks.

    If this direction looks right, I’ll use this scope for the final GSoC proposal draft. @acassis

    Sounds good for me! Please go ahead!

  7. halyssonJr commented on Feb 16, 2026

    @halyssonJr
    halyssonJr
    on Feb 16, 2026
    Contributor

    Hey folks,
    I got a clear reproduction of the shared object on NuttX. I'm using the Linum Board.

  8. tmedicci commented on Feb 19, 2026

    @tmedicci
    tmedicci
    on Feb 19, 2026
    Contributor

    Hi @aviralgarg05 ,

    Nice proposal!

    As @acassis , ESP32-S3 is better suited for ELF loading: ESP32 can only use its internal RAM to run code, which limits its capacity. I highly recommend using ESP32-S3 with 8/16MB PSRAM.

    Apart from that, the main purpose of this distribution seems to be to create a ready-to-use prototyping device where you can load dynamic applications without the need to re-flash the device. Please consider adding other languages (compiled or not) to the distribution: wasm and Python (which is supported on ESP32-S3) would be highly welcomed.

  9. aviralgarg05
    changed the title [-][Discussion] Create a NuttX Distribution with Dynamic Binary (ELF) Loading (350h)[/-] [+][Discussion]{GSoC 2026] Create a NuttX Distribution with Dynamic Binary (ELF) Loading (350h)[/+] on Mar 4, 2026
  10. aviralgarg05
    changed the title [-][Discussion]{GSoC 2026] Create a NuttX Distribution with Dynamic Binary (ELF) Loading (350h)[/-] [+][Discussion][GSoC 2026] Create a NuttX Distribution with Dynamic Binary (ELF) Loading (350h)[/+] on Mar 4, 2026

  11. aviralgarg05 commented on Mar 4, 2026

    @aviralgarg05
    aviralgarg05
    on Mar 4, 2026
    ContributorAuthor

    @halyssonJr thank you for sharing the Linum shared-object reproduction, sample repo, and debug output. This is very useful for me. I’ll include this flow in my baseline validation and align my shared-library test cases with it.

    @tmedicci thank you for the practical hardware guidance. I agree that ESP32-S3 with 8/16MB PSRAM is a better fit for ELF-heavy work than ESP32 DevKit v1. I will update my hardware plan accordingly and use ESP32-S3 as the primary ESP target.

    I’ll still keep sim as the main reproducible validation target, and keep one LCD+network board target (stm32h745i-disco) for end-to-end demo coverage.

    For wasm/Python: I really like this direction, but to keep the GSoC scope realistic, I think I should keep the NUTTX-20 core goals as must-have, and treat wasm/Python runtime support as stretch goals after install/update/rollback + library support are stable. Right @acassis ??

  12. acassis commented on Mar 4, 2026

    @acassis
    acassis
    on Mar 4, 2026
    Contributor

    @halyssonJr thank you for sharing the Linum shared-object reproduction, sample repo, and debug output. This is very useful for me. I’ll include this flow in my baseline validation and align my shared-library test cases with it.

    @tmedicci thank you for the practical hardware guidance. I agree that ESP32-S3 with 8/16MB PSRAM is a better fit for ELF-heavy work than ESP32 DevKit v1. I will update my hardware plan accordingly and use ESP32-S3 as the primary ESP target.

    I’ll still keep sim as the main reproducible validation target, and keep one LCD+network board target (stm32h745i-disco) for end-to-end demo coverage.

    For wasm/Python: I really like this direction, but to keep the GSoC scope realistic, I think I should keep the NUTTX-20 core goals as must-have, and treat wasm/Python runtime support as stretch goals after install/update/rollback + library support are stable. Right @acassis ??

    Yes, let's focus in the basics first, then we extend to more features

  13. acassis
    added
    gsoc2026
    on Mar 4, 2026

  14. acassis commented on Mar 10, 2026

    @acassis
    acassis
    on Mar 10, 2026
    Contributor

    @aviralgarg05 I suggest you to start aligning about the proposal with @halyssonJr he will be the mentor for this project

  15. aviralgarg05 commented on Mar 10, 2026

    @aviralgarg05
    aviralgarg05
    on Mar 10, 2026
    ContributorAuthor

    Thanks, @acassis.

    Sure, I’ll start aligning the proposal details with @halyssonJr from here.

    @halyssonJr I’d really like your input on the proposal direction before I finalize the GSoC draft. In particular, I want to make sure I’m taking the right approach on scope, validation plan, and the shared-library/runtime-loading part.

  16. acassis commented on Mar 17, 2026

    @acassis
    acassis
    on Mar 17, 2026
    Contributor

    @aviralgarg05 please procedure with the official GSoC candidature: https://summerofcode.withgoogle.com/programs/2026

  17. acassis commented on Apr 1, 2026

    @acassis
    acassis
    on Apr 1, 2026
    Contributor

    Please confirm if you submitted the proposal before the deadline yesterday?

  18. aviralgarg05 commented on Apr 1, 2026

    @aviralgarg05
    aviralgarg05
    on Apr 1, 2026
    ContributorAuthor

    Please confirm if you submitted the proposal before the deadline yesterday?

    Yes, The Proposal has been submitted to Apache Software Foundation for GSoC 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Community: QuestionFurther information is requestedgsoc2026

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions