Kernel/image compile question: (denx,uimage splitting)

I checked here among other places while looking for specific answers to these questions:

1: When I set Kernel modules as MODULES and not compiled into the Kernel <*>, where do the modules go (in the file-system)? Are they in the init ramfs, separate from the kernel? I know they're in e.g. /lib/modules/4.14.134/ but does this win savings in the kernel (lzma of vmlinux) image?

I need to slim my kernel down, so I can build a factory.bin (for other users with this device). At least for initial install. Because the target device has a kernel partition of exactly....

0x120000
or
1179648 bytes

I can currently get between 1.2-1.4MB depending on how I play with options make menuconfig which are already close to the bone. make kernel_menuconfig doesn't seem to win me much except for headaches.

Some tricks here and here were helpful

2: Is mtd re-partitioning a thing? My google-fu is turning up nada... I know what re-partitioning entails, but... possible? There's lots of firmware space that would be better suited to the kernel.

Modules, as far as I know, get wrapped as packages and not installed.

MTD isn’t partitioning like a GPT/MBR. Nothing is on the flash, it’s all about how the kernel and drivers interpret the bits. Yes, can be done for high-level data. Much more challenging to move the kernel start address, nearly impossible to move the boot loader.

Using an initramfs, non-persisted image is one way to transition to a different layout.

If the flash layout is easy, rootfs immediately after kernel, enlarging kernel partition size could be rather straightforward. If the partition order is different, then it might be more problematic.

Example (enlarging R7800 kernel size in DTS):
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=dc50694bd1a8f81b40c185bc8cacbdc8e821a3c6;hp=7ac6697fe269e7915e2dd55ba872cffcc102338b

It of course depends on, where paritions are defined. In DTS, or somewhere else.

Cool! Well, the DTS changes there seem simple enough. But this I can only do after I've built a slimmed down Kernel (throwing out almost everything, except networking).

I can live without moving the kernel start address. I assume this is challenging as we'd need to update the on-device uboot to know about these changes. But as long as kernel start is the same, everything else just.... works?

My DTS partitions are:

                partitions {
                        compatible = "fixed-partitions";
                        #address-cells = <1>;
                        #size-cells = <1>;

                        partition@0 {
                                label = "u-boot";
                                reg = <0x0 0x30000>;
                                read-only;
                        };

                        partition@30000 {
                                label = "u-boot-env";
                                reg = <0x30000 0x10000>;
                        };

                        factory: partition@40000 {
                                label = "factory";
                                reg = <0x40000 0x10000>;
                                read-only;
                        };

                        firmware: partition@50000 {
                                compatible = "denx,uimage";
                                label = "firmware";
                                reg = <0x50000 0x7b0000>;
                        };

Thanks to @jeff I understand that OWRT slices up the firmware partition how it wants. The OEM firmware detects the following so I reckon the ordering is conducive to re-partitioning:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00800000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 00120000 00010000 "Kernel"
mtd5: 00690000 00010000 "RootFS"
mtd6: 00010000 00010000 "EDINVRAM"
mtd7: 00010000 00010000 "EDIENVRAM"

This device at least looks promising for wider use, despite being only 8MB flash and 64MB RAM.

Hmm... how to make things not in the kernel, and available not in the kernel image, but the ramfs image so they can be loaded a short while later? Like use kernel to get basic init, and fs layers going, then plug in modules to get extra hardware support.

That looks simple enough as (your?) DTS handles them as one large partition and the structure is kernel + rootfs. However, that does not show how the "denx,uimage" gets split to kernel and rootfs. Normally I would expect there to be items about it in DTS, but apparently not ???

You also claimed earlier this:

...and I see no evidence of that in DTS.

There are apparently other rules somewhere else about handling the special "denx,uimage" partition's internal structure...
(I modified the thread title to reflect that the special thing here is the denx,uimage)

Correct, at least not in the DTS I posted, I'm talking about the OEM (ZyXEL) firmware. MY DTS is more basic (just 4 partitions).

I need to follow OEM so I can build factory which will fit a kernel in that space for initial install. Then once the flood-gates are open.... go nuts with kernel modules :slight_smile:

Edit: Judging by the git link - looks like I'll need to supply that, for a more long-term working owrt sysupgrade.

Is it possible in the e.g. mt7620.mk file to specify that factory.bin gets only certain kernel modules, while a sysupgrade.bin gets another set? How do we go about doing that?

I don't see how yet, if kernel modules necessary are under DEVICE_PACKAGES