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.