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-requ...@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"

<<attachment: rmillo.vcf>>

_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Reply via email to