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

[Wolfgang Denk]

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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If two witches would watch two watches, which witch would watch which
watch?