Testing Fiasco.OC+L4re on ODROID-X2(Exynos4412)
Reinier Millo Sánchez
rmillo at uclv.cu
Tue May 19 21:23:33 CEST 2015
Hi Adam
On 05/17/2015 06:35 PM, Adam Lackorzynski wrote:
> Hi,
>
> On Fri May 15, 2015 at 13:12:52 -0400, Reinier Millo Sánchez wrote:
>> On 05/11/2015 06:00 AM, l4-hackers-request at os.inf.tu-dresden.de wrote:
>>> On Tue May 05, 2015 at 01:28:46 -0400, Reinier Millo S?nchez wrote:
>>>>> Hi Adam
>>>>>>>>>>> FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard,
>>>>>>>>>>> p: dbl/sngl
>>>>>>>>>>>
>>>>>>>>>>> KERNEL: Warning: No page-fault handler for 0xee202214, error
>>>>>>>>>>> 0x94000848, pc f0039420
>>>>>>>>>>>
>>>>>>>>>>> Somebody have tested Fiasco.OC+L4re on ODROID-X2 or another Exynos 4412
>>>>>>>>>>> platform?
>>>>>>> On this platform this seems to be some pattern. However, last time I
>>>>>>> tried it worked for me. So, hmm, could you try another compiler version
>>>>>>> and see if it changes behavior? Maybe this gives us some hints.
>>>>> I'm using a linaro toolchain
>>>>> (gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_x86_64). I have tried the
>>>>> arm-none-eabi toolchain in Debian repository but fails compiling the
>>>>> snapshot.
>>>>> I have made some progress trying to run FiascoOC+L4re on Odroid-X2. There
>>>>> are some changes that I have made:
>>>>> I have modified the file "l4/mk/platforms/exynos4.conf" adapting Exynos4's
>>>>> platform to Odroid-X2. In this case the RAM size differs (Odroid-X2 have
>>>>> 2Gb). In this file I have configured the UART for serial output (I'm using
>>>>> UART 1).
>>>>>
>>>>> PLATFORM_RAM_BASE = 0x40000000
>>>>> - PLATFORM_RAM_SIZE_MB = 1024
>>>>> + PLATFORM_RAM_SIZE_MB = 2047
>>>>> + PLATFORM_UART_NR = 1
>>>>>
>>>>> Booting the generated image I have detected that bootstrap's server is not
>>>>> using UART 1 for output. I have modified the "init" function on
>>>>> "l4/pkg/bootstrap/server/src/platform/exynos.cc" to use the configured UART
>>>>> on the platform file modified above.
>>>>>
>>>>> unsigned long uart_base;
>>>>> - unsigned uart_nr = 2;
>>>>> + unsigned uart_nr = PLATFORM_UART_NR;
>>>>>
>>>>> I have tried to compile and test the image on the Odroid-X2, but fails the
>>>>> execution, this is the serial output:
>>>>>
>>>>> L4 Bootstrapper
>>>>> Build: #18 Sat May 2 15:56:00 CDT 2015, 4.8.3 20140303 (prerelease)
>>>>> Scanning up to 2047 MB RAM, starting at offset 32MB
>>>>> Memory size is 2047MB (40000000 - bfefffff)
>>>>> Limiting 'RAM' region [ 40000000, bfefffff] { 7ff00000} to [
>>>>> 40000000, bcffffff] { 7d000000} due to 3024 MB address limit
>>>>> RAM: 0000000040000000 - 00000000bcffffff: 2048000kB
>>>>> Total RAM: 2000MB
>>>>> Scanning fiasco
>>>>> Scanning sigma0
>>>>> Scanning moe
>>>>> Moving up to 5 modules behind 41100000
>>>>> moving module 02 { 410b4000-410e565f } -> { 411a5000-411d665f }
>>>>> [202336]
>>>>> moving module 01 { 410aa000-410b3377 } -> { 4119b000-411a4377 }
>>>>> [37752]
>>>>> moving module 00 { 41043000-410a9daf } -> { 41134000-4119adaf }
>>>>> [421296]
>>>>> moving module 04 { 41029000-410425b3 } -> { 4111a000-411335b3 }
>>>>> [103860]
>>>>> moving module 03 { 4100f000-41028493 } -> { 41100000-41119493 }
>>>>> [103572]
>>>>> Loading fiasco
>>>>> Loading sigma0
>>>>> Loading moe
>>>>> find kernel info page...
>>>>> found kernel info page at 0x40002000
>>>>> Regions of list 'regions'
>>>>> [ 40000000, 400000e3] { e4} Root mbi_rt
>>>>> [ 40001000, 40001aff] { b00} Kern fiasco
>>>>> [ 40002000, 40076fff] { 75000} Kern fiasco
>>>>> [ 40090000, 4009681b] { 681c} Sigma0 sigma0
>>>>> [ 40098000, 4009e177] { 6178} Sigma0 sigma0
>>>>> [ 40140000, 4018b4ab] { 4b4ac} Root moe
>>>>> [ 41000000, 4100e4ff] { e500} Boot bootstrap
>>>>> [ 41100000, 41133fff] { 34000} Root Module
>>>>> API Version: (87) experimental
>>>>> Sigma0 config ip:40090100 sp:00000000
>>>>> Roottask config ip:4014020c sp:00000000
>>>>> Starting kernel fiasco at 400012c8
>>>>> Hello from Startup::stage2
>>>>> Per_cpu_data_alloc: (orig: 0xf0063a50-0xf00644d0)
>>>>> Number of IRQs available at this GIC: 160
>>>>> FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard,
>>>>> p: dbl/sngl
>>>>>
>>>>> KERNEL: Warning: No page-fault handler for 0xee202214, error
>>>>> 0x94000848, pc f0039420
>>>>>
>>>>> I have been testing and changing the compiling configuration. Using the
>>>>> below configuration to compile Fiasco.OC, the system boots and hangs at
>>>>> "Calibrating timer loop...":
>>>>>
>>>>> Platform Timer -> Multi-core timer
>>>>> Use ExtGic -> True
>>>>> Execution Model -> TrustZone normal side
>>>>> Secure Monitor Interface -> Mobicore
>>>>> Enable multi processor support -> True
>>>>> Maximal supported number of CPUs -> 4
>>> Interesting. What's the difference to the previos config?
>> In the first configuration i was using:
>>
>> Platform Timer -> Multi-core timer
>> Use ExtGic -> True
>> Execution Model -> Standard mode
>> Enable multi processor support -> False
> Ok, thanks.
>
>>>>> This is the serial output when tested the image on Odroid-X2:
>>>>> Calibrating timer loop...
>>>>>
>>>>> I think that the problem now is with the Exynos4's Timers, but i have been
>>>>> reviewing the implementations and it seems fine.
>>>>> Is there anything wrong on my configuration or somebody have any idea?
>>> Does the counter of the timer count, i.e. multiple reads return
>>> different values?
>> We have checked and the system clock at Kip (Kip::k()->clock) is updating on
>> every tick in the function "Timer::update_system_clock", but multiple reads
>> of the clock in the function "Delay::measure" returns the same value.
> This sounds as it would work? Reading 'clock' multiple times in a row
> will indeed return the same value, until the next timer interrupt.
> That's what the measure function actually tries to check.
>
>> We have made another small changes to test the snapshot on the Odroid-X2
>> board. We have compiled Fiasco.OC using this configuration:
>>
>> Execution Model ->TrustZone Normal side
>> Secure Monitor Interface ->none
>> Enable multi processor support ->Disable
> So you're using the Multi-core timer? Could you add a
> mct->write<Mword>(1 << 8, Mct_timer::Reg::Tcon); and a couple of
> printf("%lx\n", mct->read<Mword>(Mct_timer::Reg::Cnt_l)); in
> timer-arm-exynos.cpp in Timer::init within the boot_cpu block?
> Are the printed numbers different?
We've tried your suggestions and the printf write different values of
the global MCT Timer. The current Fiasco.OC implementation don't uses
the Global MCT Timer, it uses the CPU local timer. The system clock is
updated in Timer::update_system_clock, incrementing the Kip::k()->clock
value. This function is called in the Timer_tick::handle_timer. At this
point we have added an printf to view if the timer is updating.
Timer_tick::handle_timer(Irq_base *_s, Upstream_irq const *ui,
Thread *t, Cpu_number cpu)
{
Timer_tick *self = nonull_static_cast<Timer_tick *>(_s);
self->ack();
ui->ack();
++ Kip *k = Kip::k();
Timer::update_system_clock(cpu);
++ if ( k->clock < 1000UL*20){
++ printf(" CLOCK:%llu\n",k->clock);
++ }
if (Config::esc_hack && cpu == Cpu_number::boot_cpu())
{
if (Kconsole::console()->char_avail() && !Vkey::check_())
kdb_ke("SERIAL_ESC");
}
self->log_timer();
t->handle_timer_interrupt();
}
We have only printed 20 values to don't overload the serial output with
the ticks output. We have added some printf in the Delay::measure to
check the clock values:
Delay::measure()
{
Cpu_time t1;
unsigned count = 0;
Kip *k = Kip::k();
Cpu_time t = Kip::k()->clock;
++ printf(" IN MEASURE CLOCK: %llu\n",k->clock);
++ int i=0;
Timer::update_timer(t + 1000); // 1ms
while (t == (t1 = k->clock)){
Proc::pause();
++ if(i==0){
++ printf(" MEASURE-WHILE : %llu : %llu\n",t,k->clock);
++ i++;
++ }
}
Timer::update_timer(k->clock + 1000); // 1ms
while (t1 == k->clock)
{
++count;
Proc::pause();
}
return count;
}
We have testes it on the Odroid-X2 and this is the serial output:
CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
APLL = 1000MHz, MPLL = 880MHz
DRAM: 2 GiB
PMIC VERSION : 0x00, CHIP REV : 2
TrustZone Enabled BSP
BL1 version: 20121128
Checking Boot Mode ... SDMMC
MMC Device 0: 7695 MB
In: serial
Out: serial
Err: serial
ModeKey Check... run normal_boot
Net: usb_ether
Exynos4412 # boot
reading bootstrap_hello.raw
1040384 bytes read in 50 ms (19.8 MiB/s)
Boot with zImage
Starting kernel ...
L4 Bootstrapper
Build: #32 Tue May 19 14:03:36 EDT 2015, 4.8.3 20140303 (prerelease)
Scanning up to 2047 MB RAM, starting at offset 32MB
Memory size is 2047MB (40000000 - bfefffff)
Limiting 'RAM' region [ 40000000, bfefffff] { 7ff00000} to [
40000000, bcffffff] { 7d000000} due to 3024 MB address limit
RAM: 0000000040000000 - 00000000bcffffff: 2048000kB
Total RAM: 2000MB
Scanning fiasco
Scanning sigma0
Scanning moe
Moving up to 5 modules behind 41100000
moving module 02 { 410cc000-410fd65f } -> { 411bd000-411ee65f }
[202336]
moving module 01 { 410c2000-410cb377 } -> { 411b3000-411bc377 }
[37752]
moving module 00 { 41043000-410c13ff } -> { 41134000-411b23ff }
[517120]
moving module 04 { 41029000-410425b3 } -> { 4111a000-411335b3 }
[103860]
moving module 03 { 4100f000-41028493 } -> { 41100000-41119493 }
[103572]
Loading fiasco
Loading sigma0
Loading moe
find kernel info page...
found kernel info page at 0x40002000
Regions of list 'regions'
[ 40000000, 400000e3] { e4} Root mbi_rt
[ 40001000, 40001aff] { b00} Kern fiasco
[ 40002000, 4008afff] { 89000} Kern fiasco
[ 40090000, 4009681b] { 681c} Sigma0 sigma0
[ 40098000, 4009e177] { 6178} Sigma0 sigma0
[ 40140000, 4016efcf] { 2efd0} Root moe
[ 40170000, 4018b4ab] { 1b4ac} Root moe
[ 41000000, 4100e4ff] { e500} Boot bootstrap
[ 41100000, 41133fff] { 34000} Root Module
API Version: (87) experimental
Sigma0 config ip:40090100 sp:00000000
Roottask config ip:4014020c sp:00000000
Starting kernel fiasco at 400012c8
Hello from Startup::stage2
Per_cpu_data_alloc: (orig: 0xf007b0a0-0xf007bb20)
Number of IRQs available at this GIC: 160
FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard,
p: dbl/sngl
L2: ID=4100c4c8 Type=1a340340 Aux=7e470001 WMask=ffff S=0
L2: Type L2C-310 Size = 1024kB Ways=16 Waysize=64
Watchdog initialized
SERIAL ESC: allocated IRQ 85 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: unknown compiled with gcc 4.8.3 for Samsung Exynos []
Build: #42 Tue May 19 14:03:26 EDT 2015
Per_cpu_data_alloc: (orig: 0xf007b0a0-0xf007bb20)
Allocate 2688 bytes (3KB) for CPU[4] local storage (offset=116ef60,
0xf11ea000-0xf11eaa80)
Timer for CPU0 is at IRQ 28
Number of CPUs: 4
Per_cpu_data_alloc: (orig: 0xf007b0a0-0xf007bb20)
Allocate 2688 bytes (3KB) for CPU[1] local storage (offset=1170f60,
0xf11ec000-0xf11eca80)
CLOCK:1000
FPU1: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard,
p: dbl/sngl
Timer for CPU1 is at IRQ 28
Per_cpu_data_alloc: (orig: 0xf007b0a0-0xf007bb20)
CLOCK:2000
Allocate 2688 bytes (3KB) for CPU[2] local storage (offset=1174f60,
0xf11f0000-0xf11f0a80)
Cache config: ON
FPU2: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard,
p: dbl/sngl
ID_PFR[01]: 00001231 00000011
Per_cpu_data_alloc: (orig: 0xf007b0a0-0xf007bb20)
CLOCK:3000
ID_[DA]FR0: 00010444 00000000
ID_MMFR[04]: 00100103 20000000 01230000 00102111
CPU[1]: goes to idle loop
CLOCK:4000
Timer for CPU2 is at IRQ 28
Allocate 2688 bytes (3KB) for CPU[3] local storage (offset=1177f60,
0xf11f3000-0xf11f3a80)
Cache config: ON
FPU3: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard,
p: dbl/sngl
ID_PFR[01]: 00001231 00000011
ID_[DA]FR0: 00010444 00000000
ID_MMFR[04]: 00100103 20000000 01230000 00102111
CLOCK:5000
CPU[2]: goes to idle loop
Timer for CPU3 is at IRQ 28
Cache config: ON
ID_PFR[01]: 00001231 00000011
CLOCK:6000
ID_[DA]FR0: 00010444 00000000
ID_MMFR[04]: 00100103 20000000 01230000 00102111
CPU[3]: goes to idle loop
CLOCK:7000
CLOCK:8000
CLOCK:9000
CLOCK:10000
CLOCK:11000
CLOCK:12000
CLOCK:13000
CLOCK:14000
CLOCK:15000
CLOCK:16000
CLOCK:17000
CLOCK:18000
CLOCK:19000
CLOCK:20000
Calibrating timer loop...
IN MEASURE CLOCK: 20000
MEASURE-WHILE :20000 : 20000
We have tested changing the amount of update_system_timer logged, but
always the system waits to finish it and then enter in the "Calibrating
timer loop". In the Delay::meause the clock always print the last value
logged by the printf at Timer_tick::handle_timer.
It seems the the system clock is working and updating but at certain
point it don't update anymore.
We have tested a little solution, forcing the system to try to pass this
point. We have added a Proc::sti() call after the Proc::pause(). In this
case the system prints differents values for the clocks.
Somebody have any idea or suggestions about this problem on the Exynos4412?
Best regards
--
Lic. Reinier Millo Sánchez
Centro de Estudios de Informática
Universidad Central "Marta Abreu" de Las Villas
Carretera a Camajuaní Km 5 1/2
Santa Clara, Villa Clara, Cuba
CP 54830
"antes de discutir ... respira;
antes de hablar ... escucha;
antes de escribir ... piensa;
antes de herir ... siente;
antes de rendirte ... intenta;
antes de morir ... vive"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150519/86e39932/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rmillo.vcf
Type: text/x-vcard
Size: 515 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150519/86e39932/attachment-0001.vcf>
More information about the l4-hackers
mailing list