> 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.
Sounds good! I'll send a patch.
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
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
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.
> > >
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
> >
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
Am 01.08.2019 um 21:01 schrieb Julius Werner:
Well, I'm sure you'd find enough FIT images where the uncompression
might succeed but the target space for decompression is not big enough
(see bootm_size), would such an error be fixed as well?
I think so? Assuming all the compression algorithms
> Well, I'm sure you'd find enough FIT images where the uncompression
> might succeed but the target space for decompression is not big enough
> (see bootm_size), would such an error be fixed as well?
I think so? Assuming all the compression algorithms check for an
output buffer overrun (looks
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
> 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
On Thu, Aug 01, 2019 at 04:38:51PM +0200, Heiko Schocher wrote:
> Hello Simon,
>
> Am 01.08.2019 um 14:33 schrieb Simon Goldschmidt:
> >Am 01.08.2019 um 10:06 schrieb Heiko Schocher:
> >>Hello Julius,
> >>
> >>since your commit (just gone into mainline):
> >>
> >>b1307f884a91 ("fit: Support
Hello Simon,
Am 01.08.2019 um 14:33 schrieb Simon Goldschmidt:
Am 01.08.2019 um 10:06 schrieb Heiko Schocher:
Hello Julius,
since your commit (just gone into mainline):
b1307f884a91 ("fit: Support compression for non-kernel components (e.g. FDT)")
I see on an imx6ull based board when
Am 01.08.2019 um 10:06 schrieb Heiko Schocher:
Hello Julius,
since your commit (just gone into mainline):
b1307f884a91 ("fit: Support compression for non-kernel components (e.g. FDT)")
I see on an imx6ull based board when booting (FIT image with kernel, dtb
and initramdisk), fit image source
Hello Julius,
since your commit (just gone into mainline):
b1307f884a91 ("fit: Support compression for non-kernel components (e.g. FDT)")
I see on an imx6ull based board when booting (FIT image with kernel, dtb
and initramdisk), fit image source created from yocto, see [1]:
## Loading kernel
14 matches
Mail list logo
