Hi Quentin, On Mon, 18 Jul 2022 at 03:39, Quentin Schulz <quentin.sch...@theobroma-systems.com> wrote: > > Hi Simon, > > On 7/16/22 13:58, Simon Glass wrote: > > On Fri, 15 Jul 2022 at 09:37, Quentin Schulz <foss+ub...@0leil.net> wrote: > >> > >> From: Quentin Schulz <quentin.sch...@theobroma-systems.com> > >> > >> Some image types handled by mkimage require the datafiles to be passed > >> independently (-d data1:data2) for specific handling of each. A > >> concatenation of datafiles prior to passing them to mkimage wouldn't > >> work. > >> > >> That is the case for rksd and rkspi for example, which require page > >> alignment (plus some weird hack for rkspi) plus size data of each stage > >> to be embedded in the mkimage header. > >> > > I forgot to rephrase the commit log. As seen in patch 1/8, there > actually doesn't seem to be a need for rksd for passing multiple data > files to mkimage, only the TPL could be passed to mkimage and SPL > appended right after that blob generated by mkimage. Maybe it's luck but > it seems to work for me the few tries I did on SD card and eMMC.
OK I see. > > >> This adds the ability to tell binman to pass the datafiles without > >> prior concatenation to mkimage, by adding the multiple-data-files > >> boolean property to the mkimage node. > >> > >> Cc: Quentin Schulz <foss+ub...@0leil.net> > >> Signed-off-by: Quentin Schulz <quentin.sch...@theobroma-systems.com> > >> --- > >> tools/binman/entries.rst | 22 +++++++++++++++++++ > >> tools/binman/etype/mkimage.py | 41 +++++++++++++++++++++++++++++++---- > >> 2 files changed, 59 insertions(+), 4 deletions(-) > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > > I wonder if we should move this logic to binman (from mkimage) when > > all the boards are converted to binman? > > Not sure this fits the "Relationship to mkimage" section in binman.rst? > What part of the logic exactly would you like to move from mkimage to > binman? The concatenation of the files and the strange SPI processing, for example. It's just an idea and it is OK to keep it in mkimage. Regards, Simon