Since my last email, I managed to get a little closer to my objective, which is to boot a Leon3 Linux Kernel on qemu. Before I continue, I'd like to ask: Is leon3 support broken?
I've stepped on a different error this time. It seems that the kernel is trying to access the 0xf0004000 address, which appears to be virtual - to be more precise, it IS the start position of the kernel virtual address. I expected qemu to translate the address, but it seems to totally ignore it and then the program just receives a SIGABRT and halts. I compiled qemu with -g in order to track the bug and got the following backtrace:
#0 0x00007ffff5d98445 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff5d9bbab in __GI_abort () at abort.c:91
#2 0x00005555557142da in qemu_ram_addr_from_host_nofail (ptr=0x0) at /home/puyol/prog/LSC/qemu-git/exec.c:2812
#3 0x000055555570c46f in get_page_addr_code (env1=0x555556308360, addr=4026548224)
at /home/puyol/prog/LSC/qemu-git/cputlb.c:343
#4 0x0000555555707555 in tb_find_slow (env=0x555556308360, pc=4026548224, cs_base=4026548228, flags=1)
at /home/puyol/prog/LSC/qemu-git/cpu-exec.c:96
#5 0x00005555557077c0 in tb_find_fast (env=0x555556308360) at /home/puyol/prog/LSC/qemu-git/cpu-exec.c:152
#6 0x0000555555707be5 in cpu_sparc_exec (env=0x555556308360) at /home/puyol/prog/LSC/qemu-git/cpu-exec.c:571
#7 0x000055555570ab60 in tcg_cpu_exec (env=0x555556308360) at /home/puyol/prog/LSC/qemu-git/cpus.c:1112
#8 0x000055555570ac78 in tcg_exec_all () at /home/puyol/prog/LSC/qemu-git/cpus.c:1144
#9 0x000055555570a03d in qemu_tcg_cpu_thread_fn (arg=0x555556308360) at /home/puyol/prog/LSC/qemu-git/cpus.c:839
#10 0x00007ffff6126e9a in start_thread (arg=0x7ffff08a3700) at pthread_create.c:308
#11 0x00007ffff5e544bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#12 0x0000000000000000 in ?? ()
Running without GDB gives me the following:
Bad ram pointer (nil)
Aborted (core dumped)
I also executed qemu-system-sparc with -d exec,cpu and got the following output(just a small dump):
Trace 0x41844a60 [400001bc]
pc: f0004000 npc: f0004004
General Registers:
%g0-7: 00000000 f0004000 00000400 00000200 000000c7 00000000 00000000 00000000
Current Register Window:
%o0-7: f00018ec 00000000 00000000 fffffffc 40001370 ffffff64 ffffff00 400001cc
%l0-7: 00000000 00000000 00800000 00000000 00000000 00000000 00000000 00000000
%i0-7: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Floating Point Registers:
%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
psr: f30000c7 (icc: ---- SPE: SP-) wim: 00000001
fsr: 00000000 y: 00000000
The relevant assembly code from the kernel:
400001bc: 03 3c 00 10 sethi %hi(0xf0004000), %g1
400001c0: 81 98 40 00 mov %g1, %tbr
400001c4: 11 3c 00 06 sethi %hi(0xf0001800), %o0
400001c8: b0 10 20 01 mov 1, %i0
400001cc: 9f c0 40 00 call %g1
As you can see in the code, the value 0xf0004000 is copied to %g1 and then a call instruction is executed.
Am I missing something?
Thanks for your time,
--
---------------------------------------------------------------------------------
Erick Luis Moraes de Sousa ~ "Puyol"
Engenharia de Computação 09 - Unicamp