On Thu, Nov 13, 2025 at 1:45 AM Mohammad Amin Nili <[email protected]> wrote: > > [ 0.000000] printk: legacy bootconsole [udbg0] enabled > [ 0.000000] ioremap() called early from of_setup_earlycon+0xd0/0x2d4. Use > early_ioremap() instead > [ 0.000000] earlycon: earlycon_map: Couldn't map 0x00000000ff000000
pretty big red flag right there > NOTE: As you know bold of you to assume i know things > the `earlycon` driver depends on calling `ioremap` > in `drivers/tty/serial/earlycon.c:L47` to get the virtual address of its > `mapbase/membase`, which is later used by the main console driver (e.g. > `cdns,uart-r1p12`). During the very early boot phase, `ioremap` returns > `0x00000000` because it is called before `early_init_mmu` and > `early_ioremap_setup` in the `early_setup` of > `arch/powerpc/kernel/setup_64.S`. > > For debugging purposes, I hardcoded it to return the **physical address** > `0xFF000000` — which corresponds to the Zynq PS-side UART0. > > 5. From what I can tell, **the system crashes or loses console output > immediately after the MMU is activated** — specifically right after the > call to `RFI_TO_KERNEL` in `arch/powerpc/kernel/head_64.S:L1019`. Right, you turn on the MMU and the next time printk() is called the console driver tries to write to 0xFF00_0000. That's not a valid virtual address so it explodes. To make an address usable in both real mode (i.e. pre-mmu) and virtual mode you need to have the page tables setup so that virtual address maps to the same physical address. Setting up that mapping is what early_ioremap() does. That's why there's a warning telling you to use it. Based on the in-tree DTS files earlycon doesn't seem to be used on any powerpc systems. My guess would be that most ppc platform use udbg (very old, powerpc specific thing) rather than earlycon for this kind of super-early debug output. Considering you're getting console output via udbg I'd say just removing earlycon from your kernel command line will probably fix your issue.
