RFC: layerscape: update to kernel 5.10

Hauke Mehrtens hauke at hauke-m.de
Tue Nov 2 11:44:02 PDT 2021

On 11/2/21 11:49 AM, Martin Schiller wrote:
> I have now found the cause of my boot problems with linux 5.10.
> (see [1] for reference)
> By changing the TEXT_OFFSET to 0x0 (instead of 0x80000 before) in the 
> upstream
> commit [2] and deactivated kernel option CONFIG_RELOCATABLE the system 
> could not
> boot.
> Thus, we now need to set the KERNEL_LOADADDR to 0x80000000 in the 
> layerscape
> target for kernel >= 5.8. (ATTENTION: but then kernel 5.4 can no longer 
> boot).

You could set this depending on the config option CONFIG_LINUX_5_10.

> In addition, we should think about enabling CONFIG_RELOCATABLE in 
> general to
> avoid being completely in the dark in case of similar problems in the 
> future.

Activating CONFIG_RELOCATABLE for layerscape should be ok, but I would 
not activate it for all targets. We tried to make a MIPS target use 
kASLR which is CONFIG_RELOCATABLE, and it was not easy to make it boot 
up again. We ran into many problems with the early boot process and the 
memory relocation. On ARM64 devices with a lot of memory this should be 

The MIPS KConfig help also says this:
 > The relocations make the kernel binary about 15% larger, but are
 > discarded at runtime

> Also, I am currently very unhappy with how the kernel patches are 
> handled in the
> layerscape target. So far they seem to be taken "1 to 1" from the NXP 
> LSDK. This
> pile of patches is totally unmanageable and it is impossible to 
> understand what
> is really needed and what is not.
> There was already a small discussion about this [3].
> I would like to make a clear CUT here and work as far as possible with 
> the linux
> upstream state.
> What is your opinion about this?
> (maybe any performance drawbacks, missing features etc.)

I am not a user of this target. I also do not like all these layerscape 
patches and would support following upstream with only very few patches. 
Doing the cut with the kernel 5.10 update is a good idea.


More information about the openwrt-devel mailing list