Hi Chris, On Mon, 12 Aug 2019 at 11:59, Chris Webb <ch...@arachsys.com> wrote: > > Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > >> [Simon Glass <s...@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 but should. We don't use a lot from this library so perhaps could adopt a similar implmentation. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot