Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken
Gio
gio at diveni.re
Thu Feb 8 00:24:09 PST 2024
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