Hi,
On Tue May 19, 2015 at 15:23:33 -0400, Reinier Millo Sánchez wrote:
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@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.
Ok, sounds goo.d
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:
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?
Your code is a bit confusing to me, as I do not see how it ever can print more than 2 lines and I'd suspect that all numbers are the same (or do you let it wrap?). Concerning the sti(), it is called before measure() (before Delay::init() is called). So maybe interrupts go off again. Could you check at various points starting from Delay::init() what Proc::interrupts() returns?
Adam