I would also like to join with: SAMV7 STM32 ZCU102 (which I would love to run nuttx on - but I need help for that)
-- Hard- and Softwaredevelopment Consultant Geschäftsführung: Simon Filgis USt-IdNr.: DE305343278 ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications> On Tue, Feb 4, 2025 at 9:00 AM zou boan <zoub...@hotmail.com> wrote: > I am very interested in distributed building and testing hardware farms, > and if someone is leading this project, I would be delighted to join. > > 获取Outlook for Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Tomek CEDRO <to...@cedro.info> > Sent: Tuesday, February 4, 2025 2:10:02 AM > To: dev@nuttx.apache.org <dev@nuttx.apache.org> > Subject: Re: arm64 zynq-mpsoc was broken > > Thus the idea for DRUNX (Distributer Runtime and bUild for NuttX) Test > Environment :-) > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Mon, Feb 3, 2025, 14:35 Nathan Hartman <hartman.nat...@gmail.com> > wrote: > > > 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 > > > > > > > > > >
