Thread (29 messages) 29 messages, 5 authors, 2025-12-11

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

From: Thomas Weißschuh <hidden>
Date: 2025-12-02 10:31:55
Also in: linux-kbuild, lkml

On Wed, Nov 26, 2025 at 12:26:49PM +0100, Ahmad Fatoum wrote:
On 11/26/25 8:16 AM, Thomas Weißschuh wrote:
quoted
On Tue, Nov 25, 2025 at 02:58:12PM -0700, Simon Glass wrote:
quoted
On Thu, 20 Nov 2025 at 00:49, Thomas Weißschuh
[off-list ref] wrote:
quoted
On Wed, Nov 19, 2025 at 11:13:27AM -0700, Simon Glass wrote:
(...)
quoted
quoted
quoted
 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.
quoted
quoted
quoted
              $(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.
quoted
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.

(...)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help