[PATCH 0/2] Fix OpenWrt images in current U-boot

[Daniel Golle]

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 at 1, initrd at 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 at 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 at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel