[OE-core] [warrior][PATCH] kernel-uboot: compress arm64 kernels

[Bedel, Alban]

On Wed, 2019-09-25 at 08:49 +0000, Bonnans, Laurent wrote:
> On 9/25/19 2:23 AM, akuster808 wrote:
> 
> > On 9/24/19 12:23 AM, Bedel, Alban wrote:
> > > On Tue, 2019-09-03 at 09:41 +0000, Bedel, Alban wrote:
> > > > On Wed, 2019-07-31 at 13:53 +0000, Bedel, Alban wrote:
> > > > > AArch64 images are not self-decompressing, thus usually much
> > > > > larger.
> > > > > Boot times can be reduced by compressing them in FIT and
> > > > > uImages.
> > > > > 
> > > > > This commit is a backport of commit a725d188b5 (kernel-uboot:
> > > > > compress
> > > > > arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove
> > > > > useless
> > > > > special casing of arm64 Image) from master. Both commit were
> > > > > melted
> > > > > into one to avoid some useless churn.
> > > > Was this patch overlooked, or is there a reason it is not
> > > > considered
> > > > in
> > > > the next round of update for warrior? Without this patch kernel
> > > > images
> > > > are too large to fit in the flash of the system I'm using.
> > > > Furthermore
> > > > it is not trivial to fix this in my own layer.
> > > Please, I really like to get an answer here. I'm fine if there is
> > > a
> > > reason why this patch is not considered for warrior, but just
> > > getting
> > > ignored is very frustrating.
> > This appears to be a performance enhancement which does not fall
> > into
> > the criteria for back porting to a stable branch.
> > 
> > - armin
> 
> Just to bring all the elements on the table:
> 
> It's possible to argue that it is more of a fix for a performance 
> regression, as the sub-optimal approach was introduced in
> 1aa417df604d2627c56232a7a2c396c6b085d74b and  the patch
> in question is equivalent to a revert.

Also it is not a question of performance, but of storage space. This
commit effectively broke every board which doesn't have enough storage
for an uncompressed kernel.

> For example, the pyro branch does not seem to have the issue.
> 
> I don't know if it makes a difference in terms of criteria for a 
> backport but I agree that the problem is indeed made worse because it
> is quite hard to override in user layers.

That's exactly my problem, I really don't see how that could be fixed
in my own layer. Furthermore, unlike ARM or X86, ARM64 doesn't support
self decompressing kernel, so that can't be workarounded from the
kernel itself.

Alban
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190925/a68317aa/attachment.sig>