I can only guess that this change was verified on QEMU. And here is another problem that introduces many bugs from Xiaomi: testing changes only on QEMU.
This approach has no chance of detecting all bugs and is inherently wrong. Meaningful tests on QEMU are not possible. Even in cases where virtualization is supported by hardware, like for example x86 target on x86 host with KVM. Problems on real hardware may not be reproducible on QEMU. This also works in the opposite direction - problems on QEMU that don't occur on HW. Fixing such bugs later is a waste of developers' time, especially since these bugs are really hard to find. pon., 3 lut 2025 o 12:32 zou boan <zoub...@hotmail.com> napisał(a): > The latest progress: > > After a day of troubleshooting, I have confirmed that the issue was > caused by stack misalignment. The pull request #15437 changes > ARM64_CONTEXT_REGS from 36 to 37, resulting in the stack no longer being > 16-byte aligned, when i changes ARM64_CONTEXT_REGS from 37 to 38, the > ZCU111 board is alive. I have submitted a PR(#15748) to fix this issue, and > I would appreciate anyone to provide better suggestions. > > Thank you very much! > > > ________________________________ > 发件人: zou boan <zoub...@hotmail.com> > 发送时间: 2025年2月3日 15:50 > 收件人: dev@nuttx.apache.org <dev@nuttx.apache.org> > 主题: arm64 zynq-mpsoc was broken > > Hi: > > Today, I pulled and synchronized the latest NuttX, but after > successfully compiling it, I found that it failed to run. Through the > process of bisecting, the issue was ultimately pinpointed to Pull Request > #15437 https://github.com/apache/nuttx/pull/15437 > The pull request #15437 lacks test logs, leaving me uncertain as to > whether it has been validated through real hardware testing. These are the > outcomes of my tests on the ZCU111 board regarding the jtag and nsh > configurations. The pull request #15437 changes ARM64_CONTEXT_REGS from 36 > to 37, resulting in the stack no longer being 16-byte aligned, which > appears to violate the ARMv8-A architecture's requirement for 16-byte stack > alignment. While I encountered this issue on the ZCU111 hardware, I am > unsure whether other ARM64 hardware platforms might be similarly affected. > If anyone has experience or insights regarding other ARM64 hardware, could > you share your advice? Specifically, I would appreciate details on how > stack alignment requirements are implemented or any potential workarounds > to avoid this issue. Thank you very much! > > JTAG: > > 1 tools/configure.sh zcu111:jtag > 2 make > 3 download to the ZCU111 by JTAG and run: > > - Ready to Boot Primary CPU > - Boot from EL3 > - Boot to C runtime for OS Initialize > nx_start: Entry > up_allocate_heap: heap_start=0x0x1b6000, heap_size=0x7fd4a000 > gic_validate_dist_version: GICv2 detected > arm64_exception_handler: CurrentEL: MODE_EL3 > arm64_exception_handler: ESR_ELn: 0x9a000000 > arm64_exception_handler: FAR_ELn: 0x1130278421201907 > arm64_exception_handler: ELR_ELn: 0x189284 > print_ec_cause: SP Alignment > print_ec_cause: SP alignment fault exception > dump_assert_info: Current Version: NuttX 10.2.0 80e37cb22c Feb 3 2025 > 10:13:54 > dump_assert_info: Assertion failed panic: at file: > common/arm64_fatal.c:572 tas8 > up_dump_register: stack = 0x1b4590 > up_dump_register: x0: 0x8 x1: 0x1ad360 > up_dump_register: x2: 0x8 x3: 0x2 > up_dump_register: x4: 0x11ce50 x5: 0x1b6398 > up_dump_register: x6: 0xe80e300a92404231 x7: 0x115f2a882441f401 > up_dump_register: x8: 0xe87aa41a1403000d x9: 0x4000c01640681404 > up_dump_register: x10: 0x801a589c11200f07 x11: 0x844000d124244195 > up_dump_register: x12: 0x9cb48130485458d7 x13: 0x857d0d0430d89326 > up_dump_register: x14: 0x32504a0c66650520 x15: 0xff000000 > up_dump_register: x16: 0x2470010282020ec1 x17: 0x99ae11ed219421c1 > up_dump_register: x18: 0x857d0d0430d89310 x19: 0x44b40228d801404 > up_dump_register: x20: 0x40b3692634057008 x21: 0x387030af24609919 > up_dump_register: x22: 0x48088006128e49c3 x23: 0x100064 > up_dump_register: x24: 0x1b4cb0 x25: 0x101c30 > up_dump_register: x26: 0x2d5119104944c158 x27: 0x70ea896aa3521102 > up_dump_register: x28: 0xf0fc07a8100183ce x29: 0x1b4c40 > up_dump_register: x30: 0x106800 > up_dump_register: > up_dump_register: STATUS Registers: > up_dump_register: SPSR: 0x800003cd > up_dump_register: ELR: 0x189284 > up_dump_register: SP_EL0: 0x1b4cb0 > up_dump_register: SP_ELX: 0x1b48c8 > up_dump_register: EXE_DEPTH: 0x0 > up_dump_register: SCTLR_EL1: 0xc52838 > sched_dumpstack: backtrace| 0: 0x0000000000189284 0x000000000010522c > 0x000000000 > dump_tasks: PID GROUP PRI POLICY TYPE NPX STATE EVENT > SIGMASK D > dump_tasks: ---- --- --- -------- ------- --- ------- ---------- > ----------q > dump_task: 0 0 0 FIFO Kthread - Running > 0000000000k > sched_dumpstack: backtrace| 0: 0x0000000000189284 0x000000000010522c > 0x000000000 > > nsh: > > 1 tools/configure.sh zcu111:nsh > 2 make > 3 flash to the QSPI flash of ZCU111 and boot: > > NOTICE: BL31: Built : 09:38:30, Dec 20 2024 > - Ready to Boot Primary CPU > - Boot from EL1 > - Boot to C runtime for OS Initialize > psc��_start: Entry > up_allocate_heap: heap_start=0x0x156000, heap_size=0x7fdaa000 > gic_validate_dist_version: GICv2 detected > uart_registarm64_el1_undef: Undefined instruction at 0x100b04, dump: > arm64_el1_undef: 0x100afc : 0xd5033fdf > arm64_el1_undef: 0x100b00 : 0xd65f03c0 > arm64_el1_undef: 0x100b04 : 0xa9bf7bfd > arm64_el1_undef: 0x100b08 : 0x910003fd > arm64_el1_undef: 0x100b0c : 0x97fffdcc > arm64_exception_handler: CurrentEL: MODE_EL1 > arm64_exception_handler: ESR_ELn: 0x0 > arm64_exception_handler: FAR_ELn: 0x0 > arm64_exception_handler: ELR_ELn: 0x108a94 > print_ec_cause: Unknown/Uncategorized > print_ec_cause: Unknown/Uncategorized > dump_assert_info: Current Version: NuttX 10.2.0 d22e6d7489-dirty Feb 3 > 2025 14:58:41 arm64 > dump_assert_info: Assertion failed panic: at file: > common/arm64_fatal.c:572 task: Idle_Task process: Kernel 0x101f10 > up_dump_register: stack = 0x155950 > up_dump_register: x0: 0x155970 x1: 0x12e498 > up_dump_register: x2: 0xd x3: 0x135698 > up_dump_register: x4: 0x1559c0 x5: 0x12e5ac > up_dump_register: x6: 0x135602 x7: 0xd > up_dump_register: x8: 0x135602 x9: 0xd > up_dump_register: x10: 0xffffffd8 x11: 0x0 > up_dump_register: x12: 0x155b38 x13: 0x2a > up_dump_register: x14: 0x1559e0 x15: 0x120f2c > up_dump_register: x16: 0x155b38 x17: 0xd > up_dump_register: x18: 0x155a10 x19: 0x109c78 > up_dump_register: x20: 0x155c90 x21: 0x0 > up_dump_register: x22: 0x0 x23: 0x10945c > up_dump_register: x24: 0x155ac0 x25: 0x10a1bc > up_dump_register: x26: 0x155b70 x27: 0x135670 > up_dump_register: x28: 0x14f000 x29: 0x14f000 > up_dump_register: x30: 0x134000 > up_dump_register: > up_dump_register: STATUS Registers: > up_dump_register: SPSR: 0x0 > up_dump_register: ELR: 0x100b04 > up_dump_register: SP_EL0: 0x0 > up_dump_register: SP_ELX: 0x155d40 > up_dump_register: EXE_DEPTH: 0x0 > sched_dumpstack: backtrace| 0: 0x0000000000100b04 > dump_tasks: PID GROUP PRI POLICY TYPE NPX STATE EVENT > SIGMASK STACKBASE STACKSIZE USED FILLED COMMAND > dump_tasks: ---- --- --- -------- ------- --- ------- ---------- > ---------------- 0x152d40 4096 0 0.0% irq > dump_task: 0 0 0 FIFO Kthread - Running > 0000000000000000 0x153d50 8176 2640 32.2% Idle_Task > sched_dumpstack: backtrace| 0: 0x0000000000100b04 >
