* [Xenomai] ODROID-U3 porting problems
@ 2014-08-27 13:49 GP Orcullo
2014-08-27 15:45 ` Gilles Chanteperdrix
0 siblings, 1 reply; 16+ messages in thread
From: GP Orcullo @ 2014-08-27 13:49 UTC (permalink / raw)
To: xenomai
Hi,
I'm in the process of porting xenomai to Samsung Exynos 4420 based
ODROID-U3 board. I've followed the online manual and I was able to finish
up to the interrupt controller part.
So far everything works when booting the board with CONFIG_IPIPE and
CONFIG_XENOMAI enabled. However, running the latency test gives the
following results:
root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 0 -T5
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|-1054607.854|-555107.854|-416666.667| 0|
0|-1054607.854|-416666.667
RTD|-2054607.854|-1555107.854|-416666.667| 0|
0|-2054607.854|-416666.667
RTD|1240359.443|1739859.443|-416666.667| 0| 0|1240359.443|-416666.667
RTD| 240359.443| 739859.443|-416666.667| 0| 0| 240359.443|-416666.667
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 240359.443|-2055107.854|-416666.667| 0| 0| 00:00:05/00:00:05
root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 1 -T5
== Sampling period: 1000 us
[ 2816.305094] Xenomai: suspending kernel thread e6561048
('timerbench') at 0xc00206d8 after exception #0x0
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 10000.000| 0.000| -10000.000| 0| 0| 00:00:05/00:00:05
root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 2 -T5
== Sampling period: 1000 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT| 00:00:01 (in-kernel timer handler, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| -0.042| 0.212| 1.208| 0| 0| -0.042| 1.208
RTD| -0.042| 0.227| 1.250| 0| 0| -0.042| 1.250
RTD| -0.001| 0.248| 1.249| 0| 0| -0.042| 1.250
RTD| -0.001| 0.247| 1.332| 0| 0| -0.042| 1.332
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| -0.042| 0.233| 1.332| 0| 0| 00:00:05/00:00:05
These are the results of running clocktest:
root@odroidu3:~# /usr/lib/xenomai/testsuite/clocktest -C 0 -T 20 -D
== Tested clock: 0 (CLOCK_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 -1409142548993831.2 5.596 0 0.0
1 -1409142548993831.2 5.598 0 0.0
2 -1409142548993831.2 5.614 0 0.0
3 -1409142548993831.2 5.600 0 0.0
root@odroidu3:~# /usr/lib/xenomai/testsuite/clocktest -C 1 -T 20 -D
== Tested clock: 1 (CLOCK_MONOTONIC)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 -1409142408743853.0 -1000000.000 0 0.0
1 -1409142408743715.0 -1000000.000 0 0.0
2 -1409142408744357.0 -1000000.000 0 0.0
3 -1409142408744674.0 -1000000.000 0 0.0
root@odroidu3:~# /usr/lib/xenomai/testsuite/clocktest -C 42 -T 20 -D
hostrt data area is live
Sequence counter : 690412
wall_time_sec : 1409144278
wall_time_nsec : 498694879
wall_to_monotonic
tv_sec : -1409142550
tv_nsec : 998340710
cycle_last : 41508303760
mask : 0xffffffffffffffff
mult : 699046750
shift : 24
== Tested clock: 42 (CLOCK_HOST_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 789310.5 -49904.232 119 0.1
1 789751.5 -48386.271 128 0.1
2 790092.5 -46656.212 84 0.1
3 789618.5 -46341.548 103 0.1
I've attached the dmesg output. Any hints on how to solve these problems?
Thanks,
Gemi
-------------- next part --------------
[ 0.000000] Booting Linux on physical CPU 0xa00
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Linux version 3.8.13.11-xen (gemi@odroidu3) (gcc version 4.6.3 (Debian 4.6.3-14) ) #34 SMP PREEMPT Wed Aug 27 20:22:46 SGT 2014 ()
[ 0.000000] Kernel was built at commit id ''
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: ODROIDU2
[ 0.000000] cma: CMA: reserved 64 MiB at 43000000
[ 0.000000] cma: CMA: reserved 64 MiB at 51000000
[ 0.000000] cma: CMA: reserved 128 MiB at 67800000
[ 0.000000] Memory policy: ECC disabled, Data cache writealloc
[ 0.000000] CPU EXYNOS4412 (id 0xe4412220)
[ 0.000000] exynos4_init_clocks: initializing clocks
[ 0.000000] S3C24XX Clocks, Copyright 2004 Simtec Electronics
[ 0.000000] s3c_register_clksrc: clock armclk has no registers set
[ 0.000000] s3c_register_clksrc: clock audiocdclk has no registers set
[ 0.000000] audiocdclk: no parent clock specified
[ 0.000000] exynos4_setup_clocks: registering clocks
[ 0.000000] exynos4_setup_clocks: xtal is 24000000
[ 0.000000] EXYNOS4: PLL settings, A=1000000000, M=880000000, E=96000000 V=350000000
[ 0.000000] EXYNOS4: ARMCLK=1000000000, DMC=440000000, ACLK200=176000000
[ 0.000000] ACLK100=110000000, ACLK160=176000000, ACLK133=146666666
[ 0.000000] sclk_pwm: source is ext_xtal (0), rate is 24000000
[ 0.000000] sclk_csis: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_csis: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_cam0: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_cam1: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_fimc: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_fimc: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_fimc: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_fimc: source is xusbxti (1), rate is 1500000
[ 0.000000] sclk_fimd: source is mout_mpll_user (6), rate is 55000000
[ 0.000000] sclk_mfc: source is mout_mfc0 (0), rate is 55000000
[ 0.000000] sclk_g3d: source is mout_g3d0 (0), rate is 55000000
[ 0.000000] Unable to set parent aclk_160 of clock dout_mmc0.
[ 0.000000] Unable to set parent aclk_160 of clock dout_mmc1.
[ 0.000000] Unable to set parent aclk_160 of clock dout_mmc2.
[ 0.000000] On node 0 totalpages: 524032
[ 0.000000] Normal zone: 1520 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 193040 pages, LIFO batch:31
[ 0.000000] HighMem zone: 2574 pages used for memmap
[ 0.000000] HighMem zone: 326898 pages, LIFO batch:31
[ 0.000000] Running under secure firmware.
[ 0.000000] PERCPU: Embedded 10 pages/cpu @c1733000 s19136 r8192 d13632 u40960
[ 0.000000] pcpu-alloc: s19136 r8192 d13632 u40960 alloc=10*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 519938
[ 0.000000] Kernel command line: console=tty1 console=ttySAC1,115200 mem=2047M console=tty1 console=ttySAC1,115200n8 fb_x_res=1280 fb_y_res=720 hdmi_phy_res=720 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro mem=2047M
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Memory: 2047MB = 2047MB total
[ 0.000000] Memory: 1801036k/3602072k available, 590184k reserved, 1317888K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc05ee670 (6042 kB)
[ 0.000000] .init : 0xc05ef000 - 0xc061fac0 ( 195 kB)
[ 0.000000] .data : 0xc0620000 - 0xc0680fc0 ( 388 kB)
[ 0.000000] .bss : 0xc0680fc0 - 0xc071df6c ( 628 kB)
[ 0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:549
[ 0.000000] I-pipe, 24.000 MHz clocksource
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] Interrupt pipeline (release #3)
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] console [tty1] enabled
[ 0.001278] Calibrating delay loop... 1992.29 BogoMIPS (lpj=4980736)
[ 0.045069] pid_max: default: 32768 minimum: 301
[ 0.045453] Mount-cache hash table entries: 512
[ 0.046745] Initializing cgroup subsys cpuacct
[ 0.046785] Initializing cgroup subsys devices
[ 0.046880] CPU: Testing write buffer coherency: ok
[ 0.047270] CPU0: thread -1, cpu 0, socket 10, mpidr 80000a00
[ 0.047407] Setting up static identity map for 0x40475a80 - 0x40475ad8
[ 0.047488] L310 cache controller enabled
[ 0.047519] l2x0: 16 ways, CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001, Cache size: 1048576 B
[ 0.097756] CPU1: Booted secondary processor
[ 0.117334] CPU1: thread -1, cpu 1, socket 10, mpidr 80000a01
[ 0.127746] CPU2: Booted secondary processor
[ 0.147333] CPU2: thread -1, cpu 2, socket 10, mpidr 80000a02
[ 0.157769] CPU3: Booted secondary processor
[ 0.177334] CPU3: thread -1, cpu 3, socket 10, mpidr 80000a03
[ 0.177389] Brought up 4 CPUs
[ 0.177473] SMP: Total of 4 processors activated (7969.17 BogoMIPS).
[ 0.179513] devtmpfs: initialized
[ 0.193235] regulator-dummy: no parameters
[ 0.201064] NET: Registered protocol family 16
[ 0.209886] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.220247] s5p_hdmi_cec_set_platdata()
[ 0.228476] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.228506] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.228531] S3C Power Management, Copyright 2004 Simtec Electronics
[ 0.228731] EXYNOS4x12 PMU Initialize
[ 0.232578] EXYNOS: Initializing architecture
[ 0.234096] s3c24xx-pwm s3c24xx-pwm.0: tin at 110000000, tdiv at 110000000, tin=divclk, base 0
[ 0.234212] s3c24xx-pwm s3c24xx-pwm.1: tin at 110000000, tdiv at 110000000, tin=divclk, base 8
[ 0.263750] bio: create slab <bio-0> at 0
[ 0.264710] hdmi_5v: 5000 mV
[ 0.266322] usbcore: registered new interface driver usbfs
[ 0.266544] usbcore: registered new interface driver hub
[ 0.266804] usbcore: registered new device driver usb
[ 0.267456] s3c-i2c s3c2440-i2c.0: slave address 0x10
[ 0.267483] s3c-i2c s3c2440-i2c.0: bus frequency set to 71 KHz
[ 0.268719] max77686 0-0009: device found
[ 0.269002] max77686 0-0009: irq is not specified
[ 0.272441] LDO1 VDD_ALIVE: 1000 mV
[ 0.276360] LDO2 VDDQ_M1_1V8: 1200 mV
[ 0.280276] LDO3 VDDQ_AUD_1V8: 1800 mV
[ 0.284171] LDO4 VDDQ_MMC2_2V8: 2800 mV
[ 0.288050] LDO5 VDDQ_MMC1_1V8: 1800 mV
[ 0.291955] LDO6 VDD10_MPLL_1V0: 1000 mV
[ 0.295830] LDO7 VDD10_EPLL_1V0: 1000 mV
[ 0.299720] LDO8 VDD10_MIPI_1V0: 1000 mV
[ 0.303059] LDO9 VT_CORE_1V0: ODROIDU2: Disabled regulator
[ 0.303083] LDO9 VT_CORE_1V0: 1000 mV
[ 0.305221] LDO10 VDD18_MIPI_1V8: 1800 mV
[ 0.309128] LDO11 VDD18_ABB1_1V8: 1800 mV
[ 0.311248] vdd_ldo12 range: 3300 mV
[ 0.315114] LDO13 VDD18_MIPIHSI_1V8: 1800 mV
[ 0.318992] LDO14 VDD18_ADC_1V8: 1800 mV
[ 0.321116] vdd_ldo15 range: 1000 mV
[ 0.325004] LDO16 VDD18_HSIC: 1800 mV
[ 0.328870] LDO17 VDDQ_CAM_1V8: 1800 mV
[ 0.332158] LDO18 VDDQ_ISP_1V8: ODROIDU2: Disabled regulator
[ 0.332183] LDO18 VDDQ_ISP_1V8: 1800 mV
[ 0.333718] LDO19 VT_CAM_1V8: ODROIDU2: Disabled regulator
[ 0.333742] LDO19 VT_CAM_1V8: 1800 mV
[ 0.335708] LDO20 EMMC_IO_1V8: 1800 mV
[ 0.339610] LDO21 TFLASH_2V8: 2800 mV
[ 0.343480] LDO22 2V8: 2800 mV
[ 0.346768] LDO23 VDD_TOUCH_2V8: ODROIDU2: Disabled regulator
[ 0.346792] LDO23 VDD_TOUCH_2V8: 2800 mV
[ 0.350072] LDO24 VDD_TOUCHLED_3V3: ODROIDU2: Disabled regulator
[ 0.350097] LDO24 VDD_TOUCHLED_3V3: 3300 mV
[ 0.353972] LDO25 VDDQ_LCD_3V0: 1800 mV
[ 0.357271] LDO26 VDD_MOTOR_3V0: ODROIDU2: Disabled regulator
[ 0.357295] LDO26 VDD_MOTOR_3V0: 3000 mV
[ 0.358860] BUCK1 vdd_mif: 1100 mV
[ 0.360977] BUCK2 vdd_arm: 800 <--> 1500 mV at 1400 mV
[ 0.362515] BUCK3 vdd_int: 1125 mV
[ 0.364629] BUCK4 vdd_g3d: 850 <--> 1200 mV at 1125 mV
[ 0.368533] BUCK5 VDDQ_CKEM1_2: 1200 mV
[ 0.372405] BUCK6 1V35: 1350 mV
[ 0.376273] BUCK7 2V0: 2000 mV
[ 0.378402] ODROIDU2: Regulator BUCK8
[ 0.501539] BUCK8 3V0: 3300 mV
[ 0.504844] BUCK9 1V2: ODROIDU2: Disabled regulator
[ 0.504868] BUCK9 1V2: 1200 mV
[ 0.506094] s3c-i2c s3c2440-i2c.0: i2c-0: S3C I2C adapter
[ 0.506208] s3c-i2c s3c2440-i2c.1: slave address 0x10
[ 0.506234] s3c-i2c s3c2440-i2c.1: bus frequency set to 71 KHz
[ 0.506772] s3c-i2c s3c2440-i2c.1: i2c-1: S3C I2C adapter
[ 0.506873] s3c-i2c s3c2440-i2c.3: slave address 0x10
[ 0.506898] s3c-i2c s3c2440-i2c.3: bus frequency set to 71 KHz
[ 0.507190] s3c-i2c s3c2440-i2c.3: i2c-3: S3C I2C adapter
[ 0.507292] s3c-i2c s3c2440-i2c.7: slave address 0x10
[ 0.507316] s3c-i2c s3c2440-i2c.7: bus frequency set to 71 KHz
[ 0.507632] s3c-i2c s3c2440-i2c.7: i2c-7: S3C I2C adapter
[ 0.507741] s3c-i2c s3c2440-hdmiphy-i2c: slave address 0x10
[ 0.507767] s3c-i2c s3c2440-hdmiphy-i2c: bus frequency set to 71 KHz
[ 0.508058] s3c-i2c s3c2440-hdmiphy-i2c: i2c-8: S3C I2C adapter
[ 0.508277] media: Linux media interface: v0.10
[ 0.508491] Linux video capture interface: v2.00
[ 0.510051] Advanced Linux Sound Architecture Driver Initialized.
[ 0.511315] Switching to clocksource ipipe_tsc
[ 0.535695] NET: Registered protocol family 2
[ 0.536223] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.536379] TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
[ 0.536562] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.536643] TCP: reno registered
[ 0.536669] UDP hash table entries: 512 (order: 2, 24576 bytes)
[ 0.536717] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
[ 0.537049] NET: Registered protocol family 1
[ 0.537406] Trying to unpack rootfs image as initramfs...
[ 1.004578] Freeing initrd memory: 7676K
[ 1.004825] CPU PMU: probing PMU on CPU 1
[ 1.004862] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[ 1.007413] I-pipe: head domain Xenomai registered.
[ 1.007486] Xenomai: hal/arm started.
[ 1.008050] Xenomai: scheduling class idle registered.
[ 1.008071] Xenomai: scheduling class rt registered.
[ 1.018789] Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
[ 1.018815] Xenomai: debug mode enabled.
[ 1.019273] Xenomai: starting native API services.
[ 1.019295] Xenomai: starting POSIX services.
[ 1.019412] Xenomai: starting RTDM services.
[ 1.020103] bounce pool size: 64 pages
[ 1.038242] msgmni has been set to 1470
[ 1.039441] io scheduler noop registered
[ 1.039463] io scheduler deadline registered
[ 1.039840] io scheduler cfq registered (default)
[ 1.054035] dma-pl330 dma-pl330.0: Loaded driver for PL330 DMAC-267056
[ 1.054065] dma-pl330 dma-pl330.0: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 1.062154] dma-pl330 dma-pl330.1: Loaded driver for PL330 DMAC-267056
[ 1.062184] dma-pl330 dma-pl330.1: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 1.064598] dma-pl330 dma-pl330.2: Loaded driver for PL330 DMAC-267056
[ 1.064626] dma-pl330 dma-pl330.2: DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[ 1.217638] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 1.219972] exynos4210-uart.0: ttySAC0 at MMIO 0x13800000 (irq = 84) is a S3C6400/10
[ 1.220491] exynos4210-uart.1: ttySAC1 at MMIO 0x13810000 (irq = 85) is a S3C6400/10
[ 2.253673] console [ttySAC1] enabled
[ 2.257830] exynos4210-uart.2: ttySAC2 at MMIO 0x13820000 (irq = 86) is a S3C6400/10
[ 2.265529] exynos4210-uart.3: ttySAC3 at MMIO 0x13830000 (irq = 87) is a S3C6400/10
[ 2.273856] [drm] Initialized drm 1.1.0 20060810
[ 2.277360] Mali<2>: Inserting Mali v19 device driver.
[ 2.282562] Mali<2>: Compiled: Aug 27 2014, time: 14:15:31.
[ 2.288107] Mali<2>: Driver revision:
[ 2.291842] Mali<2>: mali_module_init() registering driver
[ 2.297347] Mali<2>: mali_probe(): Called for platform device mali-utgard
[ 2.304079] Mali<2>: Memory system initializing
[ 2.308577] Mali<2>: Using device defined memory settings (dedicated: 0x00000000@0x00000000, shared: 0x10000000)
[ 2.318735] Mali<2>: Mali OS memory allocator created with max allocation size of 0x10000000 bytes, cpu_usage_adjust 0x00000000
[ 2.330181] Mali<2>: Using device defined frame buffer settings (0x00000000@0x00000000)
[ 2.338176] mali-utgard mali-utgard.0: start latency exceeded, new value 375 ns
[ 2.345443] mali-utgard mali-utgard.0: state restore latency exceeded, new value 3042 ns
[ 2.353515] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP0
[ 2.359224] Mali<2>: Mali PP: Base address of PP core: 0x13008000
[ 2.365360] Mali<2>: Found Mali GPU Mali-400 MP r1p1
[ 2.371691] Mali<2>: Mali L2 cache: Creating Mali L2 cache: Mali_L2
[ 2.376511] Mali<2>: Mali MMU: Creating Mali MMU: Mali_GP_MMU
[ 2.382239] Mali<2>: Mali GP: Creating Mali GP core: Mali_GP
[ 2.387883] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP0_MMU
[ 2.393682] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP0
[ 2.399374] Mali<2>: Mali PP: Base address of PP core: 0x13008000
[ 2.405471] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP1_MMU
[ 2.411269] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP1
[ 2.416979] Mali<2>: Mali PP: Base address of PP core: 0x1300a000
[ 2.423094] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP2_MMU
[ 2.428909] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP2
[ 2.434586] Mali<2>: Mali PP: Base address of PP core: 0x1300c000
[ 2.440681] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP3_MMU
[ 2.446499] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP3
[ 2.452191] Mali<2>: Mali PP: Base address of PP core: 0x1300e000
[ 2.458301] Mali<2>: 4+0 PP cores initialized
[ 2.462605] Mali<2>: Mali GPU Utilization: No utilization handler installed
[ 2.469577] Mali<2>: = clk_set_rate : 533 , 1000000
[ 2.474854] Mali<2>: = clk_get_rate: 533
[ 2.478451] Mali: init_mali_clock mali_clock c0646f88
[ 2.484320] Mali<1>: = regulator_enable -> use cnt: 1
[ 2.488713] Mali<2>: = regulator_set_voltage: 1125000, 1125000
[ 2.497772] Mali<1>: = regulator_get_voltage: 1125000
[ 2.499699] Mali<2>: MALI Clock is set at mali driver
[ 2.505764] Mali<2>: mali_probe(): Successfully initialized driver for platform device mali-utgard
[ 2.513713] mali-utgard mali-utgard.0: stop latency exceeded, new value 333 ns
[ 2.520904] mali-utgard mali-utgard.0: start latency exceeded, new value 417 ns
[ 2.528218] mali-utgard mali-utgard.0: state save latency exceeded, new value 27584 ns
[ 2.536566] Mali: Mali device driver loaded
[ 2.540715] UMP: UMP device driver loaded
[ 2.558129] brd: module loaded
[ 2.565472] loop: module loaded
[ 2.565698] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.569752] s5p-ehci s5p-ehci: S5P EHCI Host Controller
[ 2.574745] s5p-ehci s5p-ehci: new USB bus registered, assigned bus number 1
[ 2.582224] s5p-ehci s5p-ehci: irq 102, io mem 0x12580000
[ 2.596422] s5p-ehci s5p-ehci: USB 2.0 started, EHCI 1.00
[ 2.596627] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2.602981] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.610185] usb usb1: Product: S5P EHCI Host Controller
[ 2.615379] usb usb1: Manufacturer: Linux 3.8.13.11-xen ehci_hcd
[ 2.621393] usb usb1: SerialNumber: s5p-ehci
[ 2.626571] hub 1-0:1.0: USB hub found
[ 2.629334] hub 1-0:1.0: 3 ports detected
[ 2.634080] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.639603] exynos-ohci exynos-ohci: Already power on PHY
[ 2.644871] exynos-ohci exynos-ohci: EXYNOS OHCI Host Controller
[ 2.650884] exynos-ohci exynos-ohci: new USB bus registered, assigned bus number 2
[ 2.658437] exynos-ohci exynos-ohci: irq 102, io mem 0x12590000
[ 2.720510] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[ 2.721680] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.728877] usb usb2: Product: EXYNOS OHCI Host Controller
[ 2.734344] usb usb2: Manufacturer: Linux 3.8.13.11-xen ohci_hcd
[ 2.740323] usb usb2: SerialNumber: exynos-ohci
[ 2.745767] hub 2-0:1.0: USB hub found
[ 2.748582] hub 2-0:1.0: 3 ports detected
[ 2.857886] usb3503 0-0008: CFG1 failed (-111)
[ 2.857952] usb3503 0-0008: usb3503_probe: probed on hub mode
[ 2.863310] s3c-rtc s3c64xx-rtc: rtc core: registered s3c as rtc0
[ 2.875822] s5p-fimc exynos4-fimc.0: sclk_fimc rate is 176000000
[ 2.876247] s5p-fimc exynos4-fimc.0: start latency exceeded, new value 500 ns
[ 2.883363] s5p-fimc exynos4-fimc.0: state restore latency exceeded, new value 17834 ns
[ 2.891353] s5p-fimc exynos4-fimc.0: stop latency exceeded, new value 459 ns
[ 2.898363] s5p-fimc exynos4-fimc.0: state save latency exceeded, new value 4333 ns
[ 2.901509] s5p-fimc exynos4-fimc.1: sclk_fimc rate is 176000000
[ 2.911988] s5p-fimc exynos4-fimc.1: start latency exceeded, new value 334 ns
[ 2.919086] s5p-fimc exynos4-fimc.1: state restore latency exceeded, new value 16041 ns
[ 2.927081] s5p-fimc exynos4-fimc.1: stop latency exceeded, new value 417 ns
[ 2.934081] s5p-fimc exynos4-fimc.1: state save latency exceeded, new value 3333 ns
[ 2.936510] s5p-fimc exynos4-fimc.2: sclk_fimc rate is 176000000
[ 2.947712] s5p-fimc exynos4-fimc.2: start latency exceeded, new value 333 ns
[ 2.951455] usb 1-2: new high-speed USB device number 2 using s5p-ehci
[ 2.961319] s5p-fimc exynos4-fimc.2: state restore latency exceeded, new value 16250 ns
[ 2.969308] s5p-fimc exynos4-fimc.2: stop latency exceeded, new value 500 ns
[ 2.976313] s5p-fimc exynos4-fimc.2: state save latency exceeded, new value 3375 ns
[ 2.976508] s5p-fimc exynos4-fimc.3: sclk_fimc rate is 176000000
[ 2.989939] s5p-fimc exynos4-fimc.3: start latency exceeded, new value 375 ns
[ 2.997050] s5p-fimc exynos4-fimc.3: state restore latency exceeded, new value 16500 ns
[ 3.005039] s5p-fimc exynos4-fimc.3: stop latency exceeded, new value 500 ns
[ 3.012044] s5p-fimc exynos4-fimc.3: state save latency exceeded, new value 3292 ns
[ 3.020709] s5p-fimc-md: Registered fimc.0.m2m as /dev/video0
[ 3.025734] s5p-fimc-md: Registered fimc.0.capture as /dev/video1
[ 3.031805] s5p-fimc-md: Registered fimc.1.m2m as /dev/video2
[ 3.037528] s5p-fimc-md: Registered fimc.1.capture as /dev/video3
[ 3.043591] s5p-fimc-md: Registered fimc.2.m2m as /dev/video4
[ 3.049323] s5p-fimc-md: Registered fimc.2.capture as /dev/video5
[ 3.055389] s5p-fimc-md: Registered fimc.3.m2m as /dev/video6
[ 3.061109] s5p-fimc-md: Registered fimc.3.capture as /dev/video7
[ 3.068520] sclk_mfc rate is: 220
[ 3.070521] s5p-mfc s5p-mfc: decoder registered as /dev/video8
[ 3.076296] s5p-mfc s5p-mfc: encoder registered as /dev/video9
[ 3.086792] usb 1-2: New USB device found, idVendor=0424, idProduct=9730
[ 3.087560] s5p-hdmiphy 8-0038: probe successful
[ 3.087583] s5p-tv: Board is ODROID-X/X2/U2
[ 3.087590] s5p-hdmi exynos4-hdmi: probe successful
[ 3.087798] Samsung TV Mixer driver, (c) 2010-2011 Samsung Electronics Co., Ltd.
[ 3.087798]
[ 3.098400] s5p-mixer s5p-mixer: probe start
[ 3.098543] s5p-mixer s5p-mixer: resources acquired
[ 3.098560] s5p-mixer s5p-mixer: added output 'S5P HDMI connector' from module 's5p-hdmi'
[ 3.098567] s5p-mixer s5p-mixer: module s5p-sdo is missing
[ 3.098964] s5p-mixer s5p-mixer: registered layer graph0 as /dev/video10
[ 3.140310] fb0: registered frame buffer emulation for /dev/video10
[ 3.140344] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.154054] s5p-mixer s5p-mixer: registered layer graph1 as /dev/video11
[ 3.160712] fb1: registered frame buffer emulation for /dev/video11
[ 3.166980] s5p-mixer s5p-mixer: registered layer video0 as /dev/video12
[ 3.173636] fb2: registered frame buffer emulation for /dev/video12
[ 3.179514] s5p-mixer s5p-mixer: probe successful
[ 3.184874] s5p-g2d s5p-g2d.0: device registered as /dev/video13
[ 3.191152] Exynos: Kernel Thermal management registered
[ 3.195923] cpuidle: using governor ladder
[ 3.199721] sdhci: Secure Digital Host Controller Interface driver
[ 3.205702] sdhci: Copyright(c) Pierre Ossman
[ 3.210166] s3c-sdhci exynos4-sdhci.2: clock source 2: mmc_busclk.2 (440000000 Hz)
[ 3.217683] mmc0: no vqmmc regulator found
[ 3.221662] mmc0: no vmmc regulator found
[ 3.256426] mmc0: SDHCI controller on samsung-hsmmc [exynos4-sdhci.2] using ADMA
[ 3.259871] dw_mmc dw_mmc: Using internal DMA controller.
[ 3.263636] mmc1: no vmmc regulator found
[ 3.296513] dw_mmc dw_mmc: Version ID is 240a
[ 3.296580] dw_mmc dw_mmc: DW MMC controller at irq 109, 32 bit host data width, 128 deep fifo
[ 3.297215] mmc0: new SDHC card at address e624
[ 3.297804] mmcblk0: mmc0:e624 SU08G 7.40 GiB
[ 3.302774] mmcblk0: p1 p2
[ 3.303960] DWMMC: Div 2 = 125
[ 3.303971] mmc_host mmc1: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz, actual 400000HZ div = 125)
[ 3.329992] usbcore: registered new interface driver usbhid
[ 3.333770] usbhid: USB HID core driver
[ 3.364266] mmc1: BKOPS_EN bit is not set
[ 3.366535] DWMMC: Div 1 = 1
[ 3.366589] mmc_host mmc1: Bus speed (slot 0) = 100000000Hz (slot req 52000000Hz, actual 50000000HZ div = 1)
[ 3.371469] usb 1-3: new high-speed USB device number 3 using s5p-ehci
[ 3.373812] max98090 1-0010: revision 0x43
[ 3.381984] [MAX98090] max98090_set_record_main_mic(150)
[ 3.391958] mmc1: new high speed DDR MMC card at address 0001
[ 3.397768] hkdk-snd-max89090 hkdk-snd-max89090: max98090-aif1 <-> samsung-i2s.0 mapping ok
[ 3.397827] mmcblk1: mmc1:0001 008G92 7.28 GiB
[ 3.398050] mmcblk1boot0: mmc1:0001 008G92 partition 1 4.00 MiB
[ 3.398271] mmcblk1boot1: mmc1:0001 008G92 partition 2 4.00 MiB
[ 3.398499] mmcblk1rpmb: mmc1:0001 008G92 partition 3 512 KiB
[ 3.428029] mmcblk1: p1 p2
[ 3.432403] hkdk-snd-max89090 hkdk-snd-max89090: max98090-aif1 <-> samsung-i2s.0 mapping ok
[ 3.439115] mmcblk1boot1: unknown partition table
[ 3.441331] TCP: cubic registered
[ 3.441342] NET: Registered protocol family 17
[ 3.453067] mmcblk1boot0: unknown partition table
[ 3.451120] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 3.463615] ThumbEE CPU extension supported.
[ 3.467922] Registering SWP/SWPB emulation handler
[ 3.476965] LDO20 EMMC_IO_1V8: incomplete constraints, leaving on
[ 3.480511] LDO10 VDD18_MIPI_1V8: incomplete constraints, leaving on
[ 3.486043] DRM: mali_platform_drm_probe()
[ 3.489065] mali_drm_init(), driver name: mali_drm, version 0.1
[ 3.495555] DRM: mali_driver_load()
[ 3.498445] [drm] Initialized mali_drm 0.1.0 20100520 on minor 0
[ 3.504753] s3c-rtc s3c64xx-rtc: setting system clock to 2014-08-27 12:29:12 UTC (1409142552)
[ 3.513287] usb 1-3: New USB device found, idVendor=0424, idProduct=3503
[ 3.519579] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.527748] hub 1-3:1.0: USB hub found
[ 3.529748] exynos4_dvfs_hotplug_init, max(2000000),min(0)
[ 3.529826] ALSA device list:
[ 3.529829] #0: Built-in Audio
[ 3.542142] hub 1-3:1.0: 3 ports detected
[ 3.542502] Freeing init memory: 192K
[ 3.586211] udevd[1364]: starting version 175
[ 3.831660] usb 1-3.3: new high-speed USB device number 4 using s5p-ehci
[ 3.937399] usb 1-3.3: New USB device found, idVendor=0781, idProduct=5577
[ 3.938642] usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.946040] usb 1-3.3: Product: Firebird USB Flash Drive
[ 3.951249] usb 1-3.3: Manufacturer: SanDisk
[ 3.955592] usb 1-3.3: SerialNumber: 4C532000060225109224
[ 4.112540] SCSI subsystem initialized
[ 4.116683] Initializing USB Mass Storage driver...
[ 4.117373] scsi0 : usb-storage 1-3.3:1.0
[ 4.120224] usbcore: registered new interface driver usb-storage
[ 4.125923] USB Mass Storage support registered.
[ 4.213881] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.768537] udevd[1623]: starting version 175
[ 5.002540] gpio-keys gpio-keys.0: Unable to claim irq 427; error -22
[ 5.003393] gpio-keys: probe of gpio-keys.0 failed with error -22
[ 5.091447] s5p-fimc exynos4-fimc.1: state restore latency exceeded, new value 16333 ns
[ 5.093835] s5p-fimc exynos4-fimc.1: stop latency exceeded, new value 500 ns
[ 5.099542] s5p-mfc s5p-mfc: start latency exceeded, new value 333 ns
[ 5.099548] s5p-mfc s5p-mfc: state restore latency exceeded, new value 1375 ns
[ 5.110286] s5p-g2d s5p-g2d.0: instance opened
[ 5.110460] s5p-g2d s5p-g2d.0: instance closed
[ 5.122944] s5p-mixer s5p-mixer: start latency exceeded, new value 500 ns
[ 5.122981] s5p-mixer s5p-mixer: state restore latency exceeded, new value 30000 ns
[ 5.123167] s5p-mixer s5p-mixer: stop latency exceeded, new value 292 ns
[ 5.123183] s5p-mixer s5p-mixer: state save latency exceeded, new value 7875 ns
[ 5.133802] s5p-fimc exynos4-fimc.3: start latency exceeded, new value 500 ns
[ 5.133824] s5p-fimc exynos4-fimc.3: state restore latency exceeded, new value 16792 ns
[ 5.168720] scsi 0:0:0:0: Direct-Access SanDisk Cruzer Pop 1.26 PQ: 0 ANSI: 5
[ 5.186718] s5p-fimc exynos4-fimc.2: start latency exceeded, new value 416 ns
[ 5.188249] s5p-fimc exynos4-fimc.2: state restore latency exceeded, new value 18042 ns
[ 5.198401] s5p-fimc exynos4-fimc.2: stop latency exceeded, new value 875 ns
[ 5.203307] s5p-fimc exynos4-fimc.3: start latency exceeded, new value 542 ns
[ 5.210965] s5p-fimc exynos4-fimc.3: state save latency exceeded, new value 551792 ns
[ 5.218195] s5p-fimc exynos4-fimc.3: stop latency exceeded, new value 708 ns
[ 5.224775] s5p-mixer s5p-mixer: state restore latency exceeded, new value 32083 ns
[ 5.225015] s5p-mixer s5p-mixer: state save latency exceeded, new value 8375 ns
[ 5.240291] s5p-fimc exynos4-fimc.2: start latency exceeded, new value 666 ns
[ 5.247256] s5p-fimc exynos4-fimc.2: state save latency exceeded, new value 6792 ns
[ 5.255804] s5p-mixer s5p-mixer: stop latency exceeded, new value 334 ns
[ 5.258039] s5p-fimc exynos4-fimc.1: start latency exceeded, new value 750 ns
[ 5.258050] s5p-fimc exynos4-fimc.1: state save latency exceeded, new value 6208 ns
[ 5.277258] s5p-mixer s5p-mixer: start latency exceeded, new value 834 ns
[ 5.283721] s5p-mixer s5p-mixer: state save latency exceeded, new value 606250 ns
[ 5.290565] s5p-mixer s5p-mixer: stop latency exceeded, new value 541 ns
[ 5.302202] smsc95xx v1.0.4
[ 5.307591] smsc95xx_read_mac_addr : Can't file(/etc/smsc95xx_mac_addr) create!!
[ 5.312188] smsc95xx 1-2:1.0 (unregistered net_device): Failed to write /etc/smsc95xx_mac_addr file!
[ 5.372977] smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-s5p-ehci-2, smsc95xx USB 2.0 Ethernet, 7a:0c:ab:18:4c:aa
[ 5.378860] usbcore: registered new interface driver smsc95xx
[ 5.525808] s5p_mfc_alloc_and_load_firmware:44: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[ 5.531681] s5p-mfc s5p-mfc: stop latency exceeded, new value 1167 ns
[ 5.537968] s5p-mfc s5p-mfc: start latency exceeded, new value 416 ns
[ 5.544400] s5p-mfc s5p-mfc: state save latency exceeded, new value 2041 ns
[ 5.552261] s5p-mfc s5p-mfc: start latency exceeded, new value 542 ns
[ 5.556477] sd 0:0:0:0: [sda] 31266816 512-byte logical blocks: (16.0 GB/14.9 GiB)
[ 5.558052] sd 0:0:0:0: [sda] Write Protect is off
[ 5.558057] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[ 5.559050] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 5.575323] sda: sda1
[ 5.581544] s5p-mfc s5p-mfc: state restore latency exceeded, new value 3000 ns
[ 5.584681] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 5.600959] s5p_mfc_alloc_and_load_firmware:44: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[ 5.606698] s5p-mfc s5p-mfc: state save latency exceeded, new value 2042 ns
[ 6.033418] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[ 7.259407] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 8.271601] RPC: Registered named UNIX socket transport module.
[ 8.271883] RPC: Registered udp transport module.
[ 8.276578] RPC: Registered tcp transport module.
[ 8.281243] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 8.595159] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 9.389588] [MAX98090] max98090_set_playback_speaker_headset(111)
[ 2406.415314] Xenomai: suspending kernel thread e6b88048 ('timerbench') at 0xc00206d8 after exception #0x0
[ 2568.348646] Xenomai: suspending kernel thread e6561048 ('timerbench') at 0xc00206d8 after exception #0x0
[ 2816.305094] Xenomai: suspending kernel thread e6561048 ('timerbench') at 0xc00206d8 after exception #0x0
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-27 13:49 [Xenomai] ODROID-U3 porting problems GP Orcullo
@ 2014-08-27 15:45 ` Gilles Chanteperdrix
2014-08-27 17:14 ` Gilles Chanteperdrix
2014-08-28 13:45 ` GP Orcullo
0 siblings, 2 replies; 16+ messages in thread
From: Gilles Chanteperdrix @ 2014-08-27 15:45 UTC (permalink / raw)
To: GP Orcullo, xenomai
On 08/27/2014 03:49 PM, GP Orcullo wrote:
> Hi,
>
> I'm in the process of porting xenomai to Samsung Exynos 4420 based
> ODROID-U3 board. I've followed the online manual and I was able to finish
> up to the interrupt controller part.
>
> So far everything works when booting the board with CONFIG_IPIPE and
> CONFIG_XENOMAI enabled. However, running the latency test gives the
> following results:
>
> root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 0 -T5
> == Sampling period: 1000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD|-1054607.854|-555107.854|-416666.667| 0|
> 0|-1054607.854|-416666.667
> RTD|-2054607.854|-1555107.854|-416666.667| 0|
> 0|-2054607.854|-416666.667
> RTD|1240359.443|1739859.443|-416666.667| 0| 0|1240359.443|-416666.667
> RTD| 240359.443| 739859.443|-416666.667| 0| 0| 240359.443|-416666.667
> ---|-----------|-----------|-----------|--------|------|-------------------------
> RTS| 240359.443|-2055107.854|-416666.667| 0| 0| 00:00:05/00:00:05
I would say you have a problem with the tsc emulation. Have you tried to
run the "tsc" program?
> [ 0.000000] Linux version 3.8.13.11-xen (gemi@odroidu3) (gcc version 4.6.3 (Debian 4.6.3-14) ) #34 SMP PREEMPT Wed Aug 27 20:22:46 SGT 2014 ()
3.8.13 is a bit old, I would advise you to use 3.14 if you plan to get
your changes merged.
> [ 0.000000] Kernel was built at commit id ''
> [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
So, this is a cortex a9. On Cortex a9, Xenomai tries to use the global
timer for tsc emulation. Are you sure this processor has a global timer?
Again, running the "tsc" program will help you see if the tsc emulation
is working correctly.
--
Gilles.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-27 15:45 ` Gilles Chanteperdrix
@ 2014-08-27 17:14 ` Gilles Chanteperdrix
2014-08-28 13:45 ` GP Orcullo
1 sibling, 0 replies; 16+ messages in thread
From: Gilles Chanteperdrix @ 2014-08-27 17:14 UTC (permalink / raw)
To: GP Orcullo, xenomai
On 08/27/2014 05:45 PM, Gilles Chanteperdrix wrote:
> On 08/27/2014 03:49 PM, GP Orcullo wrote:
>> Hi,
>>
>> I'm in the process of porting xenomai to Samsung Exynos 4420 based
>> ODROID-U3 board. I've followed the online manual and I was able to finish
>> up to the interrupt controller part.
>>
>> So far everything works when booting the board with CONFIG_IPIPE and
>> CONFIG_XENOMAI enabled. However, running the latency test gives the
>> following results:
>>
>> root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 0 -T5
>> == Sampling period: 1000 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>> RTD|-1054607.854|-555107.854|-416666.667| 0|
>> 0|-1054607.854|-416666.667
>> RTD|-2054607.854|-1555107.854|-416666.667| 0|
>> 0|-2054607.854|-416666.667
>> RTD|1240359.443|1739859.443|-416666.667| 0| 0|1240359.443|-416666.667
>> RTD| 240359.443| 739859.443|-416666.667| 0| 0| 240359.443|-416666.667
>> ---|-----------|-----------|-----------|--------|------|-------------------------
>> RTS| 240359.443|-2055107.854|-416666.667| 0| 0| 00:00:05/00:00:05
>
> I would say you have a problem with the tsc emulation. Have you tried to
> run the "tsc" program?
In fact, your problem is only with the user-space tsc emulation. Are you
sure you passed the right physical address of the counter used for tsc
emulation, in the structure passed to the ipipe_tsc_register service?
You do not seem to be using the global timer, since your counter has a
24 MHz frequency. Note that the global timer probably runs at 500 MHz on
your system, so using the global timer would yield a better precision.
--
Gilles.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-27 15:45 ` Gilles Chanteperdrix
2014-08-27 17:14 ` Gilles Chanteperdrix
@ 2014-08-28 13:45 ` GP Orcullo
2014-08-28 13:51 ` Gilles Chanteperdrix
2014-08-29 23:13 ` Alexandre Donisete Bensi
1 sibling, 2 replies; 16+ messages in thread
From: GP Orcullo @ 2014-08-28 13:45 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, Aug 27, 2014 at 11:45 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 08/27/2014 03:49 PM, GP Orcullo wrote:
>> Hi,
>>
>> I'm in the process of porting xenomai to Samsung Exynos 4420 based
>> ODROID-U3 board. I've followed the online manual and I was able to finish
>> up to the interrupt controller part.
>>
>> So far everything works when booting the board with CONFIG_IPIPE and
>> CONFIG_XENOMAI enabled. However, running the latency test gives the
>> following results:
>>
>> root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 0 -T5
>> == Sampling period: 1000 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>> RTD|-1054607.854|-555107.854|-416666.667| 0|
>> 0|-1054607.854|-416666.667
>> RTD|-2054607.854|-1555107.854|-416666.667| 0|
>> 0|-2054607.854|-416666.667
>> RTD|1240359.443|1739859.443|-416666.667| 0| 0|1240359.443|-416666.667
>> RTD| 240359.443| 739859.443|-416666.667| 0| 0| 240359.443|-416666.667
>> ---|-----------|-----------|-----------|--------|------|-------------------------
>> RTS| 240359.443|-2055107.854|-416666.667| 0| 0| 00:00:05/00:00:05
>
> I would say you have a problem with the tsc emulation. Have you tried to
> run the "tsc" program?
>
>
Thanks for the tip! The problem was due to wrong physical address value.
>> [ 0.000000] Linux version 3.8.13.11-xen (gemi@odroidu3) (gcc version 4.6.3 (Debian 4.6.3-14) ) #34 SMP PREEMPT Wed Aug 27 20:22:46 SGT 2014 ()
>
> 3.8.13 is a bit old, I would advise you to use 3.14 if you plan to get
> your changes merged.
>
Unfortunately this is the only stable version available. A newer version is
being worked on but it is based on 3.16. This will do for the time being,
I'm just using this as a test bed for machinekit.
>> [ 0.000000] Kernel was built at commit id ''
>> [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
>
> So, this is a cortex a9. On Cortex a9, Xenomai tries to use the global
> timer for tsc emulation. Are you sure this processor has a global timer?
> Again, running the "tsc" program will help you see if the tsc emulation
> is working correctly.
AFAIK, the exynos soc doesn't use twd - they have a multi-core timer
instead. There is one global timer and a local timer for each core.
BTW, is it necessary that there should be an ipipe timer for each core
or a single
"global" one will do?
>
>
> --
> Gilles.
Gemi
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 13:45 ` GP Orcullo
@ 2014-08-28 13:51 ` Gilles Chanteperdrix
2014-08-28 15:12 ` Poole Jr, Donald R.
2014-08-29 23:13 ` Alexandre Donisete Bensi
1 sibling, 1 reply; 16+ messages in thread
From: Gilles Chanteperdrix @ 2014-08-28 13:51 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai
On 08/28/2014 03:45 PM, GP Orcullo wrote:
> On Wed, Aug 27, 2014 at 11:45 PM, Gilles Chanteperdrix
>> So, this is a cortex a9. On Cortex a9, Xenomai tries to use the global
>> timer for tsc emulation. Are you sure this processor has a global timer?
>> Again, running the "tsc" program will help you see if the tsc emulation
>> is working correctly.
>
> AFAIK, the exynos soc doesn't use twd - they have a multi-core timer
> instead. There is one global timer and a local timer for each core.
>
> BTW, is it necessary that there should be an ipipe timer for each core
> or a single
> "global" one will do?
The global timer is not the same thing as the twd, and I was talking
about using the global timer as a clock source (for tsc emulation), not
as a timer, the advantage being that you would have a much better
resolution. Xenomai indeed requires local timer support (for which it
uses twd on cortex a9), that is one timer per core.
--
Gilles.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 13:51 ` Gilles Chanteperdrix
@ 2014-08-28 15:12 ` Poole Jr, Donald R.
2014-08-28 16:34 ` GP Orcullo
0 siblings, 1 reply; 16+ messages in thread
From: Poole Jr, Donald R. @ 2014-08-28 15:12 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On 8/28/14, 8:51 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:
>On 08/28/2014 03:45 PM, GP Orcullo wrote:
>> On Wed, Aug 27, 2014 at 11:45 PM, Gilles Chanteperdrix
>>> So, this is a cortex a9. On Cortex a9, Xenomai tries to use the global
>>> timer for tsc emulation. Are you sure this processor has a global
>>>timer?
>>> Again, running the "tsc" program will help you see if the tsc emulation
>>> is working correctly.
>>
>> AFAIK, the exynos soc doesn't use twd - they have a multi-core timer
>> instead. There is one global timer and a local timer for each core.
>>
>> BTW, is it necessary that there should be an ipipe timer for each core
>> or a single
>> "global" one will do?
>
>The global timer is not the same thing as the twd, and I was talking
>about using the global timer as a clock source (for tsc emulation), not
>as a timer, the advantage being that you would have a much better
>resolution. Xenomai indeed requires local timer support (for which it
>uses twd on cortex a9), that is one timer per core.
>
>--
> Gilles.
>
>_______________________________________________
>Xenomai mailing list
>Xenomai@xenomai.org
>http://www.xenomai.org/mailman/listinfo/xenomai
Gemi - Is your work on patching the Odroid-U3 kernel available on github
or elsewhere? I would really like to have my U3 running Xenomai in this
manner as well. I¹ve been working to achieve the same thing, but I
appears that you have made far better progress.
-Donald
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 15:12 ` Poole Jr, Donald R.
@ 2014-08-28 16:34 ` GP Orcullo
2014-08-28 16:40 ` Gilles Chanteperdrix
0 siblings, 1 reply; 16+ messages in thread
From: GP Orcullo @ 2014-08-28 16:34 UTC (permalink / raw)
To: Poole Jr, Donald R.; +Cc: xenomai@xenomai.org
On Thu, Aug 28, 2014 at 11:12 PM, Poole Jr, Donald R.
<donald.poole@swri.org> wrote:
> On 8/28/14, 8:51 AM, "Gilles Chanteperdrix"
> <gilles.chanteperdrix@xenomai.org> wrote:
>
>>On 08/28/2014 03:45 PM, GP Orcullo wrote:
>>> On Wed, Aug 27, 2014 at 11:45 PM, Gilles Chanteperdrix
>>>> So, this is a cortex a9. On Cortex a9, Xenomai tries to use the global
>>>> timer for tsc emulation. Are you sure this processor has a global
>>>>timer?
>>>> Again, running the "tsc" program will help you see if the tsc emulation
>>>> is working correctly.
>>>
>>> AFAIK, the exynos soc doesn't use twd - they have a multi-core timer
>>> instead. There is one global timer and a local timer for each core.
>>>
>>> BTW, is it necessary that there should be an ipipe timer for each core
>>> or a single
>>> "global" one will do?
>>
>>The global timer is not the same thing as the twd, and I was talking
>>about using the global timer as a clock source (for tsc emulation), not
>>as a timer, the advantage being that you would have a much better
>>resolution. Xenomai indeed requires local timer support (for which it
>>uses twd on cortex a9), that is one timer per core.
>>
>>--
>> Gilles.
>>
>>_______________________________________________
>>Xenomai mailing list
>>Xenomai@xenomai.org
>>http://www.xenomai.org/mailman/listinfo/xenomai
>
> Gemi - Is your work on patching the Odroid-U3 kernel available on github
> or elsewhere? I would really like to have my U3 running Xenomai in this
> manner as well. I¹ve been working to achieve the same thing, but I
> appears that you have made far better progress.
>
> -Donald
>
I don't have git access at the moment but attached are the pre and post patches.
They apply to the following tree:
https://github.com/hardkernel/linux/tree/4d40140b44917be7fa344cc8242b8ed0f3e89e97
using the ipipe-core-3.8.13-arm-3.patch
So far it passes all the regression tests except for the switchtest.
-Gemi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: odroidu3.tar.bz2
Type: application/x-bzip2
Size: 24181 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140829/c6465973/attachment.bin>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 16:34 ` GP Orcullo
@ 2014-08-28 16:40 ` Gilles Chanteperdrix
2014-08-28 17:05 ` GP Orcullo
0 siblings, 1 reply; 16+ messages in thread
From: Gilles Chanteperdrix @ 2014-08-28 16:40 UTC (permalink / raw)
To: GP Orcullo, Poole Jr, Donald R.; +Cc: xenomai@xenomai.org
On 08/28/2014 06:34 PM, GP Orcullo wrote:
> So far it passes all the regression tests except for the switchtest.
What error do you get with switchtest ? If pthread_create fails with
resource unavailable error, see:
http://xenomai.org/troubleshooting-a-dual-kernel-configuration/#pthread_create_Resource_temporarily_unavailable
If this is another error, please post the error message and kernel log here.
--
Gilles.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 16:40 ` Gilles Chanteperdrix
@ 2014-08-28 17:05 ` GP Orcullo
2014-08-28 18:34 ` Gilles Chanteperdrix
0 siblings, 1 reply; 16+ messages in thread
From: GP Orcullo @ 2014-08-28 17:05 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Fri, Aug 29, 2014 at 12:40 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 08/28/2014 06:34 PM, GP Orcullo wrote:
>> So far it passes all the regression tests except for the switchtest.
>
> What error do you get with switchtest ? If pthread_create fails with
> resource unavailable error, see:
>
> http://xenomai.org/troubleshooting-a-dual-kernel-configuration/#pthread_create_Resource_temporarily_unavailable
>
> If this is another error, please post the error message and kernel log here.
>
> --
> Gilles.
Running "switchtest rtk0" fails with "Xenomai: suspending kernel
thread f00bb710 ('rtk1/0') at 0xc0020c8c after exception #0x0"
The address is traced to the I-pipe timer interrupt call-back. I think
I maybe missing some spinlocks somewhere.
- Gemi
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 17:05 ` GP Orcullo
@ 2014-08-28 18:34 ` Gilles Chanteperdrix
2014-08-30 0:17 ` GP Orcullo
0 siblings, 1 reply; 16+ messages in thread
From: Gilles Chanteperdrix @ 2014-08-28 18:34 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On 08/28/2014 07:05 PM, GP Orcullo wrote:
> On Fri, Aug 29, 2014 at 12:40 AM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 08/28/2014 06:34 PM, GP Orcullo wrote:
>>> So far it passes all the regression tests except for the switchtest.
>>
>> What error do you get with switchtest ? If pthread_create fails with
>> resource unavailable error, see:
>>
>> http://xenomai.org/troubleshooting-a-dual-kernel-configuration/#pthread_create_Resource_temporarily_unavailable
>>
>> If this is another error, please post the error message and kernel log here.
>>
>> --
>> Gilles.
>
> Running "switchtest rtk0" fails with "Xenomai: suspending kernel
> thread f00bb710 ('rtk1/0') at 0xc0020c8c after exception #0x0"
>
> The address is traced to the I-pipe timer interrupt call-back. I think
> I maybe missing some spinlocks somewhere.
If you are using per-cpu hardware timers, no spinlock is needed, since
each cpu accesses its own timer. If you are using the same (hardware)
timer on several cpus, then it is not going to work anyway, Xenomai
wants one hardware timer per cpu.
--
Gilles.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 18:34 ` Gilles Chanteperdrix
@ 2014-08-30 0:17 ` GP Orcullo
2014-08-30 1:11 ` Gilles Chanteperdrix
2014-08-30 2:22 ` Gilles Chanteperdrix
0 siblings, 2 replies; 16+ messages in thread
From: GP Orcullo @ 2014-08-30 0:17 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Fri, Aug 29, 2014 at 2:34 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 08/28/2014 07:05 PM, GP Orcullo wrote:
>> On Fri, Aug 29, 2014 at 12:40 AM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On 08/28/2014 06:34 PM, GP Orcullo wrote:
>>>> So far it passes all the regression tests except for the switchtest.
>>>
>>> What error do you get with switchtest ? If pthread_create fails with
>>> resource unavailable error, see:
>>>
>>> http://xenomai.org/troubleshooting-a-dual-kernel-configuration/#pthread_create_Resource_temporarily_unavailable
>>>
>>> If this is another error, please post the error message and kernel log here.
>>>
>>> --
>>> Gilles.
>>
>> Running "switchtest rtk0" fails with "Xenomai: suspending kernel
>> thread f00bb710 ('rtk1/0') at 0xc0020c8c after exception #0x0"
>>
>> The address is traced to the I-pipe timer interrupt call-back. I think
>> I maybe missing some spinlocks somewhere.
>
> If you are using per-cpu hardware timers, no spinlock is needed, since
> each cpu accesses its own timer. If you are using the same (hardware)
> timer on several cpus, then it is not going to work anyway, Xenomai
> wants one hardware timer per cpu.
>
> --
> Gilles.
I'm using the mct per-cpu hw timers and it's actually similar to
smp_twd except that the base address is different for each cpu. The
code where switch test fails is on the tick acknowledgement:
[ 224.612412] Xenomai: suspending kernel thread f00d7710 ('rtk1/3')
at 0xc0020c8c after exception #0x0
static void mct_tick_ack(void)
{
c0020c6c: e92d4008 push {r3, lr}
struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
c0020c70: eb092cf5 bl c026c04c <debug_smp_processor_id>
c0020c74: e3022908 movw r2, #10504 ; 0x2908
c0020c78: e34c2064 movt r2, #49252 ; 0xc064
c0020c7c: e30b3570 movw r3, #46448 ; 0xb570
c0020c80: e34c3061 movt r3, #49249 ; 0xc061
exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
c0020c84: e7922100 ldr r2, [r2, r0, lsl #2]
c0020c88: e3a00001 mov r0, #1
c0020c8c: e0823003 add r3, r2, r3
c0020c90: e5931004 ldr r1, [r3, #4]
c0020c94: e2811030 add r1, r1, #48 ; 0x30
}
c0020c98: e8bd4008 pop {r3, lr}
static void mct_tick_ack(void)
{
struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
c0020c9c: eaffff8a b c0020acc <exynos4_mct_write>
Writing to the mct registers is a bit slow I think this is the reason
why the switch test fails:
static void exynos4_mct_write(unsigned int value, void *addr)
{
void __iomem *stat_addr;
u32 mask;
u32 i;
writel_relaxed(value, addr);
/* ... */
/* Wait maximum 1 ms until written values are applied */
for (i = 0; i < loops_per_jiffy / 1000 * HZ; i++)
if (readl_relaxed(stat_addr) & mask) {
writel_relaxed(mask, stat_addr);
return;
}
panic("MCT hangs after writing %d (addr:0x%08x)\n", value, (u32)addr);
}
Is it possible to use a different set of hw timers per cpu other than
the local timers?
I don't have access to the docs so I'm not sure where the ARM
architected timer is or if still exists.
- Gemi
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-30 0:17 ` GP Orcullo
@ 2014-08-30 1:11 ` Gilles Chanteperdrix
2014-08-30 2:22 ` Gilles Chanteperdrix
1 sibling, 0 replies; 16+ messages in thread
From: Gilles Chanteperdrix @ 2014-08-30 1:11 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On 08/30/2014 02:17 AM, GP Orcullo wrote:
> On Fri, Aug 29, 2014 at 2:34 AM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 08/28/2014 07:05 PM, GP Orcullo wrote:
>>> On Fri, Aug 29, 2014 at 12:40 AM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On 08/28/2014 06:34 PM, GP Orcullo wrote:
>>>>> So far it passes all the regression tests except for the switchtest.
>>>>
>>>> What error do you get with switchtest ? If pthread_create fails with
>>>> resource unavailable error, see:
>>>>
>>>> http://xenomai.org/troubleshooting-a-dual-kernel-configuration/#pthread_create_Resource_temporarily_unavailable
>>>>
>>>> If this is another error, please post the error message and kernel log here.
>>>>
>>>> --
>>>> Gilles.
>>>
>>> Running "switchtest rtk0" fails with "Xenomai: suspending kernel
>>> thread f00bb710 ('rtk1/0') at 0xc0020c8c after exception #0x0"
>>>
>>> The address is traced to the I-pipe timer interrupt call-back. I think
>>> I maybe missing some spinlocks somewhere.
>>
>> If you are using per-cpu hardware timers, no spinlock is needed, since
>> each cpu accesses its own timer. If you are using the same (hardware)
>> timer on several cpus, then it is not going to work anyway, Xenomai
>> wants one hardware timer per cpu.
>>
>> --
>> Gilles.
>
> I'm using the mct per-cpu hw timers and it's actually similar to
> smp_twd except that the base address is different for each cpu. The
> code where switch test fails is on the tick acknowledgement:
>
> [ 224.612412] Xenomai: suspending kernel thread f00d7710 ('rtk1/3')
> at 0xc0020c8c after exception #0x0
>
> static void mct_tick_ack(void)
> {
> c0020c6c: e92d4008 push {r3, lr}
> struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
> c0020c70: eb092cf5 bl c026c04c <debug_smp_processor_id>
> c0020c74: e3022908 movw r2, #10504 ; 0x2908
> c0020c78: e34c2064 movt r2, #49252 ; 0xc064
> c0020c7c: e30b3570 movw r3, #46448 ; 0xb570
> c0020c80: e34c3061 movt r3, #49249 ; 0xc061
>
> exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
> c0020c84: e7922100 ldr r2, [r2, r0, lsl #2]
> c0020c88: e3a00001 mov r0, #1
> c0020c8c: e0823003 add r3, r2, r3
> c0020c90: e5931004 ldr r1, [r3, #4]
> c0020c94: e2811030 add r1, r1, #48 ; 0x30
> }
> c0020c98: e8bd4008 pop {r3, lr}
>
> static void mct_tick_ack(void)
> {
> struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
>
> exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
> c0020c9c: eaffff8a b c0020acc <exynos4_mct_write>
>
>
> Writing to the mct registers is a bit slow I think this is the reason
> why the switch test fails:
No, the problem is using smp_processor_id() over a xenomai kernel
thread, it can not work.
Normally, this should not happen. arch/arm/include/asm/percpu.h defines
__my_cpu_offset not to use smp_processor_id(), so this_cpu_ptr should
not use smp_processor_id. You have to figure out why __my_cpu_offset
does not get defined in arch/arm/include/asm/percpu.h
--
Gilles.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-30 0:17 ` GP Orcullo
2014-08-30 1:11 ` Gilles Chanteperdrix
@ 2014-08-30 2:22 ` Gilles Chanteperdrix
2014-08-30 2:40 ` GP Orcullo
1 sibling, 1 reply; 16+ messages in thread
From: Gilles Chanteperdrix @ 2014-08-30 2:22 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On 08/30/2014 02:17 AM, GP Orcullo wrote:
> static void mct_tick_ack(void)
> {
> struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
You have to use __this_cpu_ptr instead of this_cpu_ptr here.
--
Gilles.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai] ODROID-U3 porting problems
2014-08-30 2:22 ` Gilles Chanteperdrix
@ 2014-08-30 2:40 ` GP Orcullo
0 siblings, 0 replies; 16+ messages in thread
From: GP Orcullo @ 2014-08-30 2:40 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Aug 30, 2014 9:22 AM, "Gilles Chanteperdrix" <
gilles.chanteperdrix@xenomai.org> wrote:
>
> On 08/30/2014 02:17 AM, GP Orcullo wrote:
> > static void mct_tick_ack(void)
> > {
> > struct mct_clock_event_device *mevt =
this_cpu_ptr(&percpu_mct_tick);
>
> You have to use __this_cpu_ptr instead of this_cpu_ptr here.
>
> --
> Gilles.
Thanks!
Problem solved.
Next step is to upgrade to a newer kernel.
Cheers,
Gemi
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai] ODROID-U3 porting problems
2014-08-28 13:45 ` GP Orcullo
2014-08-28 13:51 ` Gilles Chanteperdrix
@ 2014-08-29 23:13 ` Alexandre Donisete Bensi
2014-08-30 0:50 ` GP Orcullo
1 sibling, 1 reply; 16+ messages in thread
From: Alexandre Donisete Bensi @ 2014-08-29 23:13 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai
2014-08-28 10:45 GMT-03:00 GP Orcullo <kinsamanka@gmail.com>:
> On Wed, Aug 27, 2014 at 11:45 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 08/27/2014 03:49 PM, GP Orcullo wrote:
>>> Hi,
>>>
>>> I'm in the process of porting xenomai to Samsung Exynos 4420 based
>>> ODROID-U3 board. I've followed the online manual and I was able to finish
>>> up to the interrupt controller part.
>>>
>>> So far everything works when booting the board with CONFIG_IPIPE and
>>> CONFIG_XENOMAI enabled. However, running the latency test gives the
>>> following results:
>>>
>>> root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 0 -T5
>>> == Sampling period: 1000 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>> RTD|-1054607.854|-555107.854|-416666.667| 0|
>>> 0|-1054607.854|-416666.667
>>> RTD|-2054607.854|-1555107.854|-416666.667| 0|
>>> 0|-2054607.854|-416666.667
>>> RTD|1240359.443|1739859.443|-416666.667| 0| 0|1240359.443|-416666.667
>>> RTD| 240359.443| 739859.443|-416666.667| 0| 0| 240359.443|-416666.667
>>> ---|-----------|-----------|-----------|--------|------|-------------------------
>>> RTS| 240359.443|-2055107.854|-416666.667| 0| 0| 00:00:05/00:00:05
>>
>> I would say you have a problem with the tsc emulation. Have you tried to
>> run the "tsc" program?
>>
>>
>
> Thanks for the tip! The problem was due to wrong physical address value.
>
>>> [ 0.000000] Linux version 3.8.13.11-xen (gemi@odroidu3) (gcc version 4.6.3 (Debian 4.6.3-14) ) #34 SMP PREEMPT Wed Aug 27 20:22:46 SGT 2014 ()
>>
>> 3.8.13 is a bit old, I would advise you to use 3.14 if you plan to get
>> your changes merged.
>>
>
> Unfortunately this is the only stable version available. A newer version is
> being worked on but it is based on 3.16. This will do for the time being,
> I'm just using this as a test bed for machinekit.
>
Hello Kinsa!
I had problems upgrading to 3:14 but at the time there was no
specific dtbs for U3, but now they have, even the new uboot to work
correctly with newest kernel : D
If you wish to still I have the binaries for this release, I am
currently running the 3.8 with another realtime kernel, I'm using EMMC
16G with the last LinuxCNC, we can exchange images ;)
Your card is the U3+ version?
http://forum.odroid.com/viewtopic.php?f=80&t=4570
I would like to join to your efforts, allows me?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai] ODROID-U3 porting problems
2014-08-29 23:13 ` Alexandre Donisete Bensi
@ 2014-08-30 0:50 ` GP Orcullo
0 siblings, 0 replies; 16+ messages in thread
From: GP Orcullo @ 2014-08-30 0:50 UTC (permalink / raw)
To: Alexandre Donisete Bensi; +Cc: xenomai@xenomai.org
On Sat, Aug 30, 2014 at 7:13 AM, Alexandre Donisete Bensi
<adbensi@gmail.com> wrote:
> 2014-08-28 10:45 GMT-03:00 GP Orcullo <kinsamanka@gmail.com>:
>> On Wed, Aug 27, 2014 at 11:45 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On 08/27/2014 03:49 PM, GP Orcullo wrote:
>>>> Hi,
>>>>
>>>> I'm in the process of porting xenomai to Samsung Exynos 4420 based
>>>> ODROID-U3 board. I've followed the online manual and I was able to finish
>>>> up to the interrupt controller part.
>>>>
>>>> So far everything works when booting the board with CONFIG_IPIPE and
>>>> CONFIG_XENOMAI enabled. However, running the latency test gives the
>>>> following results:
>>>>
>>>> root@odroidu3:~# /usr/lib/xenomai/testsuite/latency -t 0 -T5
>>>> == Sampling period: 1000 us
>>>> == Test mode: periodic user-mode task
>>>> == All results in microseconds
>>>> warming up...
>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>> RTD|-1054607.854|-555107.854|-416666.667| 0|
>>>> 0|-1054607.854|-416666.667
>>>> RTD|-2054607.854|-1555107.854|-416666.667| 0|
>>>> 0|-2054607.854|-416666.667
>>>> RTD|1240359.443|1739859.443|-416666.667| 0| 0|1240359.443|-416666.667
>>>> RTD| 240359.443| 739859.443|-416666.667| 0| 0| 240359.443|-416666.667
>>>> ---|-----------|-----------|-----------|--------|------|-------------------------
>>>> RTS| 240359.443|-2055107.854|-416666.667| 0| 0| 00:00:05/00:00:05
>>>
>>> I would say you have a problem with the tsc emulation. Have you tried to
>>> run the "tsc" program?
>>>
>>>
>>
>> Thanks for the tip! The problem was due to wrong physical address value.
>>
>>>> [ 0.000000] Linux version 3.8.13.11-xen (gemi@odroidu3) (gcc version 4.6.3 (Debian 4.6.3-14) ) #34 SMP PREEMPT Wed Aug 27 20:22:46 SGT 2014 ()
>>>
>>> 3.8.13 is a bit old, I would advise you to use 3.14 if you plan to get
>>> your changes merged.
>>>
>>
>> Unfortunately this is the only stable version available. A newer version is
>> being worked on but it is based on 3.16. This will do for the time being,
>> I'm just using this as a test bed for machinekit.
>>
>
> Hello Kinsa!
>
> I had problems upgrading to 3:14 but at the time there was no
> specific dtbs for U3, but now they have, even the new uboot to work
> correctly with newest kernel : D
>
> If you wish to still I have the binaries for this release, I am
> currently running the 3.8 with another realtime kernel, I'm using EMMC
> 16G with the last LinuxCNC, we can exchange images ;)
>
> Your card is the U3+ version?
> http://forum.odroid.com/viewtopic.php?f=80&t=4570
>
> I would like to join to your efforts, allows me?
Sure, any help is welcome :)
I have the U3+.
I don't have access to github at the moment, I will post it up next week.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-08-30 2:40 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-27 13:49 [Xenomai] ODROID-U3 porting problems GP Orcullo
2014-08-27 15:45 ` Gilles Chanteperdrix
2014-08-27 17:14 ` Gilles Chanteperdrix
2014-08-28 13:45 ` GP Orcullo
2014-08-28 13:51 ` Gilles Chanteperdrix
2014-08-28 15:12 ` Poole Jr, Donald R.
2014-08-28 16:34 ` GP Orcullo
2014-08-28 16:40 ` Gilles Chanteperdrix
2014-08-28 17:05 ` GP Orcullo
2014-08-28 18:34 ` Gilles Chanteperdrix
2014-08-30 0:17 ` GP Orcullo
2014-08-30 1:11 ` Gilles Chanteperdrix
2014-08-30 2:22 ` Gilles Chanteperdrix
2014-08-30 2:40 ` GP Orcullo
2014-08-29 23:13 ` Alexandre Donisete Bensi
2014-08-30 0:50 ` GP Orcullo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.