[PATCH v6 6/8] kbuild: Allow adding modules into the FIT ramdisk

Simon Glass sjg at chromium.org
Thu Dec 11 05:31:43 PST 2025


Hi Thomas,

On Tue, 2 Dec 2025 at 03:31, Thomas Weißschuh
<thomas.weissschuh at linutronix.de> wrote:
>
> On Wed, Nov 26, 2025 at 12:26:49PM +0100, Ahmad Fatoum wrote:
> > On 11/26/25 8:16 AM, Thomas Weißschuh wrote:
> > > On Tue, Nov 25, 2025 at 02:58:12PM -0700, Simon Glass wrote:
> > >> On Thu, 20 Nov 2025 at 00:49, Thomas Weißschuh
> > >> <thomas.weissschuh at linutronix.de> wrote:
> > >>>
> > >>> On Wed, Nov 19, 2025 at 11:13:27AM -0700, Simon Glass wrote:
> > >
> > > (...)
> > >
> > >>>>  quiet_cmd_fit = FIT     $@
> > >>>>        cmd_fit = $(MAKE_FIT) -o $@ --arch $(UIMAGE_ARCH) --os linux \
> > >>>> -             --name '$(UIMAGE_NAME)' \
> > >>>> +             --name '$(UIMAGE_NAME)' $(MAKE_FIT_FLAGS) \
> > >>>
> > >>> Remnant of a previous revision?
> > >>
> > >> The flags are there to allow extra options to be passed if needed.
> > >
> > > Are they necessary for the module functionality added here?
> > > If not I'd put them into a dedicated commit.
> > >
> > >>>
> > >>>>               $(if $(findstring 1,$(KBUILD_VERBOSE)),-v) \
> > >>>>               $(if $(FIT_DECOMPOSE_DTBS),--decompose-dtbs) \
> > >>>> +             $(if $(FIT_MODULES),--modules @$(objtree)/modules.order) \
> > >>>
> > >>> I am wondering how module dependencies work without the depmod invocation
> > >>> and modules.dep file.
> > >>
> > >> We have a mechanism to place a pre-build initrd with the filesystem,
> > >> etc. into the FIT. But for this particular feature (suggested by Ahmad
> > >> Fatoum) we are just providing the raw modules. Presumably another
> > >> initrd would be needed to provide the startup files?
> > >
> > > modules.dep is more than optional and generic startup files but an integral
> > > part of a module tree. Without it, any module depending on another module's
> > > symbols will fail to load. Also the modules will be unsigned, potentially
> > > making them unloadable.
> >
> > I'll use the occasion to elaborate a bit on why I thought adding modules
> > is a good idea.
> >
> > - You have a system boot from FIT and maybe even a r/o rootfs
> > - You want to boot a different kernel without any userspace changes,
> > e.g. to bisect
> > - Fortunately, you have a build target that generates you a FIT with
> > kernel, enabled device trees and all modules (including deps and such)
> > - In the bootloader[1], you specify that a CPIO with a minimal init[2]
> > that bindmounts /lib/modules in the initramfs over the rootfs modules
> > before pivot_root
> >
> > and that's it, you are running your new kernel with the old rootfs
> > unchanged. I believe this would be really handy, which is why I
> > suggested it.
>
> The idea sounds good.
>
> > > Ahmad's patch does produce a complete and fully
> > > functional module tree by means of 'make headers_install'.
> >
> > I originally thought that we could generate the CPIO normally as part of
> > the kernel build and then we can readily depend on it in the rule that
> > invokes make_fit.py.
>
> That works, but it is not what the patch under discussion does, or did.
>
> > If this proves to be too cumbersome, I think it's already an improvement
> > if the user can manually run make modules-cpio-pkg and then make
> > image.fit with the initrd specified. A single target would be neater of
> > course, but I didn't intend for this to stall the series.
>
> The single target idea would require 'modules-cpio-pkg' to not be a PHONY
> target anymore but to properly track dependencies. Otherwise the CPIO and FIT
> image will be rebuilt even if no sources change. Proper dependencies are always
> better than PHONY targets, but it will be a bit of additional work.
>
> > It can always follow later.
>
> Yep. But for the patch as it is proposed I am still wondering how it will work
> without modules.dep and friends.
>
> (...)

I'm going to send a v7 and perhaps Ahmad can help to refine this.
Unfortunately the modules generation has turned into a significant
detour. We can either drop it, or continue to try to resolve this.

Regards,
SImon



More information about the linux-arm-kernel mailing list