Digging a bit more into the code I found the culprit

The function mtd_partition_split added by the patch 400-mtd-mtdsplit-support.patch

After finding first partition that is either named rootfs or have "linux,rootfs" property no matter if it is contained into a "super" partition named "firmware" or not, the function stops looking for partitions to split, so because second firmware partition is located after first it never get looked inside for split partitions. This code basically render impossible to have any form of "dual boot" in OpenWrt, because no matter what are the command line passed to the kernel from the bootloader, or what is inside de DTS the first and only partition with any of those two properties will be choosen as rootfs by the kernel.

Along with the code there is no comment indicating that this behavior is intentional, AFAIU the rootfs is always inside the "super-partition" called "firmware", if you can confirm my understanding is correct I can change the code so "dual boot" is supported again and submit a patch.


Cheers Gio


P.S. rafal as direct recipient because from git log you seems to be the last one to have made substantial changes to that part of the code ;)

On 2/5/24 17:26, Gio wrote:
Have tested a few changes based on your suggestion, all of them sadly failed:

1) Reset kernel settings to default + Remove the whole partitions block from librerouter dts, the image fails to be compile with an error of missing art label (probably because uno of the partitions have that label)


2) Reset kernel settings to default + Remove firmware and fw2 partitions from librerouter dts, the image build fine but at boot the commandline passed by the bootloader is completely ignored (because the default kernel config includes CONFIG_MIPS_CMDLINE_FROM_DTB)

3) Unset CONFIG_MIPS_CMDLINE_FROM_DTB and set CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER, at this point the commandline is onored but fails later because the partitions encapsulated inside firmare partitions are not "unpacked" same as I reported in the first email


Does the "automatic unpacking" have something to do with the `compatible = "denx,uimage";` line present on the DTS  which refer to the firmware partition?


Cheers

Gio


On 2/3/24 01:18, Isaev Ruslan wrote:
Try to remove your patch and just remove mtdparts from dts.

On Sat, Feb 3, 2024, 00:19 Gio <g...@diveni.re> wrote:

    Hi!

    librerouterOS used to be based on OpenWrt 19

    librerouterOS is basically plain OpenWrt plus safe-upgrade,

    safe-upgrade is a mechanism to flash an updated firmware to a second
    partition and mark it as testing, so if something goes wrong and user
    doesn't confirm everything is ok, after a while it reboot from the
    first
    partition, support for flashing a second partition and booting from
    there, to do this safe-upgrade basically does a bit of U-Boot
    trickery and

    pass to kernel command line

mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),7936k(firmware),7936k(fw2),128k(res),64k(ART)

    to boot from first partition, while

mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),7936k(fw1),7936k(firmware),128k(res),64k(ART)

    when booting from second partition

    OpenWrt 19 used to works perfectly with this trick, while with
    current
    development branch it boot perfectly from first partition but
    fails to
    boot from second :-/

    AFAIU now mtdparts are passed via DTS so I have been fiddling with
    kernel options to avoid the kernel reading from there as of today
    I do this


         # Avoid MTD partition table being read from Device Tree
    safe-upgrade need
         # to change it depending if we need to boot fw1 or fw2 so it
    uses
    kernel
         # command line to pass partition table
         kconfig_unset CONFIG_MTD_OF_PARTS

         # Disable kernel command line being read from device tree
    which is
    mutually
         # exclusive with reading it from boot loader
         # CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER
         kconfig_unset CONFIG_MIPS_CMDLINE_FROM_DTB

         # safe-upgrade need kernel command line to be generated
    dinamically
    by the
         # boot loader (U-Boot) depending on which partition (either
    fw1 or
    fw2) it
         # need to boot
         kconfig_set CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER

    and then pass the mtdparts to kernel command line via U-Boot, the
    result
    is that it keeps booting fine from first partition but it cannot find     root partition when booting from second partition, apparently at some
    point sub-MTD-partitions get detected when booting from fw1 while
    they
    are not when booting from fw2


    booting form first partition


    [    0.334007] spi-nor spi0.0: w25q128 (16384 Kbytes)
    [    0.338951] mtd: Found partition defined in DT for u-boot.
    Assigning
    OF node to support nvmem.
    [    0.338964] mtd: Found partition defined in DT for u-boot-env.
    Assigning OF node to support nvmem.
    [    0.347748] mtd: Found partition defined in DT for firmware.
    Assigning OF node to support nvmem.
    [    0.356859] mtd: Found partition defined in DT for res.
    Assigning OF
    node to support nvmem.
    [    0.365783] mtd: Found partition defined in DT for ART.
    Assigning OF
    node to support nvmem.
    [    0.374263] 6 cmdlinepart partitions found on MTD device spi0.0
    [    0.388733] Creating 6 MTD partitions on "spi0.0":
    [    0.393595] 0x000000000000-0x000000040000 : "u-boot"
    [    0.402035] 0x000000040000-0x000000050000 : "u-boot-env"
    [    0.408366] 0x000000050000-0x000000810000 : "firmware"
    [    0.416207] 2 uimage-fw partitions found on MTD device firmware
    [    0.422228] Creating 2 MTD partitions on "firmware":
    [    0.427307] 0x000000000000-0x000000240000 : "kernel"
    [    0.433243] 0x000000240000-0x0000007c0000 : "rootfs"
    [    0.440527] mtd: setting mtd4 (rootfs) as root device
    [    0.445792] 1 squashfs-split partitions found on MTD device rootfs
    [    0.452072] 0x000000690000-0x0000007c0000 : "rootfs_data"
    [    0.458570] 0x000000810000-0x000000fd0000 : "fw2"
    [    0.465664] 0x000000fd0000-0x000000ff0000 : "res"
    [    0.471330] 0x000000ff0000-0x000001000000 : "ART"
    [    0.869051] switch0: Atheros AR8337 rev. 2 switch registered on
    mdio.0



    booting from the second


    [    0.333444] spi-nor spi0.0: w25q128 (16384 Kbytes)
    [    0.338391] mtd: Found partition defined in DT for u-boot.
    Assigning
    OF node to support nvmem.
    [    0.338404] mtd: Found partition defined in DT for u-boot-env.
    Assigning OF node to support nvmem.
    [    0.347192] mtd: Found partition defined in DT for res.
    Assigning OF
    node to support nvmem.
    [    0.356297] mtd: Found partition defined in DT for ART.
    Assigning OF
    node to support nvmem.
    [    0.364771] 6 cmdlinepart partitions found on MTD device spi0.0
    [    0.379250] Creating 6 MTD partitions on "spi0.0":
    [    0.384128] 0x000000000000-0x000000040000 : "u-boot"
    [    0.392987] 0x000000040000-0x000000050000 : "u-boot-env"
    [    0.400143] 0x000000050000-0x000000810000 : "fw1"
    [    0.407352] 0x000000810000-0x000000fd0000 : "firmware"
    [    0.414387] 0x000000fd0000-0x000000ff0000 : "res"
    [    0.421421] 0x000000ff0000-0x000001000000 : "ART"
    [    0.818598] switch0: Atheros AR8337 rev. 2 switch registered on
    mdio.0

    .....


    [    2.055622] /dev/root: Can't open blockdev
    [    2.059807] VFS: Cannot open root device "(null)" or
    unknown-block(0,0): error -6
    [    2.067440] Please append a correct "root=" boot option; here
    are the
    available partitions:
    [    2.075921] 1f00             256 mtdblock0
    [    2.075933]  (driver?)
    [    2.082560] 1f01              64 mtdblock1
    [    2.082568]  (driver?)
    [    2.089212] 1f02            7936 mtdblock2
    [    2.089222]  (driver?)
    [    2.095856] 1f03            7936 mtdblock3
    [    2.095866]  (driver?)
    [    2.102490] 1f04             128 mtdblock4
    [    2.102498]  (driver?)
    [    2.109135] 1f05              64 mtdblock5
    [    2.109144]  (driver?)
    [    2.115779] Kernel panic - not syncing: VFS: Unable to mount
    root fs
    on unknown-block(0,0)
    [    2.124157] Rebooting in 1 seconds..


    AFAIU the code inside 400-mtd-mtdsplit-support.patch is working in
    the
    first case but not on the second, any suggestion?


    Cheers

    G10h4ck




    _______________________________________________
    openwrt-devel mailing list
    openwrt-devel@lists.openwrt.org
    https://lists.openwrt.org/mailman/listinfo/openwrt-devel


_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to