I have some patches which I'll post shortly which fix QEMU crashing on
attempts to write to the ROM. However this doesn't cause your test
binary to work. What happens is that we start executing "instructions"
from the start of this binary blob, but it looks like this is actually
data:
0x10010000: 402000d1 ldrdmi r0, [r0], -r1
0x10010004: 17800000 strne r0, [r0, r0]
0x10010008: 00000000 andeq r0, r0, r0
0x1001000c: 177ff42c ldrbne pc, [pc, -ip, lsr #8]!
0x10010010: 177ff420 ldrbne pc, [pc, -r0, lsr #8]!
0x10010014: 177ff400 ldrbne pc, [pc, -r0, lsl #8]!
0x10010018: 00000000 andeq r0, r0, r0
0x1001001c: 00000000 andeq r0, r0, r0
0x10010020: 177ff000 ldrbne pc, [pc, -r0]!
0x10010024: 00065000 andeq r5, r6, r0
0x10010028: 00000000 andeq r0, r0, r0
0x1001002c: 40f002d2 ldrsbtmi r0, [r0], #34
0x10010030: 04ec02cc strbteq r0, [ip], #716
0x10010034: 74070e02 strvc r0, [r7], #-3586
0x10010038: 00000c00 andeq r0, r0, r0, lsl #24
0x1001003c: 54070e02 strpl r0, [r7], #-3586
0x10010040: 00000000 andeq r0, r0, r0
0x10010044: ac040e02 stcge 14, cr0, [r4], {2}
Eventually we get to that 'stcge', which isn't a valid instruction for a
Cortex-A9, and causes an UNDEF exception. We take the exception to the usual
UNDEF vector, where there is no code:
0x00000004: 00000000 andeq r0, r0, r0
0x00000008: 00000000 andeq r0, r0, r0
0x0000000c: 00000000 andeq r0, r0, r0
0x00000010: 00000000 andeq r0, r0, r0
and continue to execute NOPs through the whole of this empty ROM until we get
to the end of it:
0x00017ff8: 00000000 andeq r0, r0, r0
0x00017ffc: 00000000 andeq r0, r0, r0
at which point we hit the usual "trying to execute code outside RAM or
ROM" error:
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00018000
R00=00000000 R01=ffffffff R02=10000100 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=ffffe3fc
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=000002cc R13=00000000 R14=10010048 R15=00018000
PSR=400001db -Z-- A S und32
So the underlying problem here is that the thing you're passing to -kernel is
neither (1) a Linux kernel nor (2) an ELF format binary, which is what -kernel
is expecting.
thanks
-- PMM
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1596160
Title:
SIGSEGV in memory_region_access_valid on Sabre Lite board
Status in QEMU:
New
Bug description:
I'm trying to emulate a Sabre Lite board and booting U-Boot, but I'm
encountering a SIGSEGV almost immediately after starting QEMU.
QEMU version: 6f1d2d1c5ad20d464705b17318cb7ca495f8078a
U-Boot version: mx6qsabrelite_defconfig 2016.05 (with
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=1f516faa45611aedc8c2e3f303b3866f615d481e
reverted, since it hangs the CPU)
$ gdb --args ./arm-softmmu/qemu-system-arm -machine sabrelite -kernel
~/u-boot-2016.05/u-boot
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
...
(gdb) r
Starting program: /home/kota/qemu/build/arm-softmmu/qemu-system-arm -machine
sabrelite -kernel /home/kota/u-boot-2016.05/u-boot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe9074700 (LWP 18025)]
[New Thread 0x7fffe58c0700 (LWP 18027)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe58c0700 (LWP 18027)]
0x00005555557aaaa8 in memory_region_access_valid (mr=mr@entry=0x7fffe594e0e0,
addr=addr@entry=0, size=size@entry=4, is_write=is_write@entry=true) at
/home/kota/qemu/memory.c:1143
1143 if (!mr->ops->valid.unaligned && (addr & (size - 1))) {
(gdb) print mr->ops
$1 = (const MemoryRegionOps *) 0x0
(gdb) print *mr
$2 = {parent_obj = {class = 0x555556678990, free = 0x0, properties =
0x555557002d20, ref = 1, parent = 0x555556693d10}, romd_mode = true, ram =
false, subpage = false, readonly = false, rom_device = true,
flush_coalesced_mmio = false, global_locking = true, dirty_log_mask = 0
'\000', ram_block = 0x5555570228f0, owner = 0x0, iommu_ops = 0x0, ops = 0x0,
opaque = 0x0, container = 0x555556693980, size = {
lo = 98304, hi = 0}, addr = 0, destructor = 0x5555557a70b0
<memory_region_destructor_rom_device>, align = 2097152, terminates = true,
skip_dump = false, enabled = true, warning_printed = false,
vga_logging_count = 0 '\000', alias = 0x0, alias_offset = 0, priority = 0,
subregions = {tqh_first = 0x0, tqh_last = 0x7fffe594e188}, subregions_link =
{tqe_next = 0x7fffe594d988, tqe_prev = 0x7fffe594e290},
coalesced = {tqh_first = 0x0, tqh_last = 0x7fffe594e1a8}, name =
0x555557022710 "imx6.rom", ioeventfd_nb = 0, ioeventfds = 0x0, iommu_notify =
{notifiers = {lh_first = 0x0}}}
(gdb) bt
#0 0x00005555557aaaa8 in memory_region_access_valid
(mr=mr@entry=0x7fffe594e0e0, addr=addr@entry=0, size=size@entry=4,
is_write=is_write@entry=true) at /home/kota/qemu/memory.c:1143
#1 0x00005555557aacbd in memory_region_dispatch_write (mr=0x7fffe594e0e0,
addr=0, data=3925868734, size=4, attrs=...) at /home/kota/qemu/memory.c:1249
#2 0x00007fffe645a4e4 in code_gen_buffer ()
#3 0x0000555555778d4d in cpu_tb_exec (itb=<optimized out>, itb=<optimized
out>, cpu=0x7fffe58c92e0) at /home/kota/qemu/cpu-exec.c:166
#4 cpu_loop_exec_tb (sc=0x7fffe58bfab0, tb_exit=<synthetic pointer>,
last_tb=0x7fffe58bfaa0, tb=<optimized out>, cpu=0x7fffe58c92e0) at
/home/kota/qemu/cpu-exec.c:530
#5 cpu_arm_exec (cpu=cpu@entry=0x7fffe58c1080) at
/home/kota/qemu/cpu-exec.c:626
#6 0x0000555555798a20 in tcg_cpu_exec (cpu=0x7fffe58c1080) at
/home/kota/qemu/cpus.c:1541
#7 tcg_exec_all () at /home/kota/qemu/cpus.c:1574
#8 qemu_tcg_cpu_thread_fn (arg=<optimized out>) at
/home/kota/qemu/cpus.c:1171
#9 0x00007ffff27f1184 in start_thread (arg=0x7fffe58c0700) at
pthread_create.c:312
#10 0x00007ffff251e37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1596160/+subscriptions
