On Fri, Aug 2, 2019 at 2:36 PM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 02, 2019 at 08:00:22AM +0200, Simon Goldschmidt wrote:
Hi Heiko,
On Fri, Aug 2, 2019 at 6:08 AM Heiko Schocher hs@denx.de wrote:
Hello Julius,
Am 01.08.2019 um 20:24 schrieb Julius Werner:
First, we have a problem as we need to support what's out in the world.
How about I write a patch to change the decompression call in fit_image_load() to fall back to a memcpy() if the decompression fails (and print a big warning that the FIT image is wrong and should be updated)? That should keep those old installations working.
Hmm.. what happens if decompression does not fail ? (I wonder, why I get this Error, but I go into vacation, so I have no chance to dig deeper into it soon ...)
And why should we decompress, if we "know" we do not have to (in ramdisk case)? This cost only boottime ...
It's correct we don't need to decompress since the kernel can decompress the ramdisk. However, the FIT image is wrong (given our updated definition of the "compressed" field) and it's only decompressed on "legacy" images.
For the fast track, I prefer to ignore the compression property in ramdisk node ... (may configurable through a Kconfig option with default to ignore)
I'm not too fond of adding such extra cases, but you're right that decompressing a ramdisk is probably never needed...
I think we have a case where intentions differed historically and now we have to deal with it. Back in the earlier thread this year where we talked about this exact case, it was OK to start decompressing ramdisks as that was the intention way back when, but it was silently broken forever ago. After it was broken is when FIT adoption finally took off and we have the real life case of "set compression to the factual value, but it's not used by U-Boot!" has now become "set compression to the factual value and U-Boot decompresses it".
Maybe the best choice is to rework things so that we only check compression on (and decompress) device trees and when we print ramdisk information we note that it's not being decompressed?
While I can understand that point of view, please note that my intention is not having a compressed devicetree (where we save some KByte) but having a compressed FPGA image (where I save about 2 MByte!).
Given that, please don't start a positive list (e.g. only decompress devicetree and Kernel). But if we actually need to do this differently per type, just implement Heiko's suggestion and don't decompress ramdisks.
That way, we could show an error when seeing this setting for ramdisks and probably remove this special case handling in some years...?
Regards, Simon