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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core