arch/arm64 Fix the SP unalignment issues

[zouboan]

Summary

zynq-mpsoc and zcu111 borad was broken by #15437, because #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. this PR changes ARM64_CONTEXT_REGS to 38 to fix the issues #15747.

Impact

Impact on user: YES, this PR changes ARM64_CONTEXT_REGS from 37 to 38 will consume 8 byte more memary, but the mpact is acceptable.
Impact on build: NO, this PR just changes the value of ARM64_CONTEXT_REGS.
Impact on hardware: YES. This impacts all the arm64 hardware, but tested and passed on ZCU111 board.
Impact on documentation: NO, there's no functionality or usage changes, so the documentation does not need to bo modified.
Impact on security: YES, this PR improved security.
Impact on compatibility:YES, this PR fixed uncompatibility of zynq-mpsoc and zcu111 borad.

Testing

Build Host(s): Linux Ubuntu 22.04, x86_64, Linaro GCC 7.3-2018.04-rc3.
Target(s): Zynq UltraScale+ MPSoC ZCU111 board.
Testing logs:

nsh:

1 tools/configure.sh zcu111:nsh
2 make
3 flash to the QSPI flash of ZCU111 and boot:

Xilinx Zynq MP First Stage Boot Loader 
Release 2018.3   Dec 16 2024  -  19:57:38
NOTICE:  BL31: Built : 09:38:30, Dec 20 2024
- Ready to Boot Primary CPU
- Boot from EL1
- Boot to C runtime for OS Initialize
nx_start: Entry
NuttShell (NSH) NuttX-10.2.0
nsh> nx_start: CPU0: Beginning Idle Loop
nsh> 
nsh> 

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=0x0x183000, heap_size=0x7fd7d000
gic_validate_dist_version: GICv2 detected
uart_register: Registering /dev/console
uart_register: Registering /dev/ttyS0
work_start_highpri: Starting high-priority kernel worker thread(s)
nxtask_activate: hpwork pid=1,TCB=0x1835b0
nx_start_application: Starting init thread
task_spawn: name=nsh_main entry=0x11cfd8 file_actions=0 attr=0x181d30 argv=0x181d50
nxtask_activate: nsh_main pid=2,TCB=0x185ac0
lib_cxx_initialize: _sinit: 0x15dc34 _einit: 0x15dc34

NuttShell (NSH) NuttX-10.2.0
nsh> nx_start: CPU0: Beginning Idle Loop
nsh> 
nsh> 

[acassis]

@zouboan nice work investigating this issue and submitting this fix!

[cederom]

Thank you @zouboan :-) Good catch! :-)

Can you also perform apps/testing/ostest and other possible tests to make sure this REG_RESERVED is never used? :-)

[anchao]

LGTM

[cederom]

@anchao please take a look at dev@ mailing list.

@zouboan could you please try running the ostest please?

[zouboan]

Thank you @zouboan :-) Good catch! :-)
i
Can you also perform apps/testing/ostest and other possible tests to make sure this REG_RESERVED is never used? :-)

Thank you for the reminder. After checking, I found that REG_RESERVED is not used in either NuttX or APPS . However, I will still proceed with conducting apps/testing/ostest

[zouboan]

@anchao please take a look at dev@ mailing list.

@zouboan could you please try running the ostest please?

I'm on leave today and don't have access to the hardware. I will conduct the test tomorrow.

[cederom]

@cederom: Thank you @zouboan :-) Good catch! :-)
Can you also perform apps/testing/ostest and other possible tests to make sure this REG_RESERVED is never used? :-)

@zouboan: Thank you for the reminder. After checking, I found that REG_RESERVED is not used in either NuttX or APPS . However, I will still proceed with conducting apps/testing/ostest

Thank you for understanding @zouboan, and for fixing the problem!! :-) We are discussing on the mailing list how to improve testing of hardware related changes, to avoid this kind of breaks in future, that better testing is required, and we should not rush merging because that rush already impacts users and self-compatibility.

Take your time. Lets try out one step deeper verification (i.e. ostest maybe some benchmarks). If you have ideas on what should be part of standard mandatory "selftest" for architecture related changes please share :-)

[anchao]

@anchao please take a look at dev@ mailing list.

@cederom Thank you, I have encountered similar problems before on other RTOS, and I think this change is reasonable. If this fix does not improve the problem, then we can continue to resolve other

[zouboan]

@cederom: Thank you @zouboan :-) Good catch! :-)
Can you also perform apps/testing/ostest and other possible tests to make sure this REG_RESERVED is never used? :-)

@zouboan: Thank you for the reminder. After checking, I found that REG_RESERVED is not used in either NuttX or APPS . However, I will still proceed with conducting apps/testing/ostest

Thank you for understanding @zouboan, and for fixing the problem!! :-) We are discussing on the mailing list how to improve testing of hardware related changes, to avoid this kind of breaks in future, that better testing is required, and we should not rush merging because that rush already impacts users and self-compatibility.

Take your time. Lets try out one step deeper verification (i.e. ostest maybe some benchmarks). If you have ideas on what should be part of standard mandatory "selftest" for architecture related changes please share :-)

I tested 'ostest' 'ping' and 'uname -a', and both tests passed.

ostest:

Final memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena    7fdanxtask_exit: ostest pid=4,TCB=0x15e0b0
a000nxtask_exit: ostest pid=3,TCB=0x15ba08
 7fdaa000
ordblks         1        4
mxordblk 7fd9f838 7fd9b4f8
uordblks     a7c8     d550
fordblks 7fd9f838 7fd9cab0
user_main: Exiting
ostest_main: Exiting with status 0
nsh> 
nsh> 

uname:

nsh> 
nsh> uname -a
NuttX 10.2.0 e5e9032ea0-dirty Feb  3 2025 18:08:46 arm64 zcu111
nsh> 
nsh> 

ping:

nsh>                                                                            
nsh> ping 10.0.0.101                                                            
task_spawn: name=ping entry=0x16561c file_actions=0x1f1ec0 attr=0x1f1ec8 argv=00
spawn_execattrs: Setting policy=2 priority=100 for pid=3                        
nxtask_activate: ping pid=3,TCB=0x1f2868                                        
PING 10.0.0.101 56 bytes of data                                                
56 bytes from 10.0.0.101: icmp_seq=0 time=2.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=1 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=2 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=3 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=4 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=5 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=6 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=7 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=8 time=1.0 ms                                
56 bytes from 10.0.0.101: icmp_seq=9 time=1.0 ms                                
10 packets transmitted, 10 received, 0% packet loss, time 10011 ms              
rtt min/avg/max/mdev = 1.000/1.100/2.000/0.300 ms                               
nxtask_exit: ping pid=3,TCB=0x1f2868      
nsh>     

[cederom]

Thank you @zouboan and @anchao !! After long discussions on the mailing lists the conclusion is to take time and extra caution with critical kernel / architecture changes, as they impact lots of users, we need solid real world hardware runtime evidence triple checked that things are working as expected, which is already done above, thank you so much!! :-)