Hi everyone,
I’m currently trying to port Fiasco + L4re with the « Hello World » application on a Zedboard which has a Xilinx Zynq z7020 processor (ARM Cortex A9 MPCore).
We already configure UART and Timer for the microkernel but boot crash after the step : Calibrating Timer loop… Our problem seems to occur during the execution of Delay::measure() function. Does anyone know what it exactly does and especially update_timer which seems to have no effect in our case.
Here is the boot execution trace :
# Booting kernel from Legacy Image at 03000000 ...
Image Name: L4 Image #42
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 868352 Bytes = 848 KiB
Load Address: 01100000
Entry Point: 01100000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 5619903 Bytes = 5.4 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
Booting using the fdt blob at 0x2a00000
Loading Kernel Image ... OK
Loading Ramdisk to 1f5d2000, end 1fb2e0bf ... OK
Loading Device Tre
L4 Bootstrapper
Build: #42 Tue Jul 1 15:59:58 CEST 2014, 4.7.3
Scanning up to 512 MB RAM
Memory size is 512MB (00100000 - 200fffff)
RAM: 0000000000100000 - 00000000200fffff: 524288kB
Total RAM: 512MB
mod04: 011ba000-011d3578: hello
mod03: 011a0000-011b9458: l4re
mod02: 0116e000-0119f624: moe
mod01: 01164000-0116d33c: sigma0
mod00: 01115000-011638e8: fiasco
Moving up to 5 modules behind 1200000
moving module 00 { 1115000-11638e7 } -> { 12bf000-130d8e7 } [321768]
moving module 01 { 1164000-116d33b } -> { 130e000-131733b } [37692]
moving module 02 { 116e000-119f623 } -> { 1318000-1349623 } [202276]
moving module 03 { 11a0000-11b9457 } -> { 1200000-1219457 } [103512]
moving module 04 { 11ba000-11d3577 } -> { 121a000-1233577 } [103800]
Scanning fiasco -serial_esc
Scanning sigma0
Scanning moe --init=rom/hello
Relocated mbi to [0x110e000-0x110e0e2]
Loading fiasco
Loading sigma0
Loading moe
find kernel info page...
found kernel info page at 0x102000
Regions of list 'regions'
[ 101000, 101b3f] { b40} Kern fiasco
[ 102000, 15efff] { 5d000} Kern fiasco
[ 190000, 1965fb] { 65fc} Sigma0 sigma0
[ 198000, 19e17b] { 617c} Sigma0 sigma0
[ 240000, 26cacb] { 2cacc} Root moe
[ 270000, 286f0f] { 16f10} Root moe
[ 1100000, 11143f3] { 143f4} Boot bootstrap
[ 110a000, 110a0a6] { a7} Boot mbi
[ 110e000, 110e1df] { 1e0} Root Multiboot info
[ 1114048, 111409f] { 58} Boot mbi
[ 1200000, 1233577] { 33578} Root Module
API Version: (87) experimental
Sigma0 config ip:00190100 sp:01113de4
Roottask config i�Hello from Startup::stage2
Number of IRQs available at this GIC: 96
Cache config: ON
ID_PFR[01]: 00001231 00000011 ID_[DA]FR0: 00010444 00000000
ID_MMFR[04]: 00100103 20000000 01230000 00102111
L2: ID=410000c8 Type=9e300300 Aux=72360000 WMask=ff S=0
L2: Type L2C-310 Size = 512kB
SERIAL ESC: allocated IRQ 59 for serial uart
Not using serial hack in slow timer handler.
Welcome to Fiasco.OC (arm)!
L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden
Rev: f5bb6d4 compiled with gcc 4.7.3 for zynq []
Build: #69 Tue Jul 1 15:59:21 CEST 2014
Calibrating timer loop...
Thanks in advance
Best Regards
Xavier
Hi Xavier,
Am 01.07.2014 17:04, schrieb Xavier LEBARS:
Hi everyone,
I’m currently trying to port Fiasco + L4re with the « Hello World » application on a Zedboard which has a Xilinx Zynq z7020 processor (ARM Cortex A9 MPCore).
We already configure UART and Timer for the microkernel but boot crash after the step : Calibrating Timer loop… Our problem seems to occur during the execution of Delay::measure() function. Does anyone know what it exactly does and especially update_timer which seems to have no effect in our case.
This Delay::measure() function counts the number of calls to Proc::pause() which can be made until the 1ms system time elapses.
I had the same problem while porting Fiasco on some other platform (i.MX28). The reason why you are stuck in Delay::measure() is that the system time of Fiasco does not advance and thus Delay::measure() does not return. Most probably the driver of your timer device is not running properly, your timer is not configured to generate the periodically 1ms system clock and/or the driver of your interrupt controller does not handle timer interrupts.
For the first testing steps you can probably skip this loop and return some hardcoded arbitrary value to get the Hello World example running.
Martin
Hello,
Thanks for the answer, we can display Hello World only once. (I resend my message because I forgot to add the L4 mailing list ...)
We still have another questions. What kind of interrupts are you talking about ? Which module should actually throw this interrupt and when ?
Best regards Xavier
-----Message d'origine----- De : l4-hackers [mailto:l4-hackers-bounces@os.inf.tu-dresden.de] De la part de Martin Schröder Envoyé : mardi 1 juillet 2014 17:37 À : l4-hackers@os.inf.tu-dresden.de Objet : Re: Delay::measure function
Hi Xavier,
Am 01.07.2014 17:04, schrieb Xavier LEBARS:
Hi everyone,
I'm currently trying to port Fiasco + L4re with the « Hello World » application on a Zedboard which has a Xilinx Zynq z7020 processor (ARM Cortex A9 MPCore).
We already configure UART and Timer for the microkernel but boot crash after the step : Calibrating Timer loop... Our problem seems to occur during the execution of Delay::measure() function. Does anyone know what it exactly does and especially update_timer which seems to have no effect in our case.
This Delay::measure() function counts the number of calls to Proc::pause() which can be made until the 1ms system time elapses.
I had the same problem while porting Fiasco on some other platform (i.MX28). The reason why you are stuck in Delay::measure() is that the system time of Fiasco does not advance and thus Delay::measure() does not return. Most probably the driver of your timer device is not running properly, your timer is not configured to generate the periodically 1ms system clock and/or the driver of your interrupt controller does not handle timer interrupts.
For the first testing steps you can probably skip this loop and return some hardcoded arbitrary value to get the Hello World example running.
Martin
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hello Xavier,
Am 04.07.2014 11:18, schrieb Xavier LEBARS:
Hello,
Thanks for the answer, we can display Hello World only once. (I resend my message because I forgot to add the L4 mailing list ...)
the Hello World example calls sleep(1) which causes the kernel to suspend the task for one second until the next line is printed. This delay period is derived from the fiasco system clock. The system clock needs periodically increased. Usually a hardware timer is configured to periodically generate (hardware-)interrupts at a rate of 1000 Hz. And every time the interrupt handler of the timer is triggered, it calls a function in the kernel to increase the system clock. See the the last line in timer-arm-realview.cpp where Kip::k()->clock; is called.
If your system clock is not advanced, the sleep(1) will never return.
We still have another questions. What kind of interrupts are you talking about ? Which module should actually throw this interrupt and when ?
In the bsp you have to add support for the hardware-timers of your SOC, configure one channel for 1000Hz and make sure that the timer interrupts are routet to the interrupt handler.
Best regards Martin
l4-hackers@os.inf.tu-dresden.de