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 <g...@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 <g...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
