All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] fit: Support FDT compression
Date: Thu, 18 Apr 2019 22:48:18 +0200	[thread overview]
Message-ID: <af56da68-f99f-3294-1f77-8a6def1e6a94@gmail.com> (raw)
In-Reply-To: <CAODwPW_Ljk3bFbDGdMoRJkHVUbLqtBNjzKWRKj8RNOwMC0io5w@mail.gmail.com>



On 18.04.19 22:36, Julius Werner wrote:
>> My approach was to uncompress all compressed images on-the-fly in
>> fit_image_load().
> 
> Right, that's essentially what this patch is doing too.

Cool. I'm sorry I haven't found the time to dig into your patch for 
details (too much day-to-day work right now).

> 
>> Or I could dig up my patches from October and we'll see how far you get
>> with those?
> 
> I think I found your patch:
> https://lists.denx.de/pipermail/u-boot/2018-October/344673.html

Exactly. I do have some further versions locally, but no real 
breakthrough I think.

> It seems to be doing something very close to what my patch does
> anyway. My patch goes a little further by also solving the case when
> no load address is given (in that case it will malloc() a buffer to
> decompress into with an upper bound guess for the required size).

Hmm, I think we might want to use the lmb functions here to allocate a 
buffer instead of relyling on malloc? The malloc pool might be large 
enough for an uncompressed devicetree, but not for an 8 MByte FPGA image...

But starting with malloc might be ok.

> If there is a load size given, the two should end up doing the same
> thing. Also your patch works on all image types, which as you said
> there breaks it for kernels. I think the option of doing it for all
> image types except kernels would be a good solution for everyone.
> (Ultimately, I think it might be nicer if the kernel decompression
> would also be handled there and not as a special case, but I'd rather
> not tackle everything at once. This can always be iterated upon in the
> future.)

The reason I discontinued that patch was that I started adding a feature 
to mkimage to add a property for the uncompressed size. This is still 
pending work I haven't sent to the ML, but I do want to continue it once 
I find the time.

So maybe we could move on with a v2 of your patch that uncompresses 
everything but the kernel? I'd like to test that with my compressed FPGA 
images then.

Regards,
Simon

  reply	other threads:[~2019-04-18 20:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18  1:22 [U-Boot] [PATCH 0/2] fit: FDT compression Julius Werner
2019-04-18  1:22 ` [U-Boot] [PATCH 1/2] fit: Support " Julius Werner
2019-04-18  8:29   ` Simon Goldschmidt
2019-04-18 19:59     ` Julius Werner
2019-04-18 20:06       ` Simon Goldschmidt
2019-04-18 20:36         ` Julius Werner
2019-04-18 20:48           ` Simon Goldschmidt [this message]
2019-04-18 21:09             ` Julius Werner
2019-04-18  1:22 ` [U-Boot] [PATCH 2/2] fit: Support compat string property in configuration node Julius Werner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af56da68-f99f-3294-1f77-8a6def1e6a94@gmail.com \
    --to=simon.k.r.goldschmidt@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.