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

[Robert Marko]

On Fri, Mar 5, 2021 at 4:25 AM Daniel Golle <daniel at 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 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).

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 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



-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko at sartura.hr
Web: www.sartura.hr