ARM with Qemu

[Nicolas VARONA]

Hi,

Thanks for your answer and your help.

>Could also be the uart issue? But entering jdb always works for me.

Even if I can't give inputs to the bare metal application on Qemu, I can
also enter into the JDB. Is that mean that all interruptions are well
handled? So the uart issue seems more probable.
	
>Which kind of panic?

I firstly tested my L4linux on Qemu for the Zinq board and the boot
finishes well (with the problem of inputs that I told you before).
Nonetheless, with the same image on the board, I have this message:

[...]
Freeing unused kernel memory: 116K (0230f000 - 0232c000)
potentially unexpected fatal signal 11.

CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #152
task: 05c23ac0 ti: 05c26000 task.ti: 05c26000
PC is at 0x0
LR is at 0x0
pc : [<00000000>]    lr : [<00000000>]    psr: 60000010
sp : bf73cef0  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : 00000000
r3 : 0000c50c  r2 : 00000000  r1 : 00000000  r0 : 00000000
vcpu: b3000c00  vcpu-state: 00000001
Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #152
[<0200c9c8>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14)
[<020055e8>] (show_stack) from [<0202844c>]
(get_signal_to_deliver+0x204/0x490)
[<0202844c>] (get_signal_to_deliver) from [<02006be8>]
(do_signal+0x114/0x448)
[<02006be8>] (do_signal) from [<0200a210>]
(l4x_vcpu_entry_c+0xa94/0x1da8)
[<0200a210>] (l4x_vcpu_entry_c) from [<00000000>] (  (null))
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #152
[<0200c9c8>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14)
[<020055e8>] (show_stack) from [<022441a4>] (panic+0x7c/0x1e0)
[<022441a4>] (panic) from [<0201e6a8>] (do_exit+0x708/0x7a0)
[<0201e6a8>] (do_exit) from [<0201e80c>] (do_group_exit+0x3c/0x9c)
[<0201e80c>] (do_group_exit) from [<02028390>]
(get_signal_to_deliver+0x148/0x490)
[<02028390>] (get_signal_to_deliver) from [<02006be8>]
(do_signal+0x114/0x448)
[<02006be8>] (do_signal) from [<0200a210>]
(l4x_vcpu_entry_c+0xa94/0x1da8)
[<0200a210>] (l4x_vcpu_entry_c) from [<00000000>] (  (null))
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b

panic: going to sleep forever, bye
l4linux | panic: going to sleep forever, bye

Thanks in advance for your help,

Nicolas



>Hi,
>
>On Mon Mar 02, 2015 at 15:10:04 +0100, Nicolas VARONA wrote:
>> I am trying to set up a simulator with Qemu and l4linux ARM to 
>> simulate the Zynq board. I have successfully compiled Fiasco and L4 
>> with the tool chain "arm-linux-gnueabi-gcc". I succeeded to launch 
>> l4linux but I have no input on l4linux when it's running on Qemu. 
>> Nevertheless, the fiasco jdb can be invoked. After reading the
mailing 
>> list I changed the hello world program to take inputs and tried a
bare 
>> metal application with l4re with the same result (I didn't modify the
>module list).
>> 
>> So, I tried to do the same thing with the board and I have inputs
with 
>> the l4 bare metal application
>
>So I looked a bit at this and it seems to me that there's something
strange >with uart rx in Qemu, or at least which only shows up in Qemu.
>I need to investigate that further.
>
>> and a kernel panic for the l4linux.
>
>Which kind of panic?
>
>> I boot
>> with the uboot image on it. Nonetheless, using uImage for qemu
doesn't 
>> change anything:
>> 
>> ./qemu-system-arm -M arm-generic-fdt-plnx -m 512M -kernel 
>> /path/bootstrap.uimage -dtb /path/devicetree.dtb -serial mon:stdio
>> 
>> I tried to compile the u-boot from Xilinx and Qemu freezes when I 
>> launch the l4 application.
>
>Could also be the uart issue? But entering jdb always works for me.
>
>> To be sure I have done things right, I also tried the modified hello 
>> world program on x86 intel and it works well. Then I launched a 
>> Petalinux with Qemu and a uImage with uboot and it works.
>> 
>> My Qemu is from Xilinx: QEMU emulator version 2.0.50
>
>Oh, good to know. I tried the normal one.