[U-Boot] [PATCH] spl: implement CRC check on U-Boot uImage

[Simon Goldschmidt]

On 28.11.2018 10:08, Wolfgang Denk wrote:
> Dear Simon,
>
> In message <1707f08a-4844-979c-716f-9ee8da29ccfd at gmail.com> you wrote:
>> I also thought about that. I voted against to have less config options.
> Yes, I can understand this.  Actually I have to admit that I cannot
> think of a god reason to have CRC support in SPL for other purposes,
> but who knows...
>
>> But sure, I can add a config option for this in v2.
> Thanks.
>
>> Hmm, while this is a good idea regarding speed, I'm not sure this can be
>> done easily with the current infrastructure. The data is copied down at
>> the driver somewhere. That would mean we'd have to change every driver
>> interface and every driver to allow a callback where we'd update the CRC.
> I would hope it became easier now since we have a unified interface,
> but I admit I didn't look at the implementation details at all. In
> any case, this requires additional though, as the "loader" would
> also need to understand the structure of the file - for legacy
> uImage format it would have to know where to find the header
> checksum andverify the header, then where to find the image
> checksum(s) and length(s) and verify the payload(s).
>
>> Is this really a rework that is worth it? Because it's also not done
>> like that for loading other uImages (Kernel, fdt, ramdisk) when U-Boot
>> loads the OS, or is it?
> Yesno.  Image handling has been reworked frequently and I fear much
> of the original design ideas have not been preserved - either by
> lack of knowledge or by intention.
>
> The idea was that there are two stages for booting: 1) loading some
> image to RAM, and 2) booting it.
>
> The loading part would not care about the content - it loads a
> "file", i. e. an unstructured byte stream.
>
> The booting part (i. e. the bootm command) would understand the
> image format and handle the checking.  It would compute (and verify)
> the CRC while uncompressing the kernel and writing the uncompressed
> data to the memory region specified by the "load address" given in
> the image header, so no _extra_ reading was needed.

That still sounds like an interesting feature! Although it might be 
difficult to implement with all the different unzip algorithms we have 
to add a CRC check...

But I do not see it in the current U-Boot sources. Can you point me to a 
git commit in the past where I can have a look at how this was done?

Regards,
Simon