Cortex-R52 thumb2 question

[fcojavbriceo]

Cortex-R52 thumb2 question

[ajelinski]

Hello @fcojavbriceo, thanks for asking the question!

There are a few issues that result in such unexpected behaviour.

First of all, ELF contains T32 code while Arm Cortex-R52 always is set to execute A32 code after init. This can be changed by setting CPSR’s T32 flag from the Monitor:

(ARM Cortex-R52) cpu CPSR  # check CPSR value
0x400001da
(ARM Cortex-R52) cpu CPSR 0x400001fa  # set T32 flag to 1

Having said that, we could add a more user-friendly helper for this, e.g., cpu Thumb true, so thanks for your report on the issue.

Setting the T32 flag is enough to make a properly loaded T32 code work in Renode. See this example of executing T32 mov r0, #1 instruction with an opcode written directly to memory from the Monitor:

(ARM Cortex-R52) cpu GetRegistersValues
…
|R0    |0x0       |
…
(ARM Cortex-R52) sysbus WriteDoubleWord 0x0 0x0001F04F
(ARM Cortex-R52) cpu ExecutionMode SingleStepBlocking; start; cpu Step
(ARM Cortex-R52) cpu GetRegistersValues
…
|R0    |0x1       |
…

Also, the ELF in question seems to use virtual addressing, whereas Renode by default uses physical ones when loading segments into memory.

Program Headers:
  Type       	Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD       	0x0000a0 0x00100000 0x00000000 0x00008 0x00008 R E 0x4
  LOAD       	0x000000 0x00100008 0x00000000 0x00000 0x100000 RWE 0x8
  LOAD       	0x000000 0x00200008 0x00000000 0x00000 0x100000 RWE 0x8

As you can see from the Renode logs not only all the segments are loaded at 0x0, which is their physical address, but also code, which is loaded first, is overwritten by two other segments (.heap and .stack):

11:29:48.7160 [INFO] sysbus: Loading segment of 8 bytes length at 0x0.
11:29:48.7266 [INFO] sysbus: Loading segment of 1048576 bytes length at 0x0. (2)

This can be resolved by instructing Renode to use virtual addressing with an optional useVirtualAddress argument of sysbus LoadELF.

The last problem is that the entry point address is incorrect since code loaded properly isn’t going to be at 0x0:

ELF Header:
  Entry point address:           	0x0

However, the PC can be set from the Monitor – with cpu PC <address>.

Therefore the ELF provided is simulated properly on Arm Cortex-R52 after changing the LoadELF line to sysbus LoadELF @<ELF_path> true in the scripts/single-node/cortex-r52.resc and issuing these commands from the Monitor:

(monitor) i @scripts/single-node/cortex-r52.resc
(ARM Cortex-R52) cpu CPSR 0x400001fa
(ARM Cortex-R52) cpu PC 0x100000