Hello l4hackers,
I'm trying to execute Fiasco.OC along with the hello module using qemu and the vexpress machine model. For both A9 and A15 cpus the system hangs at "Starting kernel fiasco". It seems that something (the UART driver?) prevents the system to log the kernel boot to the screen.
I compiled the image using 'make qemu' in L4RE, and the vm is executed with the argument -nographic.
Can you confirm this? Do you have any suggestion to solve it?
Here below you can find the log of the A15 boot process:
L4 Bootstrapper Build: #2 Thu Apr 10 12:50:53 CEST 2014, 4.6.3 Scanning up to 256 MB RAM Memory size is 256MB (80000000 - 8fffffff) RAM: 0000000080000000 - 000000008fffffff: 262144kB Total RAM: 256MB mod04: 810bc000-810d5580: hello mod03: 810a2000-810bb460: l4re mod02: 81070000-810a162c: moe mod01: 81066000-8106f344: sigma0 mod00: 81014000-810652e0: fiasco Moving up to 5 modules behind 81100000 moving module 00 { 81014000-810652df } -> { 811c2000-812132df } [332512] moving module 01 { 81066000-8106f343 } -> { 81214000-8121d343 } [37700] moving module 02 { 81070000-810a162b } -> { 8121e000-8124f62b } [202284] moving module 03 { 810a2000-810bb45f } -> { 81100000-8111945f } [103520] moving module 04 { 810bc000-810d557f } -> { 8111a000-8113357f } [103808] Scanning fiasco -serial_esc Scanning sigma0 Scanning moe --init=rom/hello Relocated mbi to [0x8100d000-0x8100d0e2] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x80002000 Regions of list 'regions' [ 80001000, 80001cbf] { cc0} Kern fiasco [ 80002000, 8005efff] { 5d000} Kern fiasco [ 80090000, 800963c3] { 63c4} Sigma0 sigma0 [ 80098000, 8009e17b] { 617c} Sigma0 sigma0 [ 80140000, 8016ba6b] { 2ba6c} Root moe [ 80170000, 80186f0f] { 16f10} Root moe [ 81000000, 810133f7] { 133f8} Boot bootstrap [ 81009000, 810090a6] { a7} Boot mbi [ 8100d000, 8100d1df] { 1e0} Root Multiboot info [ 8101304c, 810130a3] { 58} Boot mbi [ 81100000, 8113357f] { 33580} Root Module API Version: (87) experimental Sigma0 config ip:80090100 sp:81012de4 Roottask config ip:801401a0 sp:00000000 Starting kernel fiasco at 800013b0
Regards, Michele Paolino
Hi,
On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote:
I'm trying to execute Fiasco.OC along with the hello module using qemu and the vexpress machine model. For both A9 and A15 cpus the system hangs at "Starting kernel fiasco". It seems that something (the UART driver?) prevents the system to log the kernel boot to the screen.
I compiled the image using 'make qemu' in L4RE, and the vm is executed with the argument -nographic.
Can you confirm this? Do you have any suggestion to solve it?
Here below you can find the log of the A15 boot process:
Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick up the right Fiasco binary, i.e. that one configured for vexpress-a15?
Adam
Hello Adam,
On 14/04/2014 23:53, Adam Lackorzynski wrote:
Hi,
On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote:
I'm trying to execute Fiasco.OC along with the hello module using qemu and the vexpress machine model. For both A9 and A15 cpus the system hangs at "Starting kernel fiasco". It seems that something (the UART driver?) prevents the system to log the kernel boot to the screen.
I compiled the image using 'make qemu' in L4RE, and the vm is executed with the argument -nographic.
Can you confirm this? Do you have any suggestion to solve it?
Here below you can find the log of the A15 boot process:
Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick up the right Fiasco binary, i.e. that one configured for vexpress-a15?
Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the following:
Image size(s) in bytes: bootstrap_hello.elf: 917888 Start address: 0x81000000 --> Build-Nr: 2 QEmu-cmd: qemu-system-arm -kernel /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf -nographic -M vexpress-a15 -m 256
And soon after the log of the boot is exactly the one I posted before. I assume that what is in build/images/ is the right binary (bootstrap.elf is a symbolic link to build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check elsewhere?
ps: I tried to investigate about the status of the CPU registers using GDB, the info all-registers command returns always the same value for all the registers.
Regards, Michele
Adam
On Tue Apr 15, 2014 at 17:26:36 +0200, Michele Paolino wrote:
Hello Adam,
On 14/04/2014 23:53, Adam Lackorzynski wrote:
Hi,
On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote:
I'm trying to execute Fiasco.OC along with the hello module using qemu and the vexpress machine model. For both A9 and A15 cpus the system hangs at "Starting kernel fiasco". It seems that something (the UART driver?) prevents the system to log the kernel boot to the screen.
I compiled the image using 'make qemu' in L4RE, and the vm is executed with the argument -nographic.
Can you confirm this? Do you have any suggestion to solve it?
Here below you can find the log of the A15 boot process:
Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick up the right Fiasco binary, i.e. that one configured for vexpress-a15?
Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the following:
Image size(s) in bytes: bootstrap_hello.elf: 917888 Start address: 0x81000000 --> Build-Nr: 2
QEmu-cmd: qemu-system-arm -kernel /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf -nographic -M vexpress-a15 -m 256
And soon after the log of the boot is exactly the one I posted before. I assume that what is in build/images/ is the right binary (bootstrap.elf is a symbolic link to build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check elsewhere?
I'd suspect that Fiasco could be wrongly configured, that's why I was asking whether the build process picked up the right Fiasco image that has been also configured for this target.
ps: I tried to investigate about the status of the CPU registers using GDB, the info all-registers command returns always the same value for all the registers.
Please show them, they might tell me something :)
Adam
Hello Adam,
On 15/04/2014 23:33, Adam Lackorzynski wrote:
On Tue Apr 15, 2014 at 17:26:36 +0200, Michele Paolino wrote:
Hello Adam,
On 14/04/2014 23:53, Adam Lackorzynski wrote:
Hi,
On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote:
I'm trying to execute Fiasco.OC along with the hello module using qemu and the vexpress machine model. For both A9 and A15 cpus the system hangs at "Starting kernel fiasco". It seems that something (the UART driver?) prevents the system to log the kernel boot to the screen.
I compiled the image using 'make qemu' in L4RE, and the vm is executed with the argument -nographic.
Can you confirm this? Do you have any suggestion to solve it?
Here below you can find the log of the A15 boot process:
Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick up the right Fiasco binary, i.e. that one configured for vexpress-a15?
Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the following:
Image size(s) in bytes: bootstrap_hello.elf: 917888 Start address: 0x81000000 --> Build-Nr: 2 QEmu-cmd: qemu-system-arm -kernel /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf -nographic -M vexpress-a15 -m 256
And soon after the log of the boot is exactly the one I posted before. I assume that what is in build/images/ is the right binary (bootstrap.elf is a symbolic link to build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check elsewhere?
I'd suspect that Fiasco could be wrongly configured, that's why I was asking whether the build process picked up the right Fiasco image that has been also configured for this target.
ps: I tried to investigate about the status of the CPU registers using GDB, the info all-registers command returns always the same value for all the registers.
Please show them, they might tell me something :)
Sure. This is the log:
(gdb) target remote :1234 Remote debugging using :1234 0xffff000c in ?? () (gdb) info all-registers r0 0x1c 28 r1 0x2 2 r2 0x2 2 r3 0xffffffff -1 r4 0x0 0 r5 0x9000200b -1879039989 r6 0xc53c7f 12926079 r7 0x0 0 r8 0x80059cc0 -2147115840 r9 0x55555555 1431655765 r10 0x0 0 r11 0x80002500 -2147474176 r12 0x0 0 sp 0x0 0x0 lr 0xffff0010 -65520 pc 0xffff000c 0xffff000c cpsr 0x600001d7 1610613207 d0 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d1 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d2 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d3 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d4 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d5 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d6 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d7 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d8 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d9 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d10 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d11 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d12 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d13 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d14 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d15 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d16 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d17 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d18 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d19 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d20 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d21 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d22 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d23 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d24 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d25 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d26 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d27 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d28 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d29 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d30 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} d31 {u8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u16 = {0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0}, u64 = 0x0, f32 = {0x0, 0x0}, f64 = 0x0} fpscr 0x0 0 q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q8 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q9 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q10 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q10 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q12 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q13 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q14 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q15 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} fpsid 0x410430f0 1090793712 fpexc 0x0 0 s0 0 (raw 0x00000000) .. s31 0 (raw 0x00000000)
Adam
Thanks,
Hi,
On Wed Apr 16, 2014 at 13:03:44 +0200, Michele Paolino wrote:
On 15/04/2014 23:33, Adam Lackorzynski wrote:
On Tue Apr 15, 2014 at 17:26:36 +0200, Michele Paolino wrote:
Hello Adam,
On 14/04/2014 23:53, Adam Lackorzynski wrote:
Hi,
On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote:
I'm trying to execute Fiasco.OC along with the hello module using qemu and the vexpress machine model. For both A9 and A15 cpus the system hangs at "Starting kernel fiasco". It seems that something (the UART driver?) prevents the system to log the kernel boot to the screen.
I compiled the image using 'make qemu' in L4RE, and the vm is executed with the argument -nographic.
Can you confirm this? Do you have any suggestion to solve it?
Here below you can find the log of the A15 boot process:
Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick up the right Fiasco binary, i.e. that one configured for vexpress-a15?
Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the following:
Image size(s) in bytes: bootstrap_hello.elf: 917888 Start address: 0x81000000 --> Build-Nr: 2
QEmu-cmd: qemu-system-arm -kernel /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf -nographic -M vexpress-a15 -m 256
And soon after the log of the boot is exactly the one I posted before. I assume that what is in build/images/ is the right binary (bootstrap.elf is a symbolic link to build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check elsewhere?
I'd suspect that Fiasco could be wrongly configured, that's why I was asking whether the build process picked up the right Fiasco image that has been also configured for this target.
ps: I tried to investigate about the status of the CPU registers using GDB, the info all-registers command returns always the same value for all the registers.
Please show them, they might tell me something :)
Sure. This is the log:
(gdb) target remote :1234 Remote debugging using :1234 0xffff000c in ?? () (gdb) info all-registers r0 0x1c 28 r1 0x2 2 r2 0x2 2 r3 0xffffffff -1 r4 0x0 0 r5 0x9000200b -1879039989 r6 0xc53c7f 12926079 r7 0x0 0 r8 0x80059cc0 -2147115840 r9 0x55555555 1431655765 r10 0x0 0 r11 0x80002500 -2147474176 r12 0x0 0 sp 0x0 0x0 lr 0xffff0010 -65520 pc 0xffff000c 0xffff000c cpsr 0x600001d7 1610613207
So it page-faulted. Could you show me the globalconfig.out out of the Fiasco build-dir?
Adam
Hi,
On 17/04/2014 00:02, Adam Lackorzynski wrote:
Hi,
On Wed Apr 16, 2014 at 13:03:44 +0200, Michele Paolino wrote:
On 15/04/2014 23:33, Adam Lackorzynski wrote:
On Tue Apr 15, 2014 at 17:26:36 +0200, Michele Paolino wrote:
Hello Adam,
On 14/04/2014 23:53, Adam Lackorzynski wrote:
Hi,
On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote:
I'm trying to execute Fiasco.OC along with the hello module using qemu and the vexpress machine model. For both A9 and A15 cpus the system hangs at "Starting kernel fiasco". It seems that something (the UART driver?) prevents the system to log the kernel boot to the screen.
I compiled the image using 'make qemu' in L4RE, and the vm is executed with the argument -nographic.
Can you confirm this? Do you have any suggestion to solve it?
Here below you can find the log of the A15 boot process:
Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick up the right Fiasco binary, i.e. that one configured for vexpress-a15?
Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the following:
Image size(s) in bytes: bootstrap_hello.elf: 917888 Start address: 0x81000000 --> Build-Nr: 2 QEmu-cmd: qemu-system-arm -kernel /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf -nographic -M vexpress-a15 -m 256
And soon after the log of the boot is exactly the one I posted before. I assume that what is in build/images/ is the right binary (bootstrap.elf is a symbolic link to build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check elsewhere?
I'd suspect that Fiasco could be wrongly configured, that's why I was asking whether the build process picked up the right Fiasco image that has been also configured for this target.
ps: I tried to investigate about the status of the CPU registers using GDB, the info all-registers command returns always the same value for all the registers.
Please show them, they might tell me something :)
Sure. This is the log:
(gdb) target remote :1234 Remote debugging using :1234 0xffff000c in ?? () (gdb) info all-registers r0 0x1c 28 r1 0x2 2 r2 0x2 2 r3 0xffffffff -1 r4 0x0 0 r5 0x9000200b -1879039989 r6 0xc53c7f 12926079 r7 0x0 0 r8 0x80059cc0 -2147115840 r9 0x55555555 1431655765 r10 0x0 0 r11 0x80002500 -2147474176 r12 0x0 0 sp 0x0 0x0 lr 0xffff0010 -65520 pc 0xffff000c 0xffff000c cpsr 0x600001d7 1610613207
So it page-faulted. Could you show me the globalconfig.out out of the Fiasco build-dir?
Adam
This is the globalconfig file:
# # Automatically generated file; DO NOT EDIT. # Fiasco configuration #
# # Target configuration # # CONFIG_IA32 is not set # CONFIG_AMD64 is not set CONFIG_ARM=y # CONFIG_PF_IMX is not set CONFIG_PF_REALVIEW=y # CONFIG_PF_S3C2410 is not set # CONFIG_PF_TEGRA is not set # CONFIG_PF_OMAP is not set # CONFIG_PF_SA1100 is not set # CONFIG_PF_XSCALE is not set # CONFIG_PF_EXYNOS is not set # CONFIG_PF_KIRKWOOD is not set # CONFIG_PF_INTEGRATOR is not set # CONFIG_PF_BCM2835 is not set CONFIG_BSP_NAME="realview" # CONFIG_PF_REALVIEW_EB is not set # CONFIG_PF_REALVIEW_PB11MP is not set # CONFIG_PF_REALVIEW_PBX is not set CONFIG_PF_REALVIEW_VEXPRESS=y CONFIG_PF_REALVIEW_VEXPRESS_A15=y CONFIG_PF_REALVIEW_RAM_PHYS_BASE_0x8=y CONFIG_PF_REALVIEW_RAM_PHYS_BASE=0x80000000 CONFIG_ABI_VF=y CONFIG_PF_ARM_MP_CAPABLE=y CONFIG_CAN_ARM_CPU_CORTEX_A9=y CONFIG_CAN_ARM_CPU_CORTEX_A15=y # CONFIG_ARM_CORTEX_A9 is not set CONFIG_ARM_CORTEX_A15=y # CONFIG_ARM_ALIGNMENT_CHECK is not set CONFIG_ARM_EM_STD=y # CONFIG_ARM_EM_NS is not set # CONFIG_ARM_EM_TZ is not set # CONFIG_ARM_ENABLE_SWP is not set # CONFIG_ARM_LPAE is not set # CONFIG_FPU is not set # CONFIG_ARM_CPU_ERRATA is not set
# # Kernel options # # CONFIG_MP is not set CONFIG_CONTEXT_4K=y # CONFIG_FINE_GRAINED_CPUTIME is not set CONFIG_SCHED_FIXED_PRIO=y CONFIG_VIRT_OBJ_SPACE=y
# # Debugging # CONFIG_INLINE=y # CONFIG_NDEBUG is not set CONFIG_NO_FRAME_PTR=y # CONFIG_STACK_DEPTH is not set # CONFIG_LIST_ALLOC_SANITY is not set CONFIG_SERIAL=y CONFIG_JDB=y # CONFIG_JDB_LOGGING is not set # CONFIG_JDB_DISASM is not set # CONFIG_JDB_GZIP is not set # CONFIG_VMEM_ALLOC_TEST is not set # CONFIG_DEBUG_KERNEL_PAGE_FAULTS is not set # CONFIG_WARN_NONE is not set CONFIG_WARN_WARNING=y # CONFIG_WARN_ANY is not set
# # Compiling # CONFIG_CC="gcc" CONFIG_CXX="g++" CONFIG_HOST_CC="gcc" CONFIG_HOST_CXX="g++" # CONFIG_MAINTAINER_MODE is not set CONFIG_LABEL="" # CONFIG_EXPERIMENTAL is not set CONFIG_PERF_CNT=y CONFIG_BIT32=y CONFIG_ARM_V7=y CONFIG_ARM_V6PLUS=y CONFIG_WARN_LEVEL=1 CONFIG_XARCH="arm" CONFIG_ABI="vf"
I tried several configurations, for example I added the following
< CONFIG_ARM_ALIGNMENT_CHECK=y < CONFIG_ARM_ENABLE_SWP=y < CONFIG_ARM_LPAE=y < CONFIG_FPU=y < CONFIG_ARM_CPU_ERRATA=y
to the config file, but it doesn't solve the problem. In the meantime I'm checking the vexpress memory map in the directory kernel/fiasco/src/kern/arm, but everything looks good to me. Is there anyone who actually uses FIASCO with this configuration?
Regards,
Hi,
On Thu Apr 17, 2014 at 13:01:18 +0200, Michele Paolino wrote:
On 17/04/2014 00:02, Adam Lackorzynski wrote:
On Wed Apr 16, 2014 at 13:03:44 +0200, Michele Paolino wrote:
On 15/04/2014 23:33, Adam Lackorzynski wrote:
On Tue Apr 15, 2014 at 17:26:36 +0200, Michele Paolino wrote:
Hello Adam,
On 14/04/2014 23:53, Adam Lackorzynski wrote:
Hi,
On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote: >I'm trying to execute Fiasco.OC along with the hello module using qemu and >the vexpress machine model. For both A9 and A15 cpus the system hangs at >"Starting kernel fiasco". It seems that something (the UART driver?) >prevents the system to log the kernel boot to the screen. > >I compiled the image using 'make qemu' in L4RE, and the vm is executed with >the argument -nographic. > >Can you confirm this? Do you have any suggestion to solve it? > >Here below you can find the log of the A15 boot process: Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick up the right Fiasco binary, i.e. that one configured for vexpress-a15?
Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the following:
Image size(s) in bytes: bootstrap_hello.elf: 917888 Start address: 0x81000000 --> Build-Nr: 2
QEmu-cmd: qemu-system-arm -kernel /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf -nographic -M vexpress-a15 -m 256
And soon after the log of the boot is exactly the one I posted before. I assume that what is in build/images/ is the right binary (bootstrap.elf is a symbolic link to build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check elsewhere?
I'd suspect that Fiasco could be wrongly configured, that's why I was asking whether the build process picked up the right Fiasco image that has been also configured for this target.
ps: I tried to investigate about the status of the CPU registers using GDB, the info all-registers command returns always the same value for all the registers.
Please show them, they might tell me something :)
Sure. This is the log:
(gdb) target remote :1234 Remote debugging using :1234 0xffff000c in ?? () (gdb) info all-registers r0 0x1c 28 r1 0x2 2 r2 0x2 2 r3 0xffffffff -1 r4 0x0 0 r5 0x9000200b -1879039989 r6 0xc53c7f 12926079 r7 0x0 0 r8 0x80059cc0 -2147115840 r9 0x55555555 1431655765 r10 0x0 0 r11 0x80002500 -2147474176 r12 0x0 0 sp 0x0 0x0 lr 0xffff0010 -65520 pc 0xffff000c 0xffff000c cpsr 0x600001d7 1610613207
So it page-faulted. Could you show me the globalconfig.out out of the Fiasco build-dir?
This is the globalconfig file:
[...]
I tried several configurations, for example I added the following
< CONFIG_ARM_ALIGNMENT_CHECK=y < CONFIG_ARM_ENABLE_SWP=y < CONFIG_ARM_LPAE=y < CONFIG_FPU=y < CONFIG_ARM_CPU_ERRATA=y
to the config file, but it doesn't solve the problem. In the meantime I'm checking the vexpress memory map in the directory kernel/fiasco/src/kern/arm, but everything looks good to me. Is there anyone who actually uses FIASCO with this configuration?
It's among the platforms I use more regularly, so yes. I just tried your config and it works fine for me. Could you send me your bootstrap.elf and fiasco.image files (off-list) so that I can take a look?
Thanks, Adam
On Thu Apr 17, 2014 at 23:21:20 +0200, Adam Lackorzynski wrote:
Hi,
On Thu Apr 17, 2014 at 13:01:18 +0200, Michele Paolino wrote:
On 17/04/2014 00:02, Adam Lackorzynski wrote:
On Wed Apr 16, 2014 at 13:03:44 +0200, Michele Paolino wrote:
On 15/04/2014 23:33, Adam Lackorzynski wrote:
On Tue Apr 15, 2014 at 17:26:36 +0200, Michele Paolino wrote:
Hello Adam,
On 14/04/2014 23:53, Adam Lackorzynski wrote: >Hi, > >On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote: >>I'm trying to execute Fiasco.OC along with the hello module using qemu and >>the vexpress machine model. For both A9 and A15 cpus the system hangs at >>"Starting kernel fiasco". It seems that something (the UART driver?) >>prevents the system to log the kernel boot to the screen. >> >>I compiled the image using 'make qemu' in L4RE, and the vm is executed with >>the argument -nographic. >> >>Can you confirm this? Do you have any suggestion to solve it? >> >>Here below you can find the log of the A15 boot process: >Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick >up the right Fiasco binary, i.e. that one configured for vexpress-a15? Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the following:
Image size(s) in bytes: bootstrap_hello.elf: 917888 Start address: 0x81000000 --> Build-Nr: 2
QEmu-cmd: qemu-system-arm -kernel /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf -nographic -M vexpress-a15 -m 256
And soon after the log of the boot is exactly the one I posted before. I assume that what is in build/images/ is the right binary (bootstrap.elf is a symbolic link to build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check elsewhere?
I'd suspect that Fiasco could be wrongly configured, that's why I was asking whether the build process picked up the right Fiasco image that has been also configured for this target.
ps: I tried to investigate about the status of the CPU registers using GDB, the info all-registers command returns always the same value for all the registers.
Please show them, they might tell me something :)
Sure. This is the log:
(gdb) target remote :1234 Remote debugging using :1234 0xffff000c in ?? () (gdb) info all-registers r0 0x1c 28 r1 0x2 2 r2 0x2 2 r3 0xffffffff -1 r4 0x0 0 r5 0x9000200b -1879039989 r6 0xc53c7f 12926079 r7 0x0 0 r8 0x80059cc0 -2147115840 r9 0x55555555 1431655765 r10 0x0 0 r11 0x80002500 -2147474176 r12 0x0 0 sp 0x0 0x0 lr 0xffff0010 -65520 pc 0xffff000c 0xffff000c cpsr 0x600001d7 1610613207
So it page-faulted. Could you show me the globalconfig.out out of the Fiasco build-dir?
This is the globalconfig file:
[...]
I tried several configurations, for example I added the following
< CONFIG_ARM_ALIGNMENT_CHECK=y < CONFIG_ARM_ENABLE_SWP=y < CONFIG_ARM_LPAE=y < CONFIG_FPU=y < CONFIG_ARM_CPU_ERRATA=y
to the config file, but it doesn't solve the problem. In the meantime I'm checking the vexpress memory map in the directory kernel/fiasco/src/kern/arm, but everything looks good to me. Is there anyone who actually uses FIASCO with this configuration?
It's among the platforms I use more regularly, so yes. I just tried your config and it works fine for me. Could you send me your bootstrap.elf and fiasco.image files (off-list) so that I can take a look?
Your image works fine for me with qemu-system-arm -kernel /tmp/bootstrap.elf -nographic -M vexpress-a15 -m 256
I'm using a recent Qemu version. Which version do you use?
Adam
Adam,
In fact it seems that the version present in the Ubuntu 12.04 repository is too old and has some problem with FIASCO. Thank you for your help, I downloaded and compiled qemu v2 and now it works.
Actually I didn't try to change the qemu version before because I tried to use the bootstrap.elf with FastModels and the kernel stops at "Roottask config ip:801401a0 sp:00000000" ( more or less same behavior of the older versions of QEMU, so I thought the problem was the same). Is there anyone who has experience with FIASCO+FastModels?
Lastly, is there any example that you can mention of FIASCO.OC usage in production?
Regards, Michele
On 19/04/2014 11:31, Adam Lackorzynski wrote:
On Thu Apr 17, 2014 at 23:21:20 +0200, Adam Lackorzynski wrote:
Hi,
On Thu Apr 17, 2014 at 13:01:18 +0200, Michele Paolino wrote:
On 17/04/2014 00:02, Adam Lackorzynski wrote:
On Wed Apr 16, 2014 at 13:03:44 +0200, Michele Paolino wrote:
On 15/04/2014 23:33, Adam Lackorzynski wrote:
On Tue Apr 15, 2014 at 17:26:36 +0200, Michele Paolino wrote: > Hello Adam, > > On 14/04/2014 23:53, Adam Lackorzynski wrote: >> Hi, >> >> On Mon Apr 14, 2014 at 11:35:25 +0200, Michele Paolino wrote: >>> I'm trying to execute Fiasco.OC along with the hello module using qemu and >>> the vexpress machine model. For both A9 and A15 cpus the system hangs at >>> "Starting kernel fiasco". It seems that something (the UART driver?) >>> prevents the system to log the kernel boot to the screen. >>> >>> I compiled the image using 'make qemu' in L4RE, and the vm is executed with >>> the argument -nographic. >>> >>> Can you confirm this? Do you have any suggestion to solve it? >>> >>> Here below you can find the log of the A15 boot process: >> Did you launch make qemu with PT=rv_vexpress_a15 and did the launch pick >> up the right Fiasco binary, i.e. that one configured for vexpress-a15? > Executing "make qemu O=../build PT=rv_vexpress_a15 E=hello" results in the > following: > > Image size(s) in bytes: > bootstrap_hello.elf: 917888 > Start address: 0x81000000 > --> Build-Nr: 2 > QEmu-cmd: qemu-system-arm -kernel > /home/neonum6/l4re-core-2014022818/src/build/images/bootstrap.elf > -nographic -M vexpress-a15 -m 256 > > > And soon after the log of the boot is exactly the one I posted before. I > assume that what is in build/images/ is the right binary (bootstrap.elf is a > symbolic link to > build/pkg/bootstrap/server/src/OBJ-arm_armv7a/bootstrap.elf), should I check > elsewhere? I'd suspect that Fiasco could be wrongly configured, that's why I was asking whether the build process picked up the right Fiasco image that has been also configured for this target.
> ps: I tried to investigate about the status of the CPU registers using GDB, > the info all-registers command returns always the same value for all the > registers. Please show them, they might tell me something :)
Sure. This is the log:
(gdb) target remote :1234 Remote debugging using :1234 0xffff000c in ?? () (gdb) info all-registers r0 0x1c 28 r1 0x2 2 r2 0x2 2 r3 0xffffffff -1 r4 0x0 0 r5 0x9000200b -1879039989 r6 0xc53c7f 12926079 r7 0x0 0 r8 0x80059cc0 -2147115840 r9 0x55555555 1431655765 r10 0x0 0 r11 0x80002500 -2147474176 r12 0x0 0 sp 0x0 0x0 lr 0xffff0010 -65520 pc 0xffff000c 0xffff000c cpsr 0x600001d7 1610613207
So it page-faulted. Could you show me the globalconfig.out out of the Fiasco build-dir?
This is the globalconfig file:
[...]
I tried several configurations, for example I added the following
< CONFIG_ARM_ALIGNMENT_CHECK=y < CONFIG_ARM_ENABLE_SWP=y < CONFIG_ARM_LPAE=y < CONFIG_FPU=y < CONFIG_ARM_CPU_ERRATA=y
to the config file, but it doesn't solve the problem. In the meantime I'm checking the vexpress memory map in the directory kernel/fiasco/src/kern/arm, but everything looks good to me. Is there anyone who actually uses FIASCO with this configuration?
It's among the platforms I use more regularly, so yes. I just tried your config and it works fine for me. Could you send me your bootstrap.elf and fiasco.image files (off-list) so that I can take a look?
Your image works fine for me with qemu-system-arm -kernel /tmp/bootstrap.elf -nographic -M vexpress-a15 -m 256
I'm using a recent Qemu version. Which version do you use?
Adam
On Wed Apr 23, 2014 at 09:50:39 +0200, Michele Paolino wrote:
In fact it seems that the version present in the Ubuntu 12.04 repository is too old and has some problem with FIASCO. Thank you for your help, I downloaded and compiled qemu v2 and now it works.
Actually I didn't try to change the qemu version before because I tried to use the bootstrap.elf with FastModels and the kernel stops at "Roottask config ip:801401a0 sp:00000000" ( more or less same behavior of the older versions of QEMU, so I thought the problem was the same). Is there anyone who has experience with FIASCO+FastModels?
I've used it some time back however my licences are expired, so I've not used it for some time now.
Lastly, is there any example that you can mention of FIASCO.OC usage in production?
One example I can mention is http://www.telekom.com/media/enterprise-solutions/200664
Adam
l4-hackers@os.inf.tu-dresden.de