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
easier.
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.
Hauke
More information about the openwrt-devel
mailing list