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