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

[akuster808]

On 9/25/19 2:32 AM, Bedel, Alban wrote:
> 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.

Thank you for the additional information.  This will help me in making
my decision in backporting this commit

- armin
> Alban