[PATCH v2 14/25] binman: Allow mkimage to use a non-zero fake-blob size
Alper Nebi Yasak
alpernebiyasak at gmail.com
Thu Mar 10 20:30:09 CET 2022
On 06/03/2022 06:08, Simon Glass wrote:
> On Thu, 3 Mar 2022 at 14:16, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>>> def ObtainContents(self):
>>> + # Use a non-zero size for any fake files to keep mkimage happy
>>> data, input_fname, uniq = self.collect_contents_to_file(
>>> - self._mkimage_entries.values(), 'mkimage')
>>> + self._mkimage_entries.values(), 'mkimage', 1024)
>>
>> I kind of want to say that mkimage-the-etype should be able to handle
>> here whatever it gets from subentries (maybe by writing a single-byte
>> file itself), and mkimage-the-executable should be able to handle
>> zero-size files, but I'm not confident in those opinions.
>
> Well the entry has no problem with missing files, so that should be OK.
What I meant is when the non-faked input data ends up being zero-sized.
A bit contrived, but this still triggers the error:
mkimage {
args = ...;
blob-ext {
filename = "/dev/null"; /* or any other zero-size file */
};
};
which might end up happening e.g. via tee-os with TEE=/dev/null, I
remember someone doing that for one of the blobs in a mail but can't
find it or recall any details.
> For mkimage I agree it is a strange restriction. Perhaps we should
> just change it? I don't see what problem it could create.
I don't know either.
More information about the U-Boot
mailing list