Hi,

On 11/26/25 8:16 AM, Thomas Weißschuh wrote:

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.

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.

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.

It can always follow later.

[1]: For my particular usage, I intend to extend the barebox boot
override mechanism. Currently, it's possible to do:
barebox$ boot -o bootm.initrd=/mnt/tftp/my-ramdisk.cpio /mnt/tftp/my-fit
and I want to extend it to allow appending any number of CPIOs:
barebox$ boot -o bootm.initrd=":/mnt/tftp/my-init.cpio" /mnt/tftp/my-fit

[2]: The bind mount logic for the initramfs init will probably go into
https://github.com/pengutronix/rsinit, which I can compile once per
architecture, put into my TFTP srv path and then not have to worry about it.

Cheers,
Ahmad

quoted

quoted

quoted

              --compress $(FIT_COMPRESSION) -k $< @$(word 2,$^)

 # XZ
--
2.43.0

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |