On 28.11.2018 10:08, Wolfgang Denk wrote:
Dear Simon,
In message <1707f08a-4844-979c-716f-9ee8da29c...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
