You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by zou boan <zo...@hotmail.com> on 2025/02/03 11:31:51 UTC
回复: arm64 zynq-mpsoc was broken
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 <zo...@hotmail.com>
发送时间: 2025年2月3日 15:50
收件人: dev@nuttx.apache.org <de...@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
Re: arm64 zynq-mpsoc was broken
Posted by Ludovic Vanasse <lu...@gmail.com>.
I'd love to help too.
I have a couple of STM32 nucleo boards that I can add to the farm.
Best regards,
Ludovic Vanasse
ludovicvanasse@gmail.com
+1(514) 475-0447
On Tue, Feb 4, 2025 at 3:09 AM Simon Filgis <si...@ingenieurbuero-filgis.de>
wrote:
> 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 <zo...@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 <de...@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 <ha...@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 <ra...@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 <zo...@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 <zo...@hotmail.com>
> > > > > 发送时间: 2025年2月3日 15:50
> > > > > 收件人: dev@nuttx.apache.org <de...@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
> > > > >
> > > >
> > >
> >
>
Re: arm64 zynq-mpsoc was broken
Posted by Simon Filgis <si...@ingenieurbuero-filgis.de>.
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 <zo...@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 <de...@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 <ha...@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 <ra...@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 <zo...@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 <zo...@hotmail.com>
> > > > 发送时间: 2025年2月3日 15:50
> > > > 收件人: dev@nuttx.apache.org <de...@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
> > > >
> > >
> >
>
Re: arm64 zynq-mpsoc was broken
Posted by zou boan <zo...@hotmail.com>.
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 <de...@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 <ha...@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 <ra...@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 <zo...@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 <zo...@hotmail.com>
> > > 发送时间: 2025年2月3日 15:50
> > > 收件人: dev@nuttx.apache.org <de...@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
> > >
> >
>
Re: arm64 zynq-mpsoc was broken
Posted by Tomek CEDRO <to...@cedro.info>.
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 <ha...@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 <ra...@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 <zo...@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 <zo...@hotmail.com>
> > > 发送时间: 2025年2月3日 15:50
> > > 收件人: dev@nuttx.apache.org <de...@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
> > >
> >
>
Re: arm64 zynq-mpsoc was broken
Posted by Nathan Hartman <ha...@gmail.com>.
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 <ra...@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 <zo...@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 <zo...@hotmail.com>
> > 发送时间: 2025年2月3日 15:50
> > 收件人: dev@nuttx.apache.org <de...@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
> >
>
Re: arm64 zynq-mpsoc was broken
Posted by raiden00pl <ra...@gmail.com>.
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 <zo...@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 <zo...@hotmail.com>
> 发送时间: 2025年2月3日 15:50
> 收件人: dev@nuttx.apache.org <de...@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
>