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.
Hi,
On Thu Mar 05, 2015 at 14:37:56 +0100, Nicolas VARONA wrote:
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.
I think I found it. A hacky fix/workaround is to add the following line to the beginning of out_char() in src/lib/uart/uart_cadence.cc: _regs->write<unsigned>(ISR, IXR_RXOVR);
The proper change is different.
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:
It segfaults when executing init. One common reason is that VFP support is missing in Linux. Strike?
Adam
Hi Adam,
It segfaults when executing init. One common reason is that VFP
support is missing in Linux. Strike?
Sorry for answering so late, but I am still looking if it's a problem of the board's hardware configuration. Nonetheless, when I told you the panic, I had already enabled the VFP this way: [...] # # At least one emulation must be selected # CONFIG_FPE_NWFPE=y # CONFIG_FPE_NWFPE_XP is not set # CONFIG_FPE_FASTFPE is not set CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_NEON=y # CONFIG_KERNEL_MODE_NEON is not set (no change even if it's set or not)
Is that correct or do I forget something? I am wondering something: Does l4linux automatically enable FPU on the board's boot when it's enabled in the l4linux configuration?
I think I found it. A hacky fix/workaround is to add the following
line to >the beginning of >out_char() in src/lib/uart/uart_cadence.cc:
_regs->write<unsigned>(ISR, IXR_RXOVR);
Thanks for your help and great work! This was the problem. I have added the line and compiled the Fiasco: Ned says: Hi World! Ned: loading file: 'rom/hello.cfg' Press some key: l Your input: l (108) Enter a number: 4 Your number is: 4
The l4 bare metal application works. Nonetheless I tried to compile the l4linux with the change in the fiasco and I have still no input in Qemu. Is it the same issue for l4linux?
Thanks in advance for your help,
Nicolas
Hi,
On Wed Mar 11, 2015 at 15:59:09 +0100, Nicolas VARONA wrote:
It segfaults when executing init. One common reason is that VFP
support is missing in Linux. Strike?
Sorry for answering so late, but I am still looking if it's a problem of the board's hardware configuration. Nonetheless, when I told you the panic, I had already enabled the VFP this way: [...] # # At least one emulation must be selected # CONFIG_FPE_NWFPE=y # CONFIG_FPE_NWFPE_XP is not set # CONFIG_FPE_FASTFPE is not set CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_NEON=y # CONFIG_KERNEL_MODE_NEON is not set (no change even if it's set or not)
Is that correct or do I forget something? I am wondering something: Does
This looks ok. So it's something different.
l4linux automatically enable FPU on the board's boot when it's enabled in the l4linux configuration?
FPU support also needs to be enabled in Fiasco. I suppose it is? Which ramdisk are you using?
I think I found it. A hacky fix/workaround is to add the following
line to >the beginning of >out_char() in src/lib/uart/uart_cadence.cc:
_regs->write<unsigned>(ISR, IXR_RXOVR);
Thanks for your help and great work! This was the problem. I have added the line and compiled the Fiasco: Ned says: Hi World! Ned: loading file: 'rom/hello.cfg' Press some key: l Your input: l (108) Enter a number: 4 Your number is: 4
The l4 bare metal application works. Nonetheless I tried to compile the l4linux with the change in the fiasco and I have still no input in Qemu. Is it the same issue for l4linux?
Do you have the 'log = L4.Env.log' statement in the script for launching L4Linux? What is Linux telling us about ttyLv0? Do not start anything else which uses 'log = L4.Env.log'.
Adam
Hi Adam,
FPU support also needs to be enabled in Fiasco. I suppose it is?
I had already enabled FPU in Fiasco like this: # # Target configuration # [...] CONFIG_FPU=y # CONFIG_ARM_CPU_ERRATA is not set [...]
This looks ok. So it's something different.
I also checked if the VFP is enabled on the Zynq board and I added those instructions in the u-boot accordingly to the ARM datasheet: MRC p15,0,r0,c1,c0,2 ORR r0,r0,#(3<<20) ORR r0,r0,#(3<<22) BIC r0, r0, #(3<<30) MCR p15,0,r0,c1,c0,2 ISB MOV r0,#(1<<30) VMSR FPEXC,r0
MRC p15,0,r0,c1,c0,2
MOV r3, #0x300000 STR r0, [r3] I checked the CPACR register and the bits look ok. VFP is also enabled on the board. So you are right, it seems to be something else.
Which ramdisk are you using?
I use the ramdisk given in the files in the l4re-snapshot-2014092821: "ramdisk-arm.rd"
Do you have the 'log = L4.Env.log' statement in the script for launching L4Linux? Do not start anything else which uses 'log = L4.Env.log'.
I firstly tested adding this log without commenting the others. I don't have inputs on L4linux with Qemu. So I tried with only the 'log = L4.Env.log'. I have the same result with no input and I still can enter into the JDB. This is the "l4lx.cfg" file I used: -- vim:set ft=lua:
local lxname = "vmlinuz"; if L4.Info.arch() == "arm" then lxname = "vmlinuz.arm"; end
L4.default_loader:start( { caps = { --log = L4.Env.log:m("rws"), }, l4re_dbg = L4.Dbg.Warn, --log = { "l4linux", "yellow" }, log = L4.Env.log, }, "rom/" .. lxname .. " mem=64M console=ttyLv0 l4x_rd=rom/ramdisk-" .. L4.Info.arch() .. ".rd root=1:0 ramdisk_size=4000");
What is Linux telling us about ttyLv0?
During the boot with the configuration file I gave you, I can see: [...] ttyLv0 at MMIO 0x1 (irq = 211, base_baud = 230400) is a L4 [...]
Thanks in advance for your help,
Nicolas
-----Message d'origine----- De : l4-hackers [mailto:l4-hackers-bounces@os.inf.tu-dresden.de] De la part de Adam Lackorzynski Envoyé : lundi 16 mars 2015 00:21 À : l4-hackers@os.inf.tu-dresden.de Objet : Re: ARM with Qemu
Hi,
On Wed Mar 11, 2015 at 15:59:09 +0100, Nicolas VARONA wrote:
It segfaults when executing init. One common reason is that VFP
support is missing in Linux. Strike?
Sorry for answering so late, but I am still looking if it's a problem of the board's hardware configuration. Nonetheless, when I told you the panic, I had already enabled the VFP this way: [...] # # At least one emulation must be selected # CONFIG_FPE_NWFPE=y # CONFIG_FPE_NWFPE_XP is not set # CONFIG_FPE_FASTFPE is not set CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_NEON=y # CONFIG_KERNEL_MODE_NEON is not set (no change even if it's set or not)
Is that correct or do I forget something? I am wondering something: Does
This looks ok. So it's something different.
l4linux automatically enable FPU on the board's boot when it's enabled in the l4linux configuration?
FPU support also needs to be enabled in Fiasco. I suppose it is? Which ramdisk are you using?
I think I found it. A hacky fix/workaround is to add the following
line to >the beginning of >out_char() in src/lib/uart/uart_cadence.cc:
_regs->write<unsigned>(ISR, IXR_RXOVR);
Thanks for your help and great work! This was the problem. I have added the line and compiled the Fiasco: Ned says: Hi World! Ned: loading file: 'rom/hello.cfg' Press some key: l Your input: l (108) Enter a number: 4 Your number is: 4
The l4 bare metal application works. Nonetheless I tried to compile the l4linux with the change in the fiasco and I have still no input in Qemu. Is it the same issue for l4linux?
Do you have the 'log = L4.Env.log' statement in the script for launching L4Linux? What is Linux telling us about ttyLv0? Do not start anything else which uses 'log = L4.Env.log'.
Adam
Hi Nicolas,
On Mon Mar 16, 2015 at 10:41:21 +0100, Nicolas VARONA wrote:
FPU support also needs to be enabled in Fiasco. I suppose it is?
I had already enabled FPU in Fiasco like this:
Ok, good.
I checked the CPACR register and the bits look ok. VFP is also enabled on the board. So you are right, it seems to be something else.
Other issue could be a missing CONFIG_AEABI.
Which ramdisk are you using?
I use the ramdisk given in the files in the l4re-snapshot-2014092821: "ramdisk-arm.rd"
ok.
Do you have the 'log = L4.Env.log' statement in the script for launching L4Linux? Do not start anything else which uses 'log = L4.Env.log'.
I firstly tested adding this log without commenting the others. I don't have inputs on L4linux with Qemu. So I tried with only the 'log = L4.Env.log'. I have the same result with no input and I still can enter into the JDB. This is the "l4lx.cfg" file I used: -- vim:set ft=lua:
local lxname = "vmlinuz"; if L4.Info.arch() == "arm" then lxname = "vmlinuz.arm"; end
You need to have it like this:
L4.default_loader:start( { caps = { log = L4.Env.log:m("rws"), }, }, "rom/" .. lxname .. " mem=64M console=ttyLv0 l4x_rd=rom/ramdisk-" .. L4.Info.arch() .. ".rd root=1:0 ramdisk_size=4000");
But I suppose you tried that already?
What is Linux telling us about ttyLv0?
During the boot with the configuration file I gave you, I can see: [...] ttyLv0 at MMIO 0x1 (irq = 211, base_baud = 230400) is a L4 [...]
That looks fine.
Adam
Hi Adam,
Other issue could be a missing CONFIG_AEABI.
Thanks for your reply and your time. Nonetheless the CONFIG_AEABI is enabled in L4linux:
# # Kernel Features # [...] CONFIG_AEABI=y CONFIG_OABI_COMPAT=y [...]
But I suppose you tried that already?
I have already tried the configuration file this way with the same result (I can reach the end of the boot but I have no input and I can enter into the jdb in Qemu).
Thanks in advance for your help,
Nicolas
-----Message d'origine----- De : l4-hackers [mailto:l4-hackers-bounces@os.inf.tu-dresden.de] De la part de Adam Lackorzynski Envoyé : mardi 17 mars 2015 23:11 À : l4-hackers@os.inf.tu-dresden.de Objet : Re: ARM with Qemu
Hi Nicolas,
On Mon Mar 16, 2015 at 10:41:21 +0100, Nicolas VARONA wrote:
FPU support also needs to be enabled in Fiasco. I suppose it is?
I had already enabled FPU in Fiasco like this:
Ok, good.
I checked the CPACR register and the bits look ok. VFP is also enabled on the board. So you are right, it seems to be something else.
Other issue could be a missing CONFIG_AEABI.
Which ramdisk are you using?
I use the ramdisk given in the files in the l4re-snapshot-2014092821: "ramdisk-arm.rd"
ok.
Do you have the 'log = L4.Env.log' statement in the script for launching L4Linux? Do not start anything else which uses 'log = L4.Env.log'.
I firstly tested adding this log without commenting the others. I don't have inputs on L4linux with Qemu. So I tried with only the 'log = L4.Env.log'. I have the same result with no input and I still can enter into the JDB. This is the "l4lx.cfg" file I used: -- vim:set ft=lua:
local lxname = "vmlinuz"; if L4.Info.arch() == "arm" then lxname = "vmlinuz.arm"; end
You need to have it like this:
L4.default_loader:start( { caps = { log = L4.Env.log:m("rws"), }, }, "rom/" .. lxname .. " mem=64M console=ttyLv0 l4x_rd=rom/ramdisk-" .. L4.Info.arch() .. ".rd root=1:0 ramdisk_size=4000");
But I suppose you tried that already?
What is Linux telling us about ttyLv0?
During the boot with the configuration file I gave you, I can see: [...] ttyLv0 at MMIO 0x1 (irq = 211, base_baud = 230400) is a L4 [...]
That looks fine.
Adam
Hi,
On Wed Mar 18, 2015 at 10:26:46 +0100, Nicolas VARONA wrote:
Other issue could be a missing CONFIG_AEABI.
Thanks for your reply and your time. Nonetheless the CONFIG_AEABI is enabled in L4linux:
Ok. Lets look deeper. Fiasco's debugger has a tracebuffer, we'll use it to find out more. Please make sure 'extended logging' is enabled in Fiasco's config. Then, before it happens, enter the jdb, shift-O will show a selection menu. Enable 'VCPU events' (via return). Let it run further (via 'g'). Then, enter jdb again, shift-T will show up the tracebuffer, latest entry is on the top. What do we see?
But I suppose you tried that already?
I have already tried the configuration file this way with the same result (I can reach the end of the boot but I have no input and I can enter into the jdb in Qemu).
Hmm, maybe lets first look at the segfault, maybe it's related but probably not.
Adam
Hi,
Ok. Lets look deeper. [...] What do we see?
I have done the test on both the board and Qemu. On Qemu, I can see those lines:
jdb: T 5% of 32768 Perf:ACor 1=00000000(:e0) index 2=00000000(:e0) vcpu: 003e exc #11 err=44000000 pc=132cd8 sp=bfbb9c88 state=2f task 1781 vcpu: 003e ret pc=ae3c sp=bfbb9aec state=2f task=D:4c 1780 vcpu: 003e exc #11 err=44000000 pc=b1bc sp=bfbb9c44 state=2f task=D 1779 vcpu: 003e ret pc=b24c sp=bfbb9c2c state=2f task=D:4d 1778 vcpu: 003e exc #11 err=44000000 pc=b24c sp=bfbb9c2c state=2f task=D 1777 vcpu: 003e ret pc=e920 sp=bfbb9c60 state=2f task=D:4d 1776 vcpu: 003e pf pc=e920 pfa=e920 err=80000007 state=2f task=D:4d 1775 vcpu: 003e ret pc=14edd4 sp=bfbb9bc8 state=2f task=D:4d 1774 vcpu: 003e exc #11 err=44000000 pc=14edd4 sp=bfbb9bc8 state=2f task 1773 vcpu: 003e ret pc=dbf0 sp=bfbb9c08 state=2f task=D:4d 1772 vcpu: 003e pf pc=dbf0 pfa=dbf0 err=80000007 state=2f task=D:4d 1771 vcpu: 003e ret pc=127850 sp=bfbb9bd0 state=2f task=D:4d 1770 vcpu: 003e pf pc=127850 pfa=127850 err=80000007 state=2f task=D:4d 1769 vcpu: 003e ret pc=14ee48 sp=bfbb9bd0 state=2f task=D:4d 1768 vcpu: 003e exc #11 err=44000000 pc=b1bc sp=bfbb9c44 state=2f task=D 1767 vcpu: 003e ret pc=b24c sp=bfbb9c2c state=2f task=D:50 1766 vcpu: 003e exc #11 err=44000000 pc=b24c sp=bfbb9c2c state=2f task=D 1765 vcpu: 003e ret pc=b230 sp=bfbb9c30 state=2f task=D:50 1764 vcpu: 003e pf pc=b230 pfa=b230 err=80000007 state=2f task=D:50 1763 vcpu: 003e ret pc=e920 sp=bfbb9c60 state=2f task=D:50 1762 vcpu: 003e pf pc=e920 pfa=e920 err=80000007 state=2f task=D:50 1761 [...]
On the Board I have those:
jdb: T 0% of 32768 Perf:ACor 1=00000000(:e0) index 2=00000000(:e0) vcpu: 003e pf pc=fb86c pfa=bf5b3030 err=90000007 state=2f task=D:4 30 vcpu: 003e ret pc=fb850 sp=bf5b2ee8 state=2f task=D:44 29 vcpu: 003e pf pc=fb850 pfa=fb850 err=80000007 state=2f task=D:44 28 vcpu: 003e ret pc=c4d0 sp=bf5b2ef4 state=2f task=D:44 27 vcpu: 003e pf pc=c4d0 pfa=bf5b2ef0 err=9000084f state=2f task=D:44 26 vcpu: 003e ret pc=c4c8 sp=bf5b2ef0 state=2f task=D:44 25 vcpu: 003e pf pc=c4c8 pfa=bf5b2ef0 err=90000005 state=2f task=D:44 24 vcpu: 003e ret pc=c4c0 sp=bf5b2ef0 state=2f task=D:44 23 vcpu: 003e pf pc=c4c0 pfa=c4c0 err=80000005 state=2f task=D:44 22 vcpu: 003e ret pc=c4c0 sp=bf5b2ef0 state=27 task=D:44 21 vcpu: 003e ret pc=21581d0 sp=5c2787c state=5 task=D:34 20 vcpu: 003e ipc from D:41 task=D:5 sp=5c2787c 19 vcpu: 003e ret pc=2151e38 sp=5c27d44 state=5 task=D:34 18 vcpu: 003e ipc from D:41 task=D:5 sp=5c27d44 17 vcpu: 003e ret pc=208e8c8 sp=5c27e90 state=5 task=D:34 16 vcpu: 003e ipc from D:41 task=D:5 sp=5c27e90 15 vcpu: 003e ret pc=20dcdbc sp=5c27db8 state=5 task=D:34 14 vcpu: 003e ipc from D:41 task=D:5 sp=5c27db8 13 vcpu: 003e ret pc=2157a8c sp=5c27c9c state=5 task=D:34 12 vcpu: 003e ipc from D:41 task=D:5 sp=5c27c9c 11 vcpu: 003e ret pc=2153cd8 sp=5c27d30 state=5 task=D:34 10 [...]
Hmm, maybe lets first look at the segfault, maybe it's related but probably not.
It's strange because all seem to be well enabled and I have the same segfault. I give you the output with the configuration file we tested last time:
[...] Freeing unused kernel memory: 116K (0230f000 - 0232c000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #45
[<0200caa0>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14) [<020055e8>] (show_stack) from [<022441e4>] (panic+0x7c/0x1e0) [<022441e4>] (panic) from [<0201e6d4>] (do_exit+0x708/0x7a0) [<0201e6d4>] (do_exit) from [<0201e838>] (do_group_exit+0x3c/0x9c) [<0201e838>] (do_group_exit) from [<020283bc>] (get_signal_to_deliver+0x148/0x490) [<020283bc>] (get_signal_to_deliver) from [<02006be8>] (do_signal+0x114/0x448) [<02006be8>] (do_signal) from [<02006fc4>] (do_work_pending+0xa8/0xf8) [<02006fc4>] (do_work_pending) from [<02008970>] (l4x_pre_iret_work.isra.24.part.25+0x60/0x100) [<02008970>] (l4x_pre_iret_work.isra.24.part.25) from [<020099f0>] (l4x_vcpu_entry_c+0x274/0x1da8) [<020099f0>] (l4x_vcpu_entry_c) from [<0000c4ec>] (0xc4ec)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
panic: going to sleep forever, bye vmlinuz.| panic: going to sleep forever, bye
Thanks in advance for your help,
Nicolas
-----Message d'origine----- De : l4-hackers [mailto:l4-hackers-bounces@os.inf.tu-dresden.de] De la part de Adam Lackorzynski Envoyé : jeudi 19 mars 2015 23:47 À : l4-hackers@os.inf.tu-dresden.de Objet : Re: ARM with Qemu
Hi,
On Wed Mar 18, 2015 at 10:26:46 +0100, Nicolas VARONA wrote:
Other issue could be a missing CONFIG_AEABI.
Thanks for your reply and your time. Nonetheless the CONFIG_AEABI is enabled in L4linux:
Ok. Lets look deeper. Fiasco's debugger has a tracebuffer, we'll use it to find out more. Please make sure 'extended logging' is enabled in Fiasco's config. Then, before it happens, enter the jdb, shift-O will show a selection menu. Enable 'VCPU events' (via return). Let it run further (via 'g'). Then, enter jdb again, shift-T will show up the tracebuffer, latest entry is on the top. What do we see?
But I suppose you tried that already?
I have already tried the configuration file this way with the same result (I can reach the end of the boot but I have no input and I can enter into the jdb in Qemu).
Hmm, maybe lets first look at the segfault, maybe it's related but probably not.
Adam
Hi,
On Fri Mar 20, 2015 at 11:27:47 +0100, Nicolas VARONA wrote:
Ok. Lets look deeper. [...] What do we see?
I have done the test on both the board and Qemu. On Qemu, I can see those lines:
vcpu: 003e exc #11 err=44000000 pc=132cd8 sp=bfbb9c88 state=2f task 1781
Ok, a syscall, fine.
On the Board I have those:
vcpu: 003e pf pc=fb86c pfa=bf5b3030 err=90000007 state=2f task=D:4 30
A page-fault above the current stack, so that will probably be the cause for the segfault. Does this always happen in this way?
vcpu: 003e ret pc=fb850 sp=bf5b2ee8 state=2f task=D:44 29
Now why. I tried my parallella and it works fine for me. What's your hardware?
[...]
Hmm, maybe lets first look at the segfault, maybe it's related but probably not.
It's strange because all seem to be well enabled and I have the same segfault. I give you the output with the configuration file we tested last time:
On the key issue, you have the -serial_esc option too? For some debugging, you could add a printf to Vkey::trigger() in src/kern/vkey.cpp and see if it prints or not.
Adam
Hi Adam,
A page-fault above the current stack, so that will probably be the cause for the segfault. Does this >always happen in this way?
In fact I have 2 different exitcodes on the board: - exitcode=0x00000004 :
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #50 [<0200caa0>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14) [<020055e8>] (show_stack) from [<022441e4>] (panic+0x7c/0x1e0) [<022441e4>] (panic) from [<0201e6d4>] (do_exit+0x708/0x7a0) [<0201e6d4>] (do_exit) from [<0201e838>] (do_group_exit+0x3c/0x9c) [<0201e838>] (do_group_exit) from [<020283bc>] (get_signal_to_deliver+0x148/0x490) [<020283bc>] (get_signal_to_deliver) from [<02006be8>] (do_signal+0x114/0x448) [<02006be8>] (do_signal) from [<02006fc4>] (do_work_pending+0xa8/0xf8) [<02006fc4>] (do_work_pending) from [<02008970>] (l4x_pre_iret_work.isra.24.part.25+0x60/0x100) [<02008970>] (l4x_pre_iret_work.isra.24.part.25) from [<020099f0>] (l4x_vcpu_entry_c+0x274/0x1da8) [<020099f0>] (l4x_vcpu_entry_c) from [<0000c4ec>] (0xc4ec) ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
- exitcode=0x0000000b:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #50 [<0200caa0>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14) [<020055e8>] (show_stack) from [<022441e4>] (panic+0x7c/0x1e0) [<022441e4>] (panic) from [<0201e6d4>] (do_exit+0x708/0x7a0) [<0201e6d4>] (do_exit) from [<0201e838>] (do_group_exit+0x3c/0x9c) [<0201e838>] (do_group_exit) from [<020283bc>] (get_signal_to_deliver+0x148/0x490) [<020283bc>] (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
Nonetheless, on the trace, it always seems to be the same way and the same task problem. So, with the exitcode 0x00000004 I have:
jdb: T 0% of 32768 Perf:ACor 1=00000000(:e0) index 2=00000000(:e0) vcpu: 003e exc #0 err=0 pc=fb870 sp=bf792ef0 state=2f task=D:44 32 vcpu: 003e ret pc=fb850 sp=bf792ef0 state=2f task=D:44 31 vcpu: 003e pf pc=fb850 pfa=fb850 err=80000007 state=2f task=D:44 30 vcpu: 003e ret pc=c4c0 sp=bf792ef0 state=2f task=D:44 29 vcpu: 003e pf pc=c4c0 pfa=c4c0 err=80000005 state=2f task=D:44 28 vcpu: 003e ret pc=c4c0 sp=bf792ef0 state=27 task=D:44 27 vcpu: 003e ret pc=20a6cc0 sp=5c27e90 state=5 task=D:34 26 vcpu: 003e ipc from D:41 task=D:5 sp=5c27e90 25 vcpu: 003e ret pc=2157a94 sp=5c27984 state=5 task=D:34 24 […]
And with the exitcode 0x0000000b I can see:
jdb: T 0% of 32768 Perf:ACor 1=00000000(:e0) index 2=00000000(:e0) vcpu: 003e pf pc=0 pfa=0 err=80000007 state=2f task=D:44 34 vcpu: 003e ret pc=c4c0 sp=bf66bef0 state=2f task=D:44 33 vcpu: 003e pf pc=c4c0 pfa=c4c0 err=80000005 state=2f task=D:44 32 vcpu: 003e ret pc=c4c0 sp=bf66bef0 state=27 task=D:44 31 vcpu: 003e ret pc=209fa20 sp=5c27e88 state=5 task=D:34 30 vcpu: 003e ipc from D:41 task=D:5 sp=5c27e88 29 vcpu: 003e ret pc=2157a94 sp=5c27d1c state=5 task=D:34 28 […]
Now why. I tried my parallella and it works fine for me. What's your hardware?
I am using the ZedBoard from Digilent.
On the key issue, you have the -serial_esc option too?
On the key issue with Qemu I have tried both with and without the line “kernel fiasco -serial_esc” in the module list with the same result:
modaddr 0x01100000 default-kernel fiasco -serial_esc default-bootstrap bootstrap […] entry L4Linux ARM kernel fiasco -serial_esc roottask moe rom/l4lx.cfg module l4re module ned module l4lx.cfg module io module arm-rv.io module vmlinuz.arm module ramdisk-arm.rd
For some debugging, you could add a printf to Vkey::trigger() in src/kern/vkey.cpp and see if it prints or not.
Something strange happened! I wanted to try if the condition was well done with the “vkey_irq”. So I tried this code:
Vkey::trigger() { //for(int i = 0; i < 10000000; i++); if (vkey_irq){ printf("%x", vkey_irq); vkey_irq->hit(0);} }
And I can enter into the consol with inputs :-) !
Please press Enter to activate this console. f11c8320 / # f11c8320 / # f11c8320 / #
So I tried a few things: - I tried the active loop above for the temporization’s test and I have no inputs: is it an io problem? - So I tried a blank printf(“”) before the writing of the hit to check syscall and still no input. - Finally I tried a printf with a space before the writing of the hit (printf(“ ”)) and I have inputs with the space.
So it seems to be an input format problem.
Thanks in advance for your help,
Nicolas
-----Message d'origine----- De : l4-hackers [mailto:l4-hackers-bounces@os.inf.tu-dresden.de] De la part de Adam Lackorzynski Envoyé : dimanche 22 mars 2015 23:14 À : l4-hackers@os.inf.tu-dresden.de Objet : Re: ARM with Qemu
Hi,
On Fri Mar 20, 2015 at 11:27:47 +0100, Nicolas VARONA wrote:
Ok. Lets look deeper. [...] What do we see?
I have done the test on both the board and Qemu. On Qemu, I can see those lines:
vcpu: 003e exc #11 err=44000000 pc=132cd8 sp=bfbb9c88 state=2f task 1781
Ok, a syscall, fine.
On the Board I have those:
vcpu: 003e pf pc=fb86c pfa=bf5b3030 err=90000007 state=2f task=D:4 30
A page-fault above the current stack, so that will probably be the cause for the segfault. Does this always happen in this way?
vcpu: 003e ret pc=fb850 sp=bf5b2ee8 state=2f task=D:44 29
Now why. I tried my parallella and it works fine for me. What's your hardware?
[...]
Hmm, maybe lets first look at the segfault, maybe it's related but probably not.
It's strange because all seem to be well enabled and I have the same segfault. I give you the output with the configuration file we tested last time:
On the key issue, you have the -serial_esc option too? For some debugging, you could add a printf to Vkey::trigger() in src/kern/vkey.cpp and see if it prints or not.
Adam
Hi,
On Mon Mar 23, 2015 at 16:55:03 +0100, Nicolas VARONA wrote:
A page-fault above the current stack, so that will probably be the cause for the segfault. Does this >always happen in this way?
In fact I have 2 different exitcodes on the board:
- exitcode=0x00000004 :
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #50 [<0200caa0>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14) [<020055e8>] (show_stack) from [<022441e4>] (panic+0x7c/0x1e0) [<022441e4>] (panic) from [<0201e6d4>] (do_exit+0x708/0x7a0) [<0201e6d4>] (do_exit) from [<0201e838>] (do_group_exit+0x3c/0x9c) [<0201e838>] (do_group_exit) from [<020283bc>] (get_signal_to_deliver+0x148/0x490) [<020283bc>] (get_signal_to_deliver) from [<02006be8>] (do_signal+0x114/0x448) [<02006be8>] (do_signal) from [<02006fc4>] (do_work_pending+0xa8/0xf8) [<02006fc4>] (do_work_pending) from [<02008970>] (l4x_pre_iret_work.isra.24.part.25+0x60/0x100) [<02008970>] (l4x_pre_iret_work.isra.24.part.25) from [<020099f0>] (l4x_vcpu_entry_c+0x274/0x1da8) [<020099f0>] (l4x_vcpu_entry_c) from [<0000c4ec>] (0xc4ec) ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
- exitcode=0x0000000b:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #50 [<0200caa0>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14) [<020055e8>] (show_stack) from [<022441e4>] (panic+0x7c/0x1e0) [<022441e4>] (panic) from [<0201e6d4>] (do_exit+0x708/0x7a0) [<0201e6d4>] (do_exit) from [<0201e838>] (do_group_exit+0x3c/0x9c) [<0201e838>] (do_group_exit) from [<020283bc>] (get_signal_to_deliver+0x148/0x490) [<020283bc>] (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
Nonetheless, on the trace, it always seems to be the same way and the same task problem. So, with the exitcode 0x00000004 I have:
jdb: T 0% of 32768 Perf:ACor 1=00000000(:e0) index 2=00000000(:e0) vcpu: 003e exc #0 err=0 pc=fb870 sp=bf792ef0 state=2f task=D:44 32 vcpu: 003e ret pc=fb850 sp=bf792ef0 state=2f task=D:44 31 vcpu: 003e pf pc=fb850 pfa=fb850 err=80000007 state=2f task=D:44 30 vcpu: 003e ret pc=c4c0 sp=bf792ef0 state=2f task=D:44 29 vcpu: 003e pf pc=c4c0 pfa=c4c0 err=80000005 state=2f task=D:44 28 vcpu: 003e ret pc=c4c0 sp=bf792ef0 state=27 task=D:44 27 vcpu: 003e ret pc=20a6cc0 sp=5c27e90 state=5 task=D:34 26 vcpu: 003e ipc from D:41 task=D:5 sp=5c27e90 25 vcpu: 003e ret pc=2157a94 sp=5c27984 state=5 task=D:34 24 […]
And with the exitcode 0x0000000b I can see:
jdb: T 0% of 32768 Perf:ACor 1=00000000(:e0) index 2=00000000(:e0) vcpu: 003e pf pc=0 pfa=0 err=80000007 state=2f task=D:44 34 vcpu: 003e ret pc=c4c0 sp=bf66bef0 state=2f task=D:44 33 vcpu: 003e pf pc=c4c0 pfa=c4c0 err=80000005 state=2f task=D:44 32 vcpu: 003e ret pc=c4c0 sp=bf66bef0 state=27 task=D:44 31 vcpu: 003e ret pc=209fa20 sp=5c27e88 state=5 task=D:34 30 vcpu: 003e ipc from D:41 task=D:5 sp=5c27e88 29 vcpu: 003e ret pc=2157a94 sp=5c27d1c state=5 task=D:34 28 […]
Hmm, interesting.
Now why. I tried my parallella and it works fine for me. What's your hardware?
I am using the ZedBoard from Digilent.
Ok, so I picked the wrong one. But still works for me on this one.
On the key issue, you have the -serial_esc option too?
On the key issue with Qemu I have tried both with and without the line “kernel fiasco -serial_esc” in the module list with the same result:
Something strange happened! I wanted to try if the condition was well done with the “vkey_irq”. So I tried this code:
Vkey::trigger() { //for(int i = 0; i < 10000000; i++); if (vkey_irq){ printf("%x", vkey_irq); vkey_irq->hit(0);} }
And I can enter into the consol with inputs :-) !
Please press Enter to activate this console. f11c8320 / # f11c8320 / # f11c8320 / #
So I tried a few things:
- I tried the active loop above for the temporization’s test and I have no inputs: is it an io problem?
- So I tried a blank printf(“”) before the writing of the hit to check syscall and still no input.
- Finally I tried a printf with a space before the writing of the hit (printf(“ ”)) and I have inputs with the space.
So it seems to be an input format problem.
So something like this is probably more weird. Which compiler do you use? Could you try this image? http://os.inf.tu-dresden.de/~adam/dl/bootstrap-zedboard-l4linux.raw It works just fine for me. I could also try / have a look at your image. Send via PM.
Adam
Hi l4Hackers,
This post is to sum up and expose the solution of my problem. But before everything, thanks a lot to Adam Lackorzynski which took a lot of time helping me.
Briefly I sum up the initial problem:
My initial configuration was: Qemu from Xilinx: QEMU emulator version 2.0.50 Ubuntu 14.04.1 LTS and x86-32bit Toolchain : gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) or "arm-linux-gnueabi-gcc" on aptitude
With the same Image of L4linux I had no input on Qemu and a kernel panic on the Zynq board. Then, after a bare metal test with Fiasco, I had no input on Qemu but it worked on the board.
To conclude, the Adam's fix of the Fiasco is added below. But the kernel panic was due to the toolchain I used for the cross compilation.
My final configuration was: Qemu from Xilinx: QEMU emulator version 2.0.50 Ubuntu 14.04.1 LTS and x86-32bit Toolchain : 1)gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) or "arm-linux-gnueabihf-gcc" on aptitude or 2)gcc version 4.7.1 20120402 (prerelease) (crosstool-NG linaro-1.13.1-2012.04-20120426 - Linaro GCC 2012.04) from linaro (arm-linux-gnueabi-gcc). or 3)gcc version 4.8.2 20131014 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) from linaro (arm-linux-gnueabihf-gcc)
Thanks a lot,
Nicolas
############################################## FIX ############################################## Index: src/drivers/uart.cpp =================================================================== --- src/drivers/uart.cpp (revision 66) +++ src/drivers/uart.cpp (working copy) @@ -61,6 +61,10 @@ * (abstract) Get the IRQ assigned to the port. */ int irq() const; + + /** + * (abstract) Acknowledge UART interrupt. + */ void irq_ack();
Address base() const; @@ -114,11 +118,6 @@ return UART | IN | OUT; }
-IMPLEMENT_DEFAULT -void -Uart::irq_ack() -{} -
//---------------------------------------------------------------------- ----- INTERFACE [libuart]:
@@ -202,3 +201,15 @@ uart()->enable_rx_irq(false); }
+IMPLEMENT +void Uart::irq_ack() +{ + uart()->irq_ack(); +} + +//--------------------------------------------------------------------- ------ +IMPLEMENTATION [!libuart]: + +IMPLEMENT_DEFAULT +void Uart::irq_ack() +{} Index: src/lib/uart/uart_base.h =================================================================== --- src/lib/uart/uart_base.h (revision 66) +++ src/lib/uart/uart_base.h (working copy) @@ -33,6 +33,8 @@ virtual int char_avail() const = 0; virtual int write(char const *s, unsigned long count) const = 0;
+ virtual void irq_ack() {} + virtual bool enable_rx_irq(bool = true) { return false; } Transfer_mode mode() const { return _mode; } Baud_rate rate() const { return _rate; } Index: src/lib/uart/uart_cadence.cc =================================================================== --- src/lib/uart/uart_cadence.cc (revision 66) +++ src/lib/uart/uart_cadence.cc (working copy) @@ -117,4 +117,9 @@
return count; } + + void Uart_cadence::irq_ack() + { + _regs->write<unsigned>(ISR, IXR_RXOVR); + } }; Index: src/lib/uart/uart_cadence.h =================================================================== --- src/lib/uart/uart_cadence.h (revision 66) +++ src/lib/uart/uart_cadence.h (working copy) @@ -23,5 +23,6 @@ int char_avail() const; inline void out_char(char c) const; int write(char const *s, unsigned long count) const; + void irq_ack(); }; };
l4-hackers@os.inf.tu-dresden.de