Re: [VOTE] New member proposal: Robimarko (Robert Marko)
On Tue, Jan 30, 2024 at 7:16 PM Christian Marangi (Ansuel) wrote: > > Robert is active in OpenWrt since 2017 and with some recent stats, he > has more than 310 commits merged in OpenWrt. > He also have uncounted Reviewed-by tag on various PR and merged commits > and generally helps in everything related to IPQ (ipq806x, ipq40xx and > ipq807x) and some mvebu targets. > > He did the conversion of ipq40xx target to DSA and made possible the > introduction of the ipq807x target by sorting all the QSDK downstream > patch and pushing them upstream. > > With his help, also the ipq60xx is very close on getting merged and > actually used permitting support of even more device for OpenWrt. > > Also he is almost always reachable on IRC openwrt-devel and never had > a problem in coordinating and collaborating with him. > > I think Robert is a good addition to our team and would massively help > me (Ansuel) in maintaining each IPQ target and review all the related > PR on github and patchwork. > I would like to add Robert to the OpenWrt committers team. +1 Hans > > The vote shall be concluded within 14 days. (13/02/2024) > > ___ > openwrt-adm mailing list > openwrt-...@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-adm ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken
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 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_x 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 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 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
Re: Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken
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_x 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 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 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
