Don't change the name of fw1/firmware in DT. If you change it to fw1 then it will match the cmdline definition and the of_node is copied. And the uimage splitter will parse it based on compatible match.
What I suggest is keeping everything else as-is, but define CONFIG_MTD_SPLIT_FIRMWARE=y I'm in no way sure it will work. But it's worth trying Bjørn Gio <[email protected]> writes: > Bjorn I have tested your suggestion too but same result happens, the > DTS in my buildroot is manually edited so partitions are called fw1 > and fw2 and not firmware and fw2, but the behaviour is identical > > [ 0.337578] spi-nor spi0.0: w25q128 (16384 Kbytes) > [ 0.342531] mtd: Found partition defined in DT for > u-boot. Assigning OF node to support nvmem. > [ 0.342544] mtd: Found partition defined in DT for > u-boot-env. Assigning OF node to support nvmem. > [ 0.351347] mtd: Found partition defined in DT for fw1. Assigning > OF node to support nvmem. > [ 0.360463] mtd: Found partition defined in DT for res. Assigning > OF node to support nvmem. > [ 0.368951] mtd: Found partition defined in DT for ART. Assigning > OF node to support nvmem. > [ 0.377434] 6 cmdlinepart partitions found on MTD device spi0.0 > [ 0.391918] Creating 6 MTD partitions on "spi0.0": > [ 0.396797] 0x000000000000-0x000000040000 : "u-boot" > [ 0.405696] 0x000000040000-0x000000050000 : "u-boot-env" > [ 0.412065] 0x000000050000-0x000000810000 : "fw1" > [ 0.419773] 2 uimage-fw partitions found on MTD device fw1 > [ 0.425404] Creating 2 MTD partitions on "fw1": > [ 0.430002] 0x000000000000-0x000000240000 : "kernel" > [ 0.436159] 0x000000240000-0x0000007c0000 : "rootfs" > [ 0.443588] mtd: setting mtd4 (rootfs) as root device > [ 0.448901] 1 squashfs-split partitions found on MTD device rootfs > [ 0.455224] 0x000000690000-0x0000007c0000 : "rootfs_data" > [ 0.462541] 0x000000810000-0x000000fd0000 : "firmware" > [ 0.468874] 0x000000fd0000-0x000000ff0000 : "res" > [ 0.476261] 0x000000ff0000-0x000001000000 : "ART" > [ 0.880498] switch0: Atheros AR8337 rev. 2 switch registered on mdio.0 > > On 2/7/24 20:16, Bjørn Mork wrote: >> To me it looks like the uimage-fw parser isn't running at all in the >> second case. I assume that is because CONFIG_MTD_SPLIT_FIRMWARE is >> unset. >> >> The reason splitting works in the first case is because of >> 421-drivers-mtd-parsers-add-nvmem-support-to-cmdlinepart.patch >> which copies the "firmware" of_node from the DT, making the splitter >> match on the compatible. We see the >> >> "mtd: Found partition defined in DT for firmware." >> >> message from that patch. But this only works when there is an exact >> match between the cmdline partition and the DT partition, which there >> isn't when "fw2" is renamed to "firmware". >> >> If I am correct, you can make this work simply by setting >> >> CONFIG_MTD_SPLIT_FIRMWARE=y >> >> without any other changes. I believe this should make the second case >> work by matching on the "firmware" name. >> >> >> Bjørn >> >> Gio <[email protected]> writes: >> >>> 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 <[email protected]> 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 >>>>> [email protected] >>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>>>> >>>> _______________________________________________ >>>> openwrt-devel mailing list >>>> [email protected] >>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>> _______________________________________________ >>> openwrt-devel mailing list >>> [email protected] >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
