We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I have a very similar question to the resolved entry "reason for ARMv8 EDSCR err bit set".
So I try to follow that to give the state information.
Cortex-57
JTAG TCK = 3,788MHz.
ARM_STATE_AARCH64 is set
Before Halt state:
EDPRSR = 0x1
EDSCR = 0x03007C02
After Halt state:
EDSCR = 0x03006113
After Write to EDITR with opcode 0xd503201f for a NOP instruction:
EDPRSR = 0x11
EDSCR = 0x03006153
EDSCR differs from the resolved entry in bits HDE=1, RW=0100, EL=1
And Aarch64 has no thumb mode instruction, this does not solve my problem.
Any help is appreciated.
Hi kka,
This is strange. So the NOP instruction (0xD503201F) should be OK in debug state when the processor is in AA64, according to sec. H2.4.2 of the Arm Arm v8-AR as NOP is explictly listed under the 'A64 instructions that are unchanged in Debug state' sub-section.
You have HDE set = b1 prior to inserting the instruction into the EDITR so that's ok.
Do other instructions (e.g. MOV x0,#0xA5 (0xD28014A0)) cause the same error, or is it just the NOP ???
Such a MOV <immed> instruction is allowed in debug state so it would be interested to know the result.
Let me know how you are getting on.
Regards,
Stuart
Hi Stuart,
0xD28014A0 gives the same result. However after I've integrated the state check function "armv8_dpm_get_core_state" from openOCD example, right before writing to EDITR, I observe that the state is not AARCH64 anymore. And in that case the instruction is changed into Thumb mode instr. (swapping the word of the instruction) as in example, but which again results in same error.
I think that I should get more info about how these exception levels work.
Best regards,
Koray
Hi Koray,
I see. Yes if the processor is now in AArch32, then you must use 32-but Thumb instructions (T32) in the EDITR. So neither of the previous encodings would work and would result in error.
Regards
Unfortunately, even if I try a T32 instruction, it does not work. There is some other basic mistake I guess.
Yes, sounds like something isn't quite right.
Is debug properly enabled on the target ?
This might give you some hints :
https://developer.arm.com/docs/265510992/10/how-do-i-enable-the-editr-register-in-an-armv8-a-processor
though you may have to look through the OpenOCD code to see which bits it does and which bits you still need to do.....
There are some debug authentication signals that may affect the behaviour here.
For more on Debug Authentication, see the Arm Architecture Reference Manual v8-A, sec. H1.3 ' Required Debug Authentication', available here
Ensure that DBGEN signal is b1, and there are others, depending on which world you are in (secure/non-secure) as they have separately enabled debug capabilities (you may not be able to debug the Secure world, for example, if the SoC vendor has set both SPNIDEN and SPIDEN = b0)
Having said this, if debug authentication was the issue here, I wouldn't expect the core to halt and enter debug state!!
Ok, as you have said, here the initialization is missing some lines, which are relevant for resuming the PC, which are there in openOCD. But other than that the only difference was CTI unlock and this did not help with the problem either.
My DBGAUTHSTATUS_EL1 register reads 0x000000FF, which I understand, that everything should be enabled.