I'm trying to set a variable to 0x70 and examine the value using jtag debugger.(arm64)
So I set x6 to 0x70 and store the value to the address of myval2.
.global myval
.global myval2
...(skip)
reset:
/* Allow the board to save important registers */
mov x6, #0x70
ldr x7, =myval2
str x6, [x7]
b save_boot_params
...(skip)
.data
myval: .long 0x11111111
myval2: .long 0x22222222
But after supposedly the program has passed above point, when I examine the value of myval and myval2, they are still 0x11111111 and 0x22222222.
But when I did (not sure, similar to this)
ldr x6, myval
ldr x7, =myval2
str x6, [x7]
...(skip)
.data
myval: .long 0x11111111
myval2: .long 0x40025bc
I could see after the point, the two values were both 0x11111111 as I expected (but I can't reproduce it now..).
Why does the first code(mov x6, #0x70) not work? and why does the second code(ldr x6, =myval) not work? Sorry for this stupid looking question. I understand immediate value less than 12 bits can be expressed in one instruction.
==> ADD :
I found through qemu test, it is the str x6, [x7] instruction that isn't working. Even though it is executed, when I examine the address in x7, the value hasn't changed. In what case can this happen? I can see the core is in EL3.
==> UPDATE :
I tried writing to differnet location (last time was to iram area, this time to sdram area(temporarily using iram)) and it worked. so it is not the code problem but a system problem.
While doing experiment with our new SoC this time, I met with the same problem as above. Using qemu, I found out what the problem was in the above assembly.
The problem was, the data declaration
.data
myval: .long 0x11111111
myval2: .long 0x22222222
actually defines 32 bit value 0x11111111 and 0x22222222 as myval and myval2, and the address of myval2 becomes that of the 32bit integer. Because every operation is for 64bits in arm64, the assemby code
ldr x6, myval
ldr x7, =myval2
str x6, [x7]
loads value 0x2222222211111111 to x6, and some 32bit value's address to to x7 (0x40059ac in my case, which is unaligned.. ), and stores the x6 value to that 32 bit value's address (unaligned) so it was not written (it seems so from qemu and actual board's experiment). I found this and fixed the data declaration to
.data
myval: .quad 0x11111111
myval2: .quad 0x22222222
and it runs as I expected!
(the values chaged from 11111111 22222222 to 11111111 11111111)
> mdw 0x640059a0 16
0x640059a0: 00000078 00000000 11111111 00000000 22222222 00000000 72657365 306c6169
0x640059c0: 00000000 00000000 04000870 00000000 00000000 00000000 040008cc 00000000
--> after run
> mdw 0x640059a0 16
0x640059a0: 00000078 00000000 11111111 00000000 11111111 00000000 72657365 306c6169
0x640059c0: 00000000 00000000 04000870 00000000 00000000 00000000 040008cc 00000000