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-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.
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
--
Adam a...@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
