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
Wed Feb 7 12:16:04 PST 2024
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 <gio at diveni.re> 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 <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