Re: powerpc: several early boot regressions on MPC52xx

[Christophe Leroy]

Hi Matthias,

Le 18/12/2023 à 14:48, Matthias Schiffer a écrit :
> Hi all,
> 
> I'm currently in the process of porting our ancient TQM5200 SoM to a modern kernel, and I've
> identified a number of regressions that cause early boot failures (before the UART console has been
> initialized) with arch/powerpc/configs/52xx/tqm5200_defconfig.

"modern" kernel ==> which version ?

> 
> Issue 1) Boot fails with CONFIG_PPC_KUAP enabled (enabled by default since 9f5bd8f1471d7
> "powerpc/32s: Activate KUAP and KUEP by default"). The reason is a number of of_iomap() calls in
> arch/powerpc/platforms/52xx that should be early_ioremap().

Can you give more details and what leads you to that conclusion ?

There should be no relation between KUAP and of_iomap()/early_ioremap(). 
Problem is likely somewhere else.

> 
> I can fix this up easy enough for mpc5200_simple by changing mpc5200_setup_xlb_arbiter() to use
> early_ioremap() and moving mpc52xx_map_common_devices() from the setup_arch to the init hook (one
> side effect is that mpc52xx_restart() only works a bit later, as it requires the mpc52xx_wdt mapping
> from mpc52xx_map_common_devices(); I'm not sure if there is a better solution).
> 
> For the other 52xx platforms (efika, lite5200, media5200) things are a bit more chaotic, and they
> create several more temporary mappings from setup_arch. Either they should all be moved to the init
> hook as well, or be converted to early_ioremap(), but I can't tell which is more appropriate. As a
> first step, I would propose a patch that fixes this for the simple platforms and leaves the other
> ones unchanged.
> 
> (Side note: I also found that before 16132529cee58 ("powerpc/32s: Rework Kernel Userspace Access
> Protection"), boot would succeed even with KUAP enabled without changing the incorrect of_iomap(); I
> guess the old implementation was more lenient about the incorrect calls that the kernel warns
> about?)

Interesting.
Again, there shouldn't be any impact of those incorrect calls. They are 
correct calls, it is just an historical method that we want to get rid 
of on day.
Could you then provide the dmesg of what/how it works here ? And then 
I'd also be interested in a dump of /sys/kernel/debug/kernel_page_tables 
and /sys/kernel/debug/powerpc/block_address_translation
and /sys/kernel/debug/powerpc/segment_registers

For that you'll need CONFIG_PTDUMP_DEBUGFS

> 
> Issue 2) Boot fails with CONFIG_STRICT_KERNEL_RWX enabled, which is also the default nowadays.
> 
> I have not found the cause of this boot failure yet; is there any way to debug this if the failure
> happens before the UART is available and I currently don't have JTAG for this hardware?

Shouldn't happen before UART is available, strict enforcement is 
perfomed by mark_readonly() and free_initmem() in the middle of 
kernel_init(). UART should be ON long before that.

So it must be something in the setup that collides with CONFIG_KUAP and 
CONFIG_STRICT_KERNEL_RWX.

Could you send dmesg of when it works (ie without 
CONFIG_KUAP/CONFIG_STRICT_KERNEL_RWX) and when it doesn't work if you 
get some initial stuff ?

Also your .config unless you are using one of the defconfigs.

What UART driver is used ?

What's your boot console, can you use "early boot text console (BootX or 
OpenFirmware only) (CONFIG_BOOTX_TEXT)" ?

Christophe