Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken
Bjørn Mork
bjorn at mork.no
Thu Feb 8 01:10:07 PST 2024
I don't know what plans there are.
But I agree that there should be a better and standardized way to manage
dual boot support in combination with partition splitters. There are
many dual booting devices where OpenWrt can boot only from the first
firmware partition, most likely because it's so hard to make splitting
work with dual boot.
Ideally, we should be able to define this support in DT, with the
necessary flexibility for the bootloader interface.
Bjørn
Gio <gio at diveni.re> writes:
> Thanks Bjørn
>
> Clean DTS file and CONFIG_MTD_SPLIT_FIRMWARE=y were definitely needed.
>
> In conclusion to have dual boot working from a clean checkout I needed just
>
> kconfig_unset CONFIG_MIPS_CMDLINE_FROM_DTB
>
> kconfig_set CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER
>
> kconfig_set CONFIG_MTD_SPLIT_FIRMWARE
>
> Those kconfig_xxxxx functions comes from
> https://gitlab.com/g10h4ck/kconfig-utils
>
> About a bit of context, from what I read on the wiki i feel that
> CONFIG_MTD_SPLIT_FIRMWARE is someway legacy support. Am I right
> supposing there is no plan to remove this any time soon anyway? Or
> there is a plan to support dual boot in a different manner ?
>
> Cheers
>
> Gio
>
> 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 <gio at diveni.re> 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 <gio at 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 at lists.openwrt.org
>>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>>>
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel at lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list