Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken
Gio
gio at diveni.re
Wed Feb 7 09:44:05 PST 2024
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
More information about the openwrt-devel
mailing list