On Fri, Mar 5, 2021 at 4:25 AM Daniel Golle <dan...@makrotopia.org> wrote: > > 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).
U-boot is a bit vague about it, but they have changed all of the tests to check for '-' instead of '@' so I guess it's preferred. Regards, Robert > > 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 -- Robert Marko Staff Embedded Linux Engineer Sartura Ltd. Lendavska ulica 16a 10000 Zagreb, Croatia Email: robert.ma...@sartura.hr Web: www.sartura.hr _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
