[U-Boot] [RFC PATCH] rockchip, Makefile: add u-boot-tpl-with-spl.img target
sjg at chromium.org
Tue Aug 13 09:33:18 UTC 2019
On Mon, 12 Aug 2019 at 11:59, Chris Webb <chris at arachsys.com> wrote:
> Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> >> [Simon Glass <sjg at chromium.org> wrote:]
> >> Well, for producing an image that works. E.g. producing a full image
> >> (TPL, SPL and U-Boot) for an SD card - it would be nice to have
> >> u-boot-rockchip.sd.bin or something like that.
> > True. That'd be an image you write at certain offset I suppose so it
> > preserves the MBR/partition tables?
> This is also just concatenation and padding, surely?
> tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin u-boot-sd.img
> cat spl/u-boot-spl-dtb.bin >>u-boot-sd.img
> dd if=u-boot.itb of=u-boot-sd.img seek=16320 # 16384 - 64
> ...or truncate(1) and cat(1) instead of dd(1) if you prefer. As you say,
> Mark, this assumes it's meant to be written at offset 64 sectors in to
> avoid blowing away the partition table. (Pad with 64 leading NULs if it's
> supposed to be a bootable card image I guess.)
> My worry about using binman for cracking such a simple nut is the
> dependencies it pulls in that wouldn't otherwise be needed: the
> documentation suggests at least lzma-alone, liblz4, and pyelftools.
I should probably update this. Unless you use compression and SPL
symbols you shouldn't need these.
> We've just exorcised the pyelftools requirement for building Rockchip
> u-boot; it would be a pity for to re-inflict it on users and casual
> developers just for a convenience feature.
You mean make_fit_atf.py? Again I think that this logic should be
moved into binman. It doesn't actually have support to generic FITs
We don't use a lot from this library so perhaps could adopt a similar
More information about the U-Boot