From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 2 Aug 2019 09:14:29 -0400 Subject: [U-Boot] fit image: boot gzipped ramdisk does not work anymore In-Reply-To: References: <017cf623-d470-cb72-c753-824236b63f43@denx.de> <6e972a84-2a18-74df-2575-60144381a635@gmail.com> <7543a771-efd5-72cd-6f91-ee6d0863b21c@denx.de> <20190801155846.GF6403@bill-the-cat> <3f423391-b22d-5184-6106-3730ac9b400d@denx.de> <20190802123644.GJ6403@bill-the-cat> Message-ID: <20190802131429.GL6403@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Aug 02, 2019 at 02:50:40PM +0200, Simon Goldschmidt wrote: > On Fri, Aug 2, 2019 at 2:36 PM Tom Rini 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 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...? OK. So lets special case ramdisk to just note that we see it's compressed ("compression: %s, ignored" ?) and then we'll find out if there's really a bunch of cases where people assumed it was decompressed by us or not. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: