On Wed, Feb 25, 2026 at 02:34:05PM +0000, Daniel Golle wrote: > On Tue, Feb 24, 2026 at 11:24:44AM -0600, Tom Rini wrote: > > On Tue, Feb 24, 2026 at 11:57:23AM +0000, Daniel Golle wrote: > > > On Mon, Feb 23, 2026 at 01:32:19PM -0600, Tom Rini wrote: > > > > On Tue, Feb 17, 2026 at 11:46:17AM -0600, Tom Rini wrote: > > > > > 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. > > > > > > > > Following up on this part I suppose, I see in CI you're working on v2 > > > > but please make sure to follow up with the other outstanding questions > > > > I've asked before posting that. Thanks! > > > > > > I've carefully reiterated over all your emails regarding the series and > > > my replies to them. Apart from your request to share an image making use > > > of the proposal to include dm-verity parameters in uImage.FIT (and use > > > the presence to decide whether has varifications of that subimage may be > > > skipped) I haven't found anything which hasn't been answered. But maybe > > > I missed something, of course. > > > > There's: > > Thanks for digging all of them out. I took the freedom to answer all of > them here as it makes it easier to keep track of all the topics being in > a single thread. > > > https://lore.kernel.org/u-boot/20260217150820.GB2747538@bill-the-cat/ > > And I see you're using CI, but I didn't see an ack about the size > > investigations portion. > > I had to remove the -E (errors-as-warnings) option from the script > because my host toolchain is too new and caused a few warnings about > discarded 'const' qualifiers. Most can be fixed by updating dtc to > that in upstream Linux, the other one is in > tools/atmelimage.c:64:31: error: assignment discards ‘const’ qualifier > from pointer target type [-Werror=discarded-qualifiers] > and can also be fixed easily. I'll post the patch for that after I > send this email. > > Updating dtc, however, caused a cascade of new warnings in existing > device tree files, newly introduce node-name checks, ... so at that > point I decided to just remove the -E option passed from the script > to buildman... > > Results: > For any board having CONFIG_FIT enabled but none of the new features > there is a slight increase: > aarch64: (for 1/1 boards) all +8.0 text +8.0 > mt7622_rfb : all +8 text +8 > u-boot: add: 0/0, grow: 1/0 bytes: 8/0 (8) > function old new > delta > fit_image_load 1632 1640 > +8 > > The increase by 8 bytes is caused by this hunk: > --- a/boot/image-fit.c > +++ b/boot/image-fit.c > @@ -2279,8 +2362,9 @@ int fit_image_load(struct bootm_headers *images, ulong > addr, > return -EXDEV; > } > > - printf(" Loading %s from 0x%08lx to 0x%08lx\n", > - prop_name, data, load); > + if (data != load) > + printf(" Loading %s from 0x%08lx to 0x%08lx\n", > + prop_name, data, load); > } else { > load = data; /* No load address specified */ > } > > It could obviously also be guarded by some > if (!CONFIG_IS_ENABLED(IMAGEMAP) || data != load) > so the compiler would end up with byte-identical code in case > CONFIG_IS_ENABLED(IMAGEMAP) is false. > Do you think that'd be worth it?
So 8 byte growth here is fine, it would be more unreadable to avoid that than to accept it, and 8 bytes is nothing really. > Enabling the new features for the BanananPi R3 required also enabling > CONFIG_FIT which previously wasn't selected for that board. > With all the new options (CONFIG_FIT, all imagemap backends, OpenWrt > bootmeth): > aarch64: (for 1/1 boards) all +47701.0 data +848.0 rodata +5001.0 text > +41852.0 > mt7986a_bpir3_emmc: all +47701 data +848 rodata +5001 text +41852 > u-boot: add: 142/0, grow: 22/-1 bytes: 27785/-4 (27781) > function old new > delta > MD5Transform - 2528 > +2528 > fit_image_load - 1980 > +1980 > fit_print_contents - 1228 > +1228 > fit_verity_build_params - 948 > +948 > fit_image_print - 780 > +780 > cmdline_set_arg - 688 > +688 > imagemap_map - 640 > +640 > bootmeth_vbe_ft_fixup - 640 > +640 > bootm_run_states 1908 2436 > +528 > fit_image_verify_with_data - 520 > +520 > openwrt_boot - 516 > +516 > sha256_finish - 404 > +404 > image_locate_script 272 668 > +396 > boot_get_fdt_fit - 396 > +396 > fit_image_print_data - 392 > +392 > boot_get_loadable - 384 > +384 > fdt_check_full - 332 > +332 > bootm_help_text 910 1234 > +324 > sha1_finish - 300 > +300 > bootflow_scan_next 424 724 > +300 > bootmeth_vbe_simple_ft_fixup - 288 > +288 > hash_command 188 468 > +280 > hash_algo - 280 > +280 > fit_all_image_verify - 272 > +272 > bootmeth_vbe_simple_probe - 264 > +264 > MD5Update - 260 > +260 > do_imgextract 668 924 > +256 > boot_get_fdt 592 848 > +256 > static.sha1_update - 240 > +240 > boot_get_ramdisk 480 720 > +240 > static.CSWTCH 139 371 > +232 > copy_in - 228 > +228 > fit_image_get_data - 224 > +224 > static.sha256_update - 220 > +220 > fit_conf_get_node - 216 > +216 > imagemap_map_to - 212 > +212 > openwrt_read_bootflow - 204 > +204 > fit_conf_get_prop_node - 192 > +192 > MD5Final - 188 > +188 > imagemap_record - 180 > +180 > imagemap_create - 176 > +176 > fit_image_print_verification_data - 176 > +176 > source_help_text 40 212 > +172 > event_notify - 168 > +168 > vbe_simple_fixup_node - 164 > +164 > bootflow_cmdline_set_arg - 164 > +164 > fit_check_format - 152 > +152 > vbe_get_blk - 148 > +148 > vbe_read_nvdata - 140 > +140 > ofnode_add_subnode - 140 > +140 > imagemap_cleanup - 136 > +136 > fit_image_verify - 136 > +136 > fit_image_get_address - 136 > +136 > ofnode_copy_props - 120 > +120 > boot_get_setup_fit - 120 > +120 > _u_boot_list_2_uclass_driver_2_imagemap - 120 > +120 > _u_boot_list_2_driver_2_vbe_simple - 120 > +120 > _u_boot_list_2_driver_2_bootmeth_openwrt - 120 > +120 > next_glob_bootmeth - 116 > +116 > fit_parse_subimage - 116 > +116 > fit_parse_conf - 116 > +116 > calculate_hash - 116 > +116 > vbe_simple_get_state_desc - 112 > +112 > sha1_csum_wd - 112 > +112 > ofnode_write_prop - 112 > +112 > imagemap_lookup - 112 > +112 > hash_lookup_algo - 112 > +112 > vbe_simple_read_state - 100 > +100 > vbe_read_version - 100 > +100 > vbe_find_first_device - 96 > +96 > uimage_phase - 96 > +96 > ofnode_write_u32 - 96 > +96 > md5_wd - 96 > +96 > genimg_get_kernel_addr_fit 24 120 > +96 > imgextract_help_text 85 178 > +93 > board_init_r 572 664 > +92 > vbe_find_next_device - 88 > +88 > simple_read_nvdata - 88 > +88 > sha256_starts - 88 > +88 > fit_get_node_from_config - 88 > +88 > bootmeth_get_bootflow - 88 > +88 > bootflow_check - 88 > +88 > bootmeth_setup_iter_order 284 368 > +84 > bootmeth_glob_allowed - 84 > +84 > board_init_f 1168 1252 > +84 > image_info 208 288 > +80 > get_table_entry_id - 80 > +80 > fit_image_hash_get_value - 80 > +80 > fit_image_get_emb_data - 80 > +80 > fit_image_get_type - 76 > +76 > fit_image_get_phase - 76 > +76 > fit_image_get_os - 76 > +76 > fit_image_get_arch - 76 > +76 > bootflow_cmdline_set - 76 > +76 > sha256_csum_wd - 72 > +72 > fit_image_get_node - 72 > +72 > fit_image_get_data_size - 72 > +72 > fit_image_get_data_position - 72 > +72 > fit_image_get_data_offset - 72 > +72 > fit_image_get_comp - 68 > +68 > vbe_reqs - 64 > +64 > sha256_padding - 64 > +64 > sha1_padding - 64 > +64 > image_setup_libfdt 344 408 > +64 > hash_finish_sha256 - 64 > +64 > hash_finish_sha1 - 64 > +64 > fit_image_check_type - 60 > +60 > fit_image_check_os - 60 > +60 > fit_image_check_comp - 60 > +60 > fit_conf_get_prop_node_index - 60 > +60 > do_source 84 144 > +60 > crc32_wd_buf - 60 > +60 > crc16_ccitt_wd_buf - 60 > +60 > sha1_starts - 56 > +56 > openwrt_bootmeth_ops - 56 > +56 > oftree_path - 56 > +56 > ofnode_write_string - 56 > +56 > hash_finish_crc32 - 56 > +56 > hash_finish_crc16_ccitt - 56 > +56 > fit_image_hash_get_algo - 56 > +56 > fit_get_desc - 56 > +56 > bootmeth_vbe_simple_ops - 56 > +56 > hash_update_crc32 - 52 > +52 > hash_update_crc16_ccitt - 52 > +52 > hash_init_sha256 - 52 > +52 > hash_init_sha1 - 52 > +52 > crc8 - 52 > +52 > hash_init_crc32 - 48 > +48 > hash_init_crc16_ccitt - 48 > +48 > alist_uninit - 48 > +48 > openwrt_bootmeth_bind - 44 > +44 > bootmeth_vbe_simple_bind - 44 > +44 > openwrt_check - 36 > +36 > imagemap_post_probe - 36 > +36 > hash_update_sha256 - 36 > +36 > hash_update_sha1 - 36 > +36 > vbe_simple_read_file - 32 > +32 > openwrt_bootmeth_ids - 32 > +32 > generic_simple_vbe_simple_ids - 32 > +32 > bootflow_scan_first 236 264 > +28 > genimg_get_type_id - 24 > +24 > genimg_get_phase_name - 24 > +24 > genimg_get_phase_id - 24 > +24 > genimg_get_os_id - 24 > +24 > genimg_get_comp_id - 24 > +24 > genimg_get_arch_id - 24 > +24 > fit_image_get_load - 16 > +16 > fit_image_get_entry - 16 > +16 > fit_get_end - 16 > +16 > bootm_find_images 268 284 > +16 > > _u_boot_list_2_evspy_info_2_EVT_FT_FIXUP_3_bootmeth_vbe_simple_ft_fixup > - 16 +16 > > _u_boot_list_2_evspy_info_2_EVT_FT_FIXUP_3_bootmeth_vbe_ft_fixup - > 16 +16 > sha256_update - 12 > +12 > sha1_update - 12 > +12 > genimg_get_kernel_addr 20 32 > +12 > event_type_name - 12 > +12 > event_notify_null - 12 > +12 > vbe_simple_read_bootflow - 8 > +8 > vbe_req_random_seed - 8 > +8 > vbe_req_efi_runtime_rand - 8 > +8 > vbe_req_aslr_rand - 8 > +8 > vbe_req_aslr_move - 8 > +8 > oftree_root - 8 > +8 > genimg_has_config 8 16 > +8 > boot_get_setup 8 4 > -4 > > This seems excessive, but it's mostly due to CONFIG_FIT not being enabled > in the upstream U-Boot defconfig for the BananaPi R3. > > With CONFIG_FIT enabled already before, the changes are more reasonable: > aarch64: (for 1/1 boards) all +6057.0 data +296.0 rodata +513.0 text > +5248.0 > mt7986a_bpir3_emmc: all +6057 data +296 rodata +513 text +5248 > u-boot: add: 21/0, grow: 3/0 bytes: 5336/0 (5336) > function old new > delta > fit_verity_build_params - 948 > +948 > cmdline_set_arg - 688 > +688 > imagemap_map - 640 > +640 > openwrt_boot - 516 > +516 > fit_image_load 1632 1980 > +348 > copy_in - 228 > +228 > imagemap_map_to - 212 > +212 > openwrt_read_bootflow - 204 > +204 > imagemap_record - 180 > +180 > bootm_run_states 2256 2436 > +180 > imagemap_create - 176 > +176 > bootflow_cmdline_set_arg - 164 > +164 > imagemap_cleanup - 136 > +136 > _u_boot_list_2_uclass_driver_2_imagemap - 120 > +120 > _u_boot_list_2_driver_2_bootmeth_openwrt - 120 > +120 > imagemap_lookup - 112 > +112 > bootflow_cmdline_set - 76 > +76 > openwrt_bootmeth_ops - 56 > +56 > alist_uninit - 48 > +48 > openwrt_bootmeth_bind - 44 > +44 > openwrt_check - 36 > +36 > imagemap_post_probe - 36 > +36 > fit_image_get_data 188 224 > +36 > openwrt_bootmeth_ids - 32 > +32 Adding 5K or so isn't unreasonable, but I'd still suggest looking around to see if there's any easy optimizations. > > There's: > > https://lore.kernel.org/u-boot/20260217192000.GH2747538@bill-the-cat/ > > And I didn't see anything about that. > > Re: boot: add OpenWrt boot method and on-demand FIT loading > > (Re: not enabled on any board nor in sandbox) > In my new series I'll add the OpenWrt One as a sample board and also > enable the new features on the BananaPi R3. OK, thanks. > Should I also enable the imagemap base feature in sandbox as well so the > unit tests can easily be run? Absolutely. > (Re: splitting series) > There aren't any actual fixes part of the series. Of course, some > smaller changes and refactoring to create the helpers needed by > imagemap and the bootmeth could be broken out as indidivual patches > sent separately in advance, but they wouldn't have any in-tree users > at this point. Eg. > - mtd: set flash_node on DT-created partitions > - mtd: add mtd_read_skip_bad() helper > - cmd: ubi: add ubi_part_from_mtd() > - cmd: ubi: export ubi_find_volume() Maybe I'm mis-recalling but some of the changes seemed to be worded / implied they were fixing existing problems, not adding things to be used later. But also, those changes should have some impact on size growth? To make sure to look at other platforms as well. The goal is not zero growth, but rather explainable growth. I'm not asking you to do the world before/after that I do, but making use of qconfig.py -f CONFIG_FOO to find boards that enable code you're changing and then checking them and seeing if it's tens of bytes or hundreds of bytes of growth on something unsupported (and likely never supported) by OpenWrt is important. > I also think it makes sense to discuss the new feature (not part of the > original RFC series) to store dm-verity parameters for IH_TYPE_FILESYSTEM > subimages in the FIT structure separately, and that would start with > discussing the FIT spec amendment for it: > > https://github.com/open-source-firmware/flat-image-tree/pull/37 Yes, that's a separate discussion. > > There's: > > https://lore.kernel.org/u-boot/20260217190554.GF2747538@bill-the-cat/ > > Re: test: boot: add image_loader unit tests > (Re: AI fixes in the wrong commit) > Yes, this was an oversight and I've of course folded in that change, > and later, upon Simon's comment, switched to use alist instead of a > fixed-size array anyway. > > https://lore.kernel.org/u-boot/20260219153100.GL3233182@bill-the-cat/ > > Which go together and I think "human written only commit message" might > > well be a good policy as it helps ensure the patch in question has been > > read and summarized by the human author (and enforcement is on the > > honor system). > > While it was very useful to use an LLM for quickly drafting the intial > RFC and receive feedback for the overall approach, it became less and > less useful at later stages -- instead of ending of micro-managing the > LLM for each little change and fix it's easier to just do it yourself > from some point on. > > So what you are going to see in v2 surely still got some onchanged lines > of code, comments and parts of commit messages which have intially been > fabricated with the help of the LLM, but most of it is by now the work > of a human (me). OK. > Regarding the commit messages, I get the idea of enforcing a > human-written message, however, when it comes to the use of English > language (I'm not a native speaker) I think the use of things like > deepl.com does create more benefit than potential damage even though it > can also be considered an AI/LLM tool. This is a project that was started by Germans and initially contributed to by other Europeans and has an extremely long history of global and non-native-English speakers contributing, I would much rather see some imperfect English than overly polished and often useless LLM messages. It is sometimes joked that LLMs speak great Manager-English, but that's not what we want here. > > Finally there's: > > https://lore.kernel.org/u-boot/20260217191536.GG2747538@bill-the-cat/ > > where I was hoping for more feedback. > Re: reuse imageloader (by now renamed to "imagemap") in SPL > > First of all, I don't have any boards which use SPL. All modern > platforms I deal with use U-Boot as "Non-Trusted Firmware (BL33)" or > the OpenSBI equivalent of that on platforms using RISC-V. > > Especially regarding the UBI part, the implementation intended for SPL > is way too basic to be useful as imagemap backend. > > For BLK (ie. MMC) or SPI-NOR it would be a possibility to reuse > imagemap in SPL -- but (as I've replied earlier) I don't think it > makes sense to merge it with the exising FIT reader in SPL for the > reasons I've explained: > |> So there really isn't much overlap other than the fact that there is a > |> struct with a priv pointer and a .read callback, and even that uses a > |> different addressing parameter (sectors vs. bytes). You should go back in to that thread, so the other interested parties see this as well and also keep in mind that you're adding something that may be useful in other cases, not that you should use what we have today instead. Especially for the cases where people are trying to add less-basic support in SPL for various flashes. > > I don't recall if we came to a conclusion, or just look again later, > > about if we should have this functionality both exposed via "bootm" and > > the new distro bootmeth, or not. It might be "talk more" and I'm leaning > > currently on saying the migration path is something openwrt holds > > downstream while getting things migrated? > > That's also what I understood from our discussion. Adding new cmdline > features to 'bootm' can be considered a liability, so I've dropped that > from the v2 series and only use the direct-storage FIT loading in > bootmeth_openwrt. We can still add the 'bootm' features as an > intermediate step to easy migration of all our boards as downstream > patch (and later remove it again once all boards and features work with > the bootmeth). OK, thanks. > > And in sum, this series will need to be split up a bit I strongly > > suspect. Being clear about the end goal is good but implementing each of > > the backends as well in a single series will make this too large to > > review. > > The current state of the series looks pretty much like what I've pushed > to Github for the sake of getting CI exposure. I don't look at all the emails it generates and sends to me, but it was 20 commits at least? > Do you agree with the submission strategy drafted below? > > Commits (reverse git order, starting from the one directly > on top of u-boot.git master branch, ie. in the order of > the patches to be submitted starting with the first to be > sent). > > SERIES 1: dm-verity paramters for FIT images > > - boot: fit: support generating DM verity cmdline parameters > - doc: fit: add dm-verity boot parameter documentation > > To be discussed together with > https://github.com/open-source-firmware/flat-image-tree/pull/37 This is a stand-alone thing yes, and should wait for that discussion to be resolved / merged. > --- > SERIES 2: imagemap storage abstraction > > - boot: add imagemap on-demand loading abstraction > - boot: imagemap: add block device backend > - doc: imagemap: document on-demand loading framework > - test: boot: add imagemap unit tests > > This would be a meaningful series together with enabling imagemap > in sandbox so the unit tests are run there. > --- > SERIES 3: imagemap MTD and UBI backends > > - mtd: add mtd_read_skip_bad() helper > - boot: imagemap: add MTD backend > - mtd: set flash_node on DT-created partitions > - cmd: ubi: export ubi_find_volume() > - cmd: ubi: add ubi_part_from_mtd() > - boot: imagemap: add UBI volume backend > > This would be one or two small series adding the backends. > Maybe including another commit completing the documentation > to cover the newly added backends. > --- > single PATCH > > - boot: fit: support on-demand loading in fit_image_load() > > This would be good to be discussed individually as it is > the most intrusive change and needs the most eyeballs. > --- > SERIES 4: OpenWrt boot method > > - boot: bootmeth: add OpenWrt boot method skeleton > - boot: bootmeth: openwrt: implement read_bootflow > - boot: bootmeth: openwrt: implement boot via imagemap > - boot: bootdev: add MTD boot device > - boot: bootdev: add UBI boot device > - doc: bootstd: add OpenWrt boot method documentation > - board: mediatek: add OpenWrt One support > - mt7986a-bpi-r3: add OpenWrt boot method This kind of split doesn't help with review because series 2, 3 and 4 have to be seen as a whole for them to be useful and understood. It had sounded like earlier there was support for block devices (eMMC/SD for example) but that's not included yet? I was going to suggest excluding them, or just including the smallest backend support to start with, and follow-up with other backends. So I'd rather see 2, 3 and 4 as a single series than split up, so that it's possible to understand real usage. Thanks. -- Tom
signature.asc
Description: PGP signature
