[RFC PATCH 00/20] boot: add OpenWrt boot method and on-demand FIT loading

[Tom Rini]

On Mon, Feb 16, 2026 at 09:21:14PM +0000, Daniel Golle wrote:

> Hi all,
> 
> This RFC series adds a new boot method for OpenWrt's "uImage.FIT with
> embedded rootfs" firmware model, along with the underlying infrastructure
> to load FIT images on-demand directly from storage devices without copying
> them entirely to RAM first.
[snip]
> AI tool disclosure
> ==================
> 
> Major parts of this series were developed with assistance from GitHub
> Copilot (Claude Opus 4.6, Anthropic). The AI was used as a coding
> partner for scaffolding boilerplate, drafting documentation and commit
> messages, running checkpatch sweeps, and iterating on review feedback.
> All architectural decisions, U-Boot subsystem integration, hardware
> testing, and final review were done by the human author. Every line of
> code was reviewed and tested on real hardware before inclusion.

First, I appreciate your honesty and explanation in the disclosure here.

This topic comes up, and will keep coming up, and as a project we have
not yet decided on a position. I know that the Linux Kernel has come up
with:
https://docs.kernel.org/next/process/generated-content.html
so far. But I think that:
https://docs.postmarketos.org/policies-and-processes/development/contributing-and-ai.html
brings up points that are quite relevant too. Absolutely no one has been
happy with when gitlab or patchwork were unusable / unreachable (and for
some people are still unusable) but it's because of all the AI scrapers
that things were unusable or now have anubis in front of them (blocking
other humans now).

With that said, I want to stress the "human is responsible" portion of
what both links say, and that given where exactly these changes are
aimed for, extra scrutiny is required. Things like:
https://cyberplace.social/@GossiTheDog/116080909947754833
show just how bad they are about introducing security bugs these days.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260217/399ebdf9/attachment.sig>