blob: ad3577427ab9b4315ee67d2029bf20a6dbeded7a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
graphic: 0.927
device: 0.848
instruction: 0.835
semantic: 0.754
network: 0.672
socket: 0.650
mistranslation: 0.563
other: 0.534
boot: 0.500
vnc: 0.498
assembly: 0.480
KVM: 0.222
QEMU doesn't implement ARMv4/v5 legacy SCTLR.U==0 load-and-rotate unaligned access handling
Description of problem:
**ldr r7, \[r0, r1\]** works differently on real device and QEMU. Probably all **ldr Rd, \[Rs\]** commands works wrongly in QEMU with Raspberry Pi emulation.
Steps to reproduce:
1. Launch the attached software **kernel_qemu.img** in QEMU.
2. Launch the attached software **kerenel.img** on real Raspberry Pi 1B+.
3. Look at the r7. It contains different data.
Additional information:
**kernel_qemu.img** and **kerenel.img** are the same program. It just compiled with different origins - 0x8000 for real device and 0x10000 for QEMU. But code inside the program works at the same addresses.
r0 = 0x183a4
r1 = 0x817
**\[r0, r1\]** points to byte 0x42 in memory with such data:
**0x80 0x15 0x22 \[0x42\] 0x03 0x21 0x87**
After **ldr r7, \[r0, r1\]** execution real device puts to r7: **0x22158042**
After **ldr r7, \[r0, r1\]** execution QEMU puts to r7: **0x87210342**
QEMU:
Real Raspberry Pi 1B+: 
[kernel_qemu.img](/uploads/ae6a7490660569d5fe56adc9f4dde85d/kernel_qemu.img) [kernel.img](/uploads/48c94a66370c1fe8720fe89603c45c7b/kernel.img)
|