I think we should restart the conversation about setting up a build and test farm of real hardware, with a diverse collection of boards and processor architectures. It would be a good thing if we could have BOTH a project-owned centralized farm AND a relatively easy way for individual developers and companies to set up their own.
On Mon, Feb 3, 2025 at 7:25 AM raiden00pl <raiden0...@gmail.com> wrote: > 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 > > >
