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.
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.
Best wishes,
Chris.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
