Hi Oliver! > If you wanted to do something similar you would need to > implement a udbg driver for your xilinx UART.
Actually this was the key point which finally led me to the right direction. Thank you SOOO much for your help. I implemented a udbg driver for Xilinx’s UART, worked through a number of bugs, and managed to get bash and userspace to start. During the work I hit two things in the source that look odd to me; I’d appreciate any pointers or explanations: 1. There appear to be two ways udbg can be initiated: - https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup_64.c#L378 <https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup_64.c#L378> - https://elixir.bootlin.com/linux/v6.18-rc5/source/init/main.c#L932 <https://elixir.bootlin.com/linux/v6.18-rc5/source/init/main.c#L932> -> https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup-common.c#L944 <https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup-common.c#L944> -> https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup-common.c#L947 <https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup-common.c#L947> The problem with the *first* (early) path is that a udbg driver often calls `early_ioremap()` **before** any MMU/memory setup has completed. The MMU setup for 64-bit happens here: - https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup_64.c#L418 <https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup_64.c#L418> The 32-bit setup (`setup_32.c`) calls `udbg_early_init` *after* `early_ioremap_init`, so it doesn’t hit this ordering problem: - https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup_32.c#L87 <https://elixir.bootlin.com/linux/v6.18-rc5/source/arch/powerpc/kernel/setup_32.c#L87> In my case, attempting to initialize the Xilinx udbg driver via the early path can (and did) cause kernel panics because `early_ioremap()` runs before the memory/MMU is ready. Practically, the only reliable place for my driver to initialize is later in `init/main.c`. Is this the intended/expected behavior for PPC64? Or am I missing something? 2. I had to inject a busy-wait loop between lines 125–126 in `kernel/rcu/tiny.c` to prevent a crash when/after switching to userspace: - https://elixir.bootlin.com/linux/v6.18-rc5/source/kernel/rcu/tiny.c#L125 <https://elixir.bootlin.com/linux/v6.18-rc5/source/kernel/rcu/tiny.c#L125> Here is the loop I added: for (volatile uint32_t i = 0; i < 10; i++); If I omit that trivial busy-wait, the kernel crashes while/after switching to userspace with an error LIKE: [ 42.397074] kernel tried to execute exec-protected page (c00c000000000000) - exploit attempt? (uid: 0) [ 42.408148] BUG: Unable to handle kernel instruction fetch [ 42.414964] Faulting instruction address: 0xc00c000000000000 Vector: 400 (Instruction Access) at [c00000000207fae0] pc: c00c000000000000 lr: c00000000008c798: rcu_process_callbacks+0xf8/0x100 sp: c00000000207fd80 msr: 900000001000b033 current = 0xc000000002056300 paca = 0xc0000000016e8000 irqmask: 0x03 irq_happened: 0x09 pid = 10, comm = ksoftirqd/0 Linux version 6.18.0-rc5-00111-g6fa9041b7177-dirty (manili@manili) (powerpc64le-linux-gcc.br_real (Buildroot 2021.11-18033-g83947c7bb6) 14.3.0, GNU ld (GNU Binutils) 2.43.1) #3 Thu Nov 20 09:33:11 EST 2025 enter ? for help [link register ] c00000000008c798 rcu_process_callbacks+0xf8/0x100 [c00000000207fd80] c00000000008c748 rcu_process_callbacks+0xa8/0x100 (unreliable) [c00000000207fe00] c00000000003f320 handle_softirqs+0x1ec/0x23c [c00000000207ff00] c00000000003f3a8 run_ksoftirqd+0x38/0x58 [c00000000207ff20] c00000000005f9c4 smpboot_thread_fn+0x1a0/0x1a8 [c00000000207ff80] c00000000005b190 kthread+0x1c0/0x1cc [c00000000207ffe0] c00000000000b160 start_kernel_thread+0x14/0x18 mon> The exact addresses in the error vary, but the crash template is the same. My suspicion is that this is a core/thread synchronization issue. Do you have any ideas on this issue and why a simple while loop is able to solve it? Bests, Manili
