Hi Robert, On Thu, Mar 04, 2021 at 12:37:20PM +0100, Robert Marko wrote: > U-boot will reject the nodes with @ for the address since > commit: > https://gitlab.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4 > > This in turn will cause the failure to boot with OpenWrt > generated images. > > So, to rectify that simply replace @ with -.
I've pulled your patches into my staging tree and also covered the recently added additions to mkits.sh (rootfs@1, initrd@1). I tested on the BPi-R64 and Linksys E8450 devices (U-Boot 2020.10). Neither the new block/partitions/fit.c parser nor oldschool drivers/mtd/mtdsplit/fit.c rely on that '@' sign, so things should be fine equally for all platforms using mkits.sh in some way or another. Is the dash '-' symbol the recommened separator to be used for enumarated image nodes? Just not to introduce the next 'smart' (but practically unneeded, at least for) convention which will then later on again need to be fixed before anyone ever adds more than one image of each type (which isn't actually supported anywhere, not in mkits.sh, neither anywhere else in the build system). Of course, it would be very nice to use the fancy features FIT can offer such as having a single image with several DTB nodes and letting the bootloader choose the right one for the board. (quite some work on the build-system would be needed for that). Or bundling additional squashfs blobs which are overlay-mounted on top of the regular rootfs eg. for localization or community mesh firmware. I'm already working on that and if more platforms switch to use the fit partition parser and start using `mkimage -E`-style (_external data_) FIT images including the rootfs or initrd as FIT sub-images instead of writing rootfs at (from bootloader perspective) arbitrary, platform-specific location into the flash or compiling the initrd as object into the kernel (not cool for ImageBuilder...). However, even with all those cool features in mind, I still don't see the point of supporting **enumerated** images with a name-prefix, let it be kernel-1, kernel1, kernel_1, kernel#1 or whatever. If we ever support multi-dtb or multi-kernel images, then the names should be more meaningful, eg. kernel-mvebu-cortexa72 and kernel-mediatek-mt7622 along with several names DTBs, eg. dtb-mt7622-linksys-e8450, dtb-marvell-macchiatobin-doubleshot and potentially a lot of devices, all supported by that single image. When flashing such an image to a device, we could drop the uneeded sub-images (ie. not matching selected config). (anyone interested?) Cheers Daniel > > Robert Marko (2): > scripts: mktish.sh: replace @ with - in nodes > build: use config-1 instead of config@1 as default > > include/image-commands.mk | 2 +- > include/image.mk | 2 +- > scripts/mkits.sh | 8 ++++---- > 3 files changed, 6 insertions(+), 6 deletions(-) > > -- > 2.29.2 > > > _______________________________________________ > 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
