This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi
Can you clarify what you mean by EL1 handler mode and EL1 context mode
Are your tests run from bare-metal environment (run from A72?) or from linux
Sorry to use a inaccurate description. It should be EL1 handler mode and EL1 thread mode, as defined in ARMv8 TRM "EL1h" and "EL1t". Only when run smc 0x84000009 in EL1 thread mode will cause the cpu halt.
I run this in VxWorks-7 based on U-Boot (A72). However, I think this command is OS independent, because it runs into ATF at last.
Thanks.
Hi
For armv8-a cores(eg. A72), we normally have a EL1 for running OS code, EL2 for hypervisor and EL3 for Secure monitor
EL1 handler and thread modes, i can see for armv8-m cores.
Can you confirm on your intended usage
according to armv8-a, EL1 can use two type SP pointer: SP_EL1 or SP_EL0.
The selected stack pointer can be indicated by a suffix to the Exception level:
t h |
Indicates use of the SP_EL0 stack pointer. Indicates use of the SP_ELx stack pointer |
SP_EL1t uses stack pointer SP_EL0, and SMC 0x84000009 works well.
SP_EL1h uses stack pointer SP_EL1, and SMC 0x84000009 runs to a failure.
Hi
Can you check if the calling method is compatible with ATF - the SMC 0x84000009 call is trapped as PSCI call and serviced through ATF.
Has the VxWorks port been validated for inter-op with ATF on armv8a platform before
Yes, VxWorks use SMC interface is a mature interface on armv8a platform, and as mentioned, it could works well to reset if I didn't disable UART before calling SMC 0x84000009. That is to say, SMC traps into ATF successfully. I am not sure why disabling UART cause it works unsuccessfully.
Hi
So can we confirm if the issue is seen only if UART is disabled before making the SMC call - is there a specific reason why UART has to be disabled before initiating the rest?
I will check on the handling of SCI_SYSTEM_RESET to see if there is an implicit dependency on the UART being enabled for subsequent restart operation
yes, only when in EL1 handler mode, if disable UART before SMC would see this issue.
There is no specific reason to disable UART befor SMC. I just do it as I did on other boards to suspend UART driver before reset.
Thanks
Hi
I confirmed that SCI_SYSTEM_RESET results in full reset and shouldnt have any dependency on the UART disable step.
It shouldnt have made any impact
We have not come across any such issue with our testing so far
Can you live with the workaround to not disable UART before issuing the reset command
We will try and devise a similar test as part of future test scope to see if we can recreate the issue at our end