* [Xenomai] imx6q xenomai ipipe-3.0-imx6q
@ 2014-03-26 11:36 嵌入式工程师
2014-03-26 11:50 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-26 11:36 UTC (permalink / raw)
To: Gilles Chanteperdrix, xenomai
I use imx6q xenomai ipipe-3.0-imx6q ，i don`t know if rt_pipe and rt_timer will affect the latency?because I use lots of rt_pipe command and when I send the rt_pipe command the latency will like blow
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 1.567| 2.023| 5.199| 0| 0| 1.282| 326.962
RTD| 1.560| 2.050| 5.492| 0| 0| 1.282| 326.962
RTD| 1.522| 2.066| 5.984| 0| 0| 1.282| 326.962
RTD| 1.552| 2.056| 4.938| 0| 0| 1.282| 326.962
RTD| 1.572| 2.040| 5.021| 0| 0| 1.282| 326.962
RTD| 1.536| 2.047| 4.678| 0| 0| 1.282| 326.962
RTD| 1.599| 2.052| 5.442| 0| 0| 1.282| 326.962
RTD| 1.639| 2.080| 6.692| 0| 0| 1.282| 326.962
RTD| 1.533| 2.056| 6.869| 0| 0| 1.282| 326.962
RTD| 1.578| 2.036| 5.364| 0| 0| 1.282| 326.962
RTD| 1.583| 2.042| 5.222| 0| 0| 1.282| 326.962
RTD| 1.522| 2.052| 5.702| 0| 0| 1.282| 326.962
RTD| 1.542| 2.042| 5.272| 0| 0| 1.282| 326.962
RTD| 1.618| 2.049| 5.580| 0| 0| 1.282| 326.962
RTD| 1.555| 2.059| 6.398| 0| 0| 1.282| 326.962
RTD| 1.527| 2.054| 5.862| 0| 0| 1.282| 326.962
RTD| 1.564| 2.038| 5.951| 0| 0| 1.282| 326.962
RTD| 1.567| 2.053| 4.857| 0| 0| 1.282| 326.962
RTD| 1.597| 2.072| 5.433| 0| 0| 1.282| 326.962
RTD| 1.533| 2.057| 5.725| 0| 0| 1.282| 326.962
RTD| 1.634| 2.055| 5.566| 0| 0| 1.282| 326.962
RTT| 00:10:10 (in-kernel periodic task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 1.523| 2.063| 4.874| 0| 0| 1.282| 326.962
RTD| 1.601| 2.036| 4.922| 0| 0| 1.282| 326.962
RTD| 1.573| 2.064| 5.237| 0| 0| 1.282| 326.962
RTD| 1.563| 2.040| 5.386| 0| 0| 1.282| 326.962
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-26 11:36 [Xenomai] imx6q xenomai ipipe-3.0-imx6q 嵌入式工程师
@ 2014-03-26 11:50 ` Gilles Chanteperdrix
2014-03-26 13:31 ` 嵌入式工程师
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-26 11:50 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 03/26/2014 12:36 PM, 嵌入式工程师 wrote:
> I use imx6q xenomai ipipe-3.0-imx6q ，i don`t know if rt_pipe and
> rt_timer will affect the latency?because I use lots of rt_pipe command
> and when I send the rt_pipe command the latency will like blow
Could you post an example of code allowing to reproduce this problem?
Does the same problem happen if you use the xddp interface instead of
the (deprecated) rt_pipe interface?
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-26 11:50 ` Gilles Chanteperdrix
@ 2014-03-26 13:31 ` 嵌入式工程师
2014-03-26 13:34 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-26 13:31 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
I actually don't know if it caused by rt_pipe ,in user layer i used Qt and Qt call large quantity rt_pipe in a short time then the latency is like that ,i enabled smp ,it is impact that. can i only use one core, do real-time kernel?
在 2014-03-26 19:50:55，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/26/2014 12:36 PM, 嵌入式工程师 wrote:
>> I use imx6q xenomai ipipe-3.0-imx6q ，i don`t know if rt_pipe and
>> rt_timer will affect the latency?because I use lots of rt_pipe command
>> and when I send the rt_pipe command the latency will like blow
>
>Could you post an example of code allowing to reproduce this problem?
>Does the same problem happen if you use the xddp interface instead of
>the (deprecated) rt_pipe interface?
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-26 13:31 ` 嵌入式工程师
@ 2014-03-26 13:34 ` Gilles Chanteperdrix
2014-03-26 14:29 ` 嵌入式工程师
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-26 13:34 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 03/26/2014 02:31 PM, 嵌入式工程师 wrote:
> I actually don't know if it caused by rt_pipe ,in user layer i used Qt and Qt call large quantity rt_pipe
I doubt very much QT uses rt_pipes, unless you modified it to do so.
From the latencies below, I would say you are not running with the
kernel from the git branch I indicated.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-26 13:34 ` Gilles Chanteperdrix
@ 2014-03-26 14:29 ` 嵌入式工程师
2014-03-26 23:09 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-26 14:29 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
i use ipipe-gch-ipipe-3.0-imx6q.tar.bz2 with xenomai-2.6.3 /mxc/ipip-3.0.43* patch ,it is not right?
在 2014-03-26 21:34:17，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/26/2014 02:31 PM, 嵌入式工程师 wrote:
>> I actually don't know if it caused by rt_pipe ,in user layer i used Qt and Qt call large quantity rt_pipe
>
>I doubt very much QT uses rt_pipes, unless you modified it to do so.
> From the latencies below, I would say you are not running with the
>kernel from the git branch I indicated.
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-26 14:29 ` 嵌入式工程师
@ 2014-03-26 23:09 ` Gilles Chanteperdrix
2014-03-27 1:41 ` 嵌入式工程师
2014-03-27 5:24 ` 嵌入式工程师
0 siblings, 2 replies; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-26 23:09 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 03/26/2014 03:29 PM, 嵌入式工程师 wrote:
> i use ipipe-gch-ipipe-3.0-imx6q.tar.bz2 with xenomai-2.6.3 /mxc/ipip-3.0.43* patch ,it is not right?
No, you should use git to checkout the ipipe-3.0-imx6q from the
ipipe-gch git, and run prepare-kernel.sh from xenomai sources, you do
not need to apply the pre- and post- patches, the ipipe-3.0-imx6q is the
branch from which the pre- and post- patches are made.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-26 23:09 ` Gilles Chanteperdrix
@ 2014-03-27 1:41 ` 嵌入式工程师
2014-03-27 5:24 ` 嵌入式工程师
1 sibling, 0 replies; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-27 1:41 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
oh,i use http with ie download the ipipe-gch-ipipe-3.0-imx6q and apply the pre- and post- patches,now i try git checkout the ipipe-3.0-imx6q ,without apply the pre- and post- patches .Thanks very much.
在 2014-03-27 07:09:35，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/26/2014 03:29 PM, 嵌入式工程师 wrote:
>> i use ipipe-gch-ipipe-3.0-imx6q.tar.bz2 with xenomai-2.6.3 /mxc/ipip-3.0.43* patch ,it is not right?
>
>No, you should use git to checkout the ipipe-3.0-imx6q from the
>ipipe-gch git, and run prepare-kernel.sh from xenomai sources, you do
>not need to apply the pre- and post- patches, the ipipe-3.0-imx6q is the
>branch from which the pre- and post- patches are made.
>
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-26 23:09 ` Gilles Chanteperdrix
2014-03-27 1:41 ` 嵌入式工程师
@ 2014-03-27 5:24 ` 嵌入式工程师
2014-03-27 12:27 ` Gilles Chanteperdrix
1 sibling, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-27 5:24 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
I do as you said ,the result is the matter still has ,but when i change
UIMAGE arch/arm/boot/uImage
Image Name: Linux-3.0.43-ge13355f
Created: Thu Mar 27 11:07:59 2014
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3448764 Bytes = 3367.93 kB = 3.29 MB
Load Address: 10008000
Entry Point: 10008000
Image arch/arm/boot/uImage is ready
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
to
CONFIG_SMP=n
CONFIG_SMP_ON_UP=n
CONFIG_BROKEN_ON_SMP=y
the up-kernal start and latency start and do my program
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 7.318| 8.418| 11.318| 0| 0| 6.998| 19.656
RTD| 7.318| 8.695| 17.651| 0| 0| 6.998| 19.656
RTD| 7.318| 8.354| 10.985| 0| 0| 6.998| 19.656
RTD| 7.318| 8.346| 11.651| 0| 0| 6.998| 19.656
RTD| 7.317| 8.429| 11.651| 0| 0| 6.998| 19.656
RTD| 7.317| 8.310| 10.984| 0| 0| 6.998| 19.656
RTD| 7.317| 8.421| 16.984| 0| 0| 6.998| 19.656
RTD| 7.317| 8.627| 12.317| 0| 0| 6.998| 19.656
RTD| 7.316| 8.584| 11.650| 0| 0| 6.998| 19.656
RTD| 7.316| 8.468| 12.983| 0| 0| 6.998| 19.656
RTD| 7.316| 8.695| 13.982| 0| 0| 6.998| 19.656
RTD| 7.316| 8.754| 18.649| 0| 0| 6.998| 19.656
RTD| 7.315| 8.518| 11.649| 0| 0| 6.998| 19.656
RTD| 7.315| 8.583| 11.315| 0| 0| 6.998| 19.656
RTD| 7.315| 8.536| 12.315| 0| 0| 6.998| 19.656
RTD| 7.315| 8.450| 10.981| 0| 0| 6.998| 19.656
RTD| 7.314| 8.390| 11.981| 0| 0| 6.998| 19.656
RTD| 7.314| 8.392| 12.314| 0| 0| 6.998| 19.656
RTD| 7.314| 8.363| 11.314| 0| 0| 6.998| 19.656
RTD| 7.314| 8.386| 11.314| 0| 0| 6.998| 19.656
RTD| 7.313| 8.394| 11.980| 0| 0| 6.998| 19.656
RTT| 00:01:25 (in-kernel periodic task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 7.313| 8.383| 12.647| 0| 0| 6.998| 19.656
RTD| 7.313| 8.397| 11.313| 0| 0| 6.998| 19.656
RTD| 7.313| 8.354| 11.313| 0| 0| 6.998| 19.656
^C---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 6.998| 8.465| 19.656| 0| 0| 00:01:27/00:01:27
在 2014-03-27 07:09:35，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/26/2014 03:29 PM, 嵌入式工程师 wrote:
>> i use ipipe-gch-ipipe-3.0-imx6q.tar.bz2 with xenomai-2.6.3 /mxc/ipip-3.0.43* patch ,it is not right?
>
>No, you should use git to checkout the ipipe-3.0-imx6q from the
>ipipe-gch git, and run prepare-kernel.sh from xenomai sources, you do
>not need to apply the pre- and post- patches, the ipipe-3.0-imx6q is the
>branch from which the pre- and post- patches are made.
>
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-27 5:24 ` 嵌入式工程师
@ 2014-03-27 12:27 ` Gilles Chanteperdrix
2014-03-28 5:02 ` 嵌入式工程师
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-27 12:27 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 03/27/2014 06:24 AM, 嵌入式工程师 wrote:
> I do as you said ,the result is the matter still has ,but when i change
>
> UIMAGE arch/arm/boot/uImage
> Image Name: Linux-3.0.43-ge13355f
> Created: Thu Mar 27 11:07:59 2014
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 3448764 Bytes = 3367.93 kB = 3.29 MB
> Load Address: 10008000
> Entry Point: 10008000
> Image arch/arm/boot/uImage is ready
>
>
> CONFIG_SMP=y
> CONFIG_SMP_ON_UP=y
> to
> CONFIG_SMP=n
> CONFIG_SMP_ON_UP=n
> CONFIG_BROKEN_ON_SMP=y
> the up-kernal start and latency start and do my program
Turning off SMP improves latency, that is a general rule, for all
processors. The problem is that if you do that you do not take advantage
of all the cores your processor has. The question is: what latency did
you have with the correct branch? If it is, say, less than 80us, it is a
bit high but may still be normal. If it is 300us, then you may still
have a problem, it depends on the answer you give to the questions I
asked about your usage of rt_pipes.
To be sure that you are running the kernel I expect, could you show us
the boot logs?
Regards.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-27 12:27 ` Gilles Chanteperdrix
@ 2014-03-28 5:02 ` 嵌入式工程师
2014-03-28 17:35 ` Gilles Chanteperdrix
2014-03-28 8:19 ` 嵌入式工程师
2014-03-28 9:08 ` 嵌入式工程师
2 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-28 5:02 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
This is my logs
Starting kernel ...
Linux version 3.0.43 (lucid@ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #5 SMP PREEMPT Thu Mar 27 19:41:48 PDT 2014
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX 6Quad/DualLite/Solo LYNUC EVB Board
======================fire lynuc evb ========================
======================######################## ========================
Ignoring unrecognised tag 0x54410008
Memory policy: ECC disabled, Data cache writealloc
CPU identified as i.MX6Q, silicon rev 1.2
PERCPU: Embedded 9 pages/cpu @8c008000 s14496 r8192 d14176 u36864
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 227328
Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk0p1 rootwait
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 640MB 256MB = 896MB total
Memory: 896264k/896264k available, 152312k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xf4600000 - 0xffe00000 ( 184 MB)
vmalloc : 0xc0800000 - 0xf2000000 ( 792 MB)
lowmem : 0x80000000 - 0xc0000000 (1024 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.init : 0x80008000 - 0x80043000 ( 236 kB)
.text : 0x80043000 - 0x80aff898 (10995 kB)
.data : 0x80b00000 - 0x80b57280 ( 349 kB)
.bss : 0x80b572a4 - 0x80bcbaac ( 467 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:496
MXC GPIO hardware
sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms
MXC_Early serial console at MMIO 0x2020000 (options '115200')
bootconsole [ttymxc0] enabled
I-pipe 1.18-13: pipeline enabled.
Console: colour dummy device 80x30
Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
I-pipe, 396.000 MHz timer
I-pipe, 396.000 MHz clocksource
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated (6324.22 BogoMIPS).
print_constraints: dummy:
NET: Registered protocol family 16
print_constraints: vddpu: 725 <--> 1300 mV at 700 mV fast normal
print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV fast normal
print_constraints: vddsoc: 725 <--> 1300 mV at 1200 mV fast normal
print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV fast normal
print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV fast normal
print_constraints: vdd3p0: 2800 <--> 3150 mV at 3000 mV fast normal
CLKCTL_CCGR6=c00
cscmr1=12700007
rate=52800000
Warning: emi_slow_clk not set to 132 MHz! WEIM NOR timing may be incorrect!
hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.
hw-breakpoint: maximum watchpoint size is 4 bytes.
L310 cache controller enabled
l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02870000, Cache size: 1048576 B
IMX usb wakeup probe
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Freescale USB OTG Driver loaded, $Revision: 1.55 $
add wake up source irq 75
imx-ipuv3 imx-ipuv3.0: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)
imx-ipuv3 imx-ipuv3.1: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)
MIPI CSI2 driver module loaded
Advanced Linux Sound Architecture Driver Version 1.0.24.
Bluetooth: Core ver 2.16
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
cfg80211: Calling CRDA to update world regulatory domain
i2c-core: driver [max17135] using legacy suspend method
i2c-core: driver [max17135] using legacy resume method
Switching to clocksource ipipe_tsc
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Static Power Management for Freescale i.MX6
wait mode is disabled for i.MX6
cpaddr = c0880000 suspend_iram_base=c08ea000
PM driver module loaded
IMX usb wakeup probe
I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
msgmni has been set to 1750
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
MIPI DSI driver module loaded
mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver ldb
mxc_sdc_fb mxc_sdc_fb.0: NO mxc display driver found!
mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver ldb
mxc_sdc_fb mxc_sdc_fb.1: NO mxc display driver found!
mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver lcd
Console: switching to colour frame buffer device 100x30
imx-sdma imx-sdma: loaded firmware 1.1
imx-sdma imx-sdma: initialized
Serial: IMX driver
imx-uart.0: ttymxc0 at MMIO 0x2020000 (irq = 58) is a IMX
console [ttymxc0] enabled, bootconsole disabled
console [ttymxc0] enabled, bootconsole disabled
loop: module loaded
Can't recover from RESET HBA!
No sata disk.
vcan: Virtual CAN interface driver
CAN device driver interface
flexcan netdevice driver
flexcan imx6q-flexcan.0: device registered (reg_base=c0978000, irq=142)
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver net1080
usbcore: registered new interface driver cdc_subset
usbcore: registered new interface driver zaurus
cdc_ncm: 04-Aug-2011
usbcore: registered new interface driver cdc_ncm
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 75, io base 0x02184000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
add wake up source irq 72
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-efsl-ehci fsl-ehci.1: irq 72, io base 0x02184200
fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ARC USBOTG Device Controller driver (1 August 2005)
mousedev: PS/2 mouse device common for all mice
input: gpio-keys as /devices/platform/gpio-keys/input/input0
i2c-core: driver [isl29023] using legacy suspend method
i2c-core: driver [isl29023] using legacy resume method
i2c /dev entries driver
Linux video capture intehod
i2c-core: driver [mag3110] using legacy resume method
imx2-wdt imx2-wdt.0: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=1)
Bluetooth: Virtual HCI driver ver 1.3
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCIATH3K protocol initialized
Bluetooth: Generic Bluetooth USB driver ver 0.6
usbcore: registered new interface driver btusb
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
mmc0: no vmmc regulator found
mmc0: SDHCI controller on platform [sdhci-esdhc-imx.2] using DMA
mmc1: no vmmc regulator found
mmc1: SDHCI controller on platform [sdhci-esdhc-imx.1] using DMA
mxc_asrc registered
Thermal calibration data is 0x5ec55d69
Anatop Thermal registered as thermal_zone0
anatop_thermal_probe: default cooling device is cpufreq!
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver snd-usb-audio
Cirrus Logic CS42888 ALSA SoC Codec Driver
i2c-core: driver [cs42888] using legacy suspend method
i2c-core: driver [cs42888] using legacy resume method
imx_3stack asoc driver
ALSA device list:
No soundcards found.
NET: Registered protocol family 26
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t)
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
lib80211: common routines for IEEE802.11 drivers
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
Bus freq driver module loaded
Bus freq driver Enabled
mxc_dvfs_core_probe
DVFS driver module loaded
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Waiting for root device /dev/mmcblk0p1...
-sh-2.05b# smsc95xx 2-1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1
在 2014-03-27 20:27:15，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/27/2014 06:24 AM, 嵌入式工程师 wrote:
>> I do as you said ,the result is the matter still has ,but when i change
>>
>> UIMAGE arch/arm/boot/uImage
>> Image Name: Linux-3.0.43-ge13355f
>> Created: Thu Mar 27 11:07:59 2014
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 3448764 Bytes = 3367.93 kB = 3.29 MB
>> Load Address: 10008000
>> Entry Point: 10008000
>> Image arch/arm/boot/uImage is ready
>>
>>
>> CONFIG_SMP=y
>> CONFIG_SMP_ON_UP=y
>> to
>> CONFIG_SMP=n
>> CONFIG_SMP_ON_UP=n
>> CONFIG_BROKEN_ON_SMP=y
>> the up-kernal start and latency start and do my program
>
>Turning off SMP improves latency, that is a general rule, for all
>processors. The problem is that if you do that you do not take advantage
>of all the cores your processor has. The question is: what latency did
>you have with the correct branch? If it is, say, less than 80us, it is a
>bit high but may still be normal. If it is 300us, then you may still
>have a problem, it depends on the answer you give to the questions I
>asked about your usage of rt_pipes.
>
>To be sure that you are running the kernel I expect, could you show us
>the boot logs?
>
>Regards.
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-28 5:02 ` 嵌入式工程师
@ 2014-03-28 17:35 ` Gilles Chanteperdrix
2014-03-29 5:54 ` 嵌入式工程师
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-28 17:35 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 03/28/2014 06:02 AM, 嵌入式工程师 wrote:
> This is my logs
>
>
>
>
> (...)
> hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
I guess you should probably not enable perf. On some architectures, it
creates unwanted latencies, by using NMI.
> (...)
> l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02870000, Cache size: 1048576 B
So, your auxiliary register has bit 23 set (0x800000), and has L2 write
allocate disabled.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-28 17:35 ` Gilles Chanteperdrix
@ 2014-03-29 5:54 ` 嵌入式工程师
0 siblings, 0 replies; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-29 5:54 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
thanks vary mach , I disable perf and have a try .Yes ,the auxiliary register has bit 23 set (0x800000), and has L2 write
allocate disabled.
在 2014-03-29 01:35:33，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/28/2014 06:02 AM, 嵌入式工程师 wrote:
>> This is my logs
>>
>>
>>
>>
> > (...)
>> hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
>
>I guess you should probably not enable perf. On some architectures, it
>creates unwanted latencies, by using NMI.
>
> > (...)
>> l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02870000, Cache size: 1048576 B
>
>So, your auxiliary register has bit 23 set (0x800000), and has L2 write
>allocate disabled.
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-27 12:27 ` Gilles Chanteperdrix
2014-03-28 5:02 ` 嵌入式工程师
@ 2014-03-28 8:19 ` 嵌入式工程师
2014-03-28 17:37 ` Gilles Chanteperdrix
2014-03-28 9:08 ` 嵌入式工程师
2 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-28 8:19 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
THis is my newtest on my imx6q board with ipipe-3.0-imx6q
my boot logs
WARNING! The remote SSH server rejected X11 forwarding request.
-sh-2.05b# dmesg
Linux version 3.0.43 (lucid@ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #10 SMP PREEMPT Fri Mar 28 00:58:23 PDT 2014
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX 6Quad/DualLite/Solo LYNUC EVB Board
======================fire lynuc evb ========================
======================######################## ========================
Ignoring unrecognised tag 0x54410008
Memory policy: ECC disabled, Data cache writealloc
CPU identified as i.MX6Q, silicon rev 1.2
On node 0 totalpages: 229376
free_area_init_node: node 0, pgdat 806e0f80, node_mem_map 8b800000
DMA zone: 368 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 46736 pages, LIFO batch:15
Normal zone: 1680 pages used for memmap
Normal zone: 180592 pages, LIFO batch:31
PERCPU: Embedded 9 pages/cpu @8c008000 s14464 r8192 d14208 u36864
pcpu-alloc: s14464 r8192 d14208 u36864 alloc=9*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 227328
Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk0p1 rootwait
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 640MB 256MB = 896MB total
Memory: 900976k/900976k available, 147600k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xf4600000 - 0xffe00000 ( 184 MB)
vmalloc : 0xc0800000 - 0xf2000000 ( 792 MB)
lowmem : 0x80000000 - 0xc0000000 (1024 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.init : 0x80008000 - 0x80040000 ( 224 kB)
.text : 0x80040000 - 0x8069bec0 (6512 kB)
.data : 0x8069c000 - 0x806e2020 ( 281 kB)
.bss : 0x806e2044 - 0x80731c0c ( 319 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:496
MXC GPIO hardware
sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms
MXC_Early serial console at MMIO 0x2020000 (options '115200')
bootconsole [ttymxc0] enabled
I-pipe 1.18-13: pipeline enabled.
Console: colour dummy device 80x30
Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
I-pipe, 396.000 MHz timer
I-pipe, 396.000 MHz clocksource
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated (6324.22 BogoMIPS).
print_constraints: dummy:
NET: Registered protocol family 16
print_constraints: vddpu: 725 <--> 1300 mV at 700 mV fast normal
print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV fast normal
print_constraints: vddsoc: 725 <--> 1300 mV at 1200 mV fast normal
print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV fast normal
print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV fast normal
print_constraints: vdd3p0: 2800 <--> 3150 mV at 3000 mV fast normal
CLKCTL_CCGR6=c00
cscmr1=12700007
rate=52800000
Warning: emi_slow_clk not set to 132 MHz! WEIM NOR timing may be incorrect!
No AHCI save PWR: PDDQ enabled
hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.
hw-breakpoint: maximum watchpoint size is 4 bytes.
L310 cache controller enabled
l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02870000, Cache size: 1048576 B
IMX usb wakeup probe
the wakeup pdata is 0xbfe37500
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Freescale USB OTG Driver loaded, $Revision: 1.55 $
add wake up source irq 75
imx-ipuv3 imx-ipuv3.0: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)
imx-ipuv3 imx-ipuv3.1: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)
MIPI CSI2 driver module loaded
Advanced Linux Sound Architecture Driver Version 1.0.24.
Bluetooth: Core ver 2.16
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
cfg80211: Calling CRDA to update world regulatory domain
i2c-core: driver [max17135] using legacy suspend method
i2c-core: driver [max17135] using legacy resume method
Switching to clocksource ipipe_tsc
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Static Power Management for Freescale i.MX6
wait mode is disabled for i.MX6
cpaddr = c0880000 suspend_iram_base=c08ec000
PM driver module loaded
IMX usb wakeup probe
the wakeup pdata is 0xbfe8bb40
I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
JFFS2 version 2.2. (NAND) 漏 2001-2006 Red Hat, Inc.
msgmni has been set to 1759
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver ldb
mxc_sdc_fb mxc_sdc_fb.0: NO mxc display driver found!
mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver ldb
mxc_sdc_fb mxc_sdc_fb.1: NO mxc display driver found!
mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver lcd
imx-sdma imx-sdma: loaded firmware 1.1
imx-sdma imx-sdma: initialized
Serial: IMX driver
imx-uart.0: ttymxc0 at MMIO 0x2020000 (irq = 58) is a IMX
console [ttymxc0] enabled, bootconsole disabled
loop: module loaded
vcan: Virtual CAN interface driver
CAN device driver interface
flexcan netdevice driver
flexcan imx6q-flexcan.0: device registered (reg_base=c0938000, irq=142)
usbcore: registered new interface driver smsc95xx
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 75, io base 0x02184000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
add wake up source irq 72
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
fsl-ehci fsl-ehci.1: irq 72, io base 0x02184200
fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ARC USBOTG Device Controller driver (1 August 2005)
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC ee:3a:a3:34:e2:9f
usb0: HOST MAC 52:55:42:06:24:27
g_ether gadget: controller 'fsl-usb2-udc' not recognized; trying CDC Ethernet (EEM)
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
Suspend udc for OTG auto detect
USB Host suspend begins
will suspend roothub and its children
ehci_fsl_bus_suspend begins, DR
ehci_fsl_bus_suspend ends, DR
host suspend ends
USB Gadget resume begins
fsl_udc_resume, Wait for wakeup thread finishes
dr_controller_run: udc enter low power mode
USB Gadget resume ends
fsl-usb2-udc: bind to driver g_ether
mousedev: PS/2 mouse device common for all mice
input: gpio-keys as /devices/platform/gpio-keys/input/input0
i2c-core: driver [isl29023] using legacy suspend method
i2c-core: driver [isl29023] using legacy resume method
i2c /dev entries driver
imx2-wdt imx2-wdt.0: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=1)
Bluetooth: Virtual HCI driver ver 1.3
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCIATH3K protocol initialized
Bluetooth: Generic Bluetooth USB driver ver 0.6
usbcore: registered new interface driver btusb
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
mmc0: no vmmc regulator found
mmc0: SDHCI controller on platform [sdhci-esdhc-imx.2] using DMA
mmc1: no vmmc regulator found
mmc1: SDHCI controller on platform [sdhci-esdhc-imx.1] using DMA
mxc_asrc registered
Thermal calibration data is 0x5ec55d69
Anatop Thermal registered as thermal_zone0
anatop_thermal_probe: default cooling device is cpufreq!
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver snd-usb-audio
Cirrus Logic CS42888 ALSA SoC Codec Driver
i2c-core: driver [cs42888] using legacy suspend method
i2c-core: driver [cs42888] using legacy resume method
imx_3stack asoc driver
ALSA device list:
No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t)
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
lib80211: common routines for IEEE802.11 drivers
lib80211_crypt: registered algorithm 'NULL'
lib80211_crypt: registered algorithm 'WEP'
lib80211_crypt: registered algorithm 'CCMP'
lib80211_crypt: registered algorithm 'TKIP'
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
Bus freq driver module loaded
usb 2-1: new high speed USB device number 2 using fsl-ehci
Bus freq driver Enabled
mxc_dvfs_core_probe
DVFS driver module loaded
mmc0: new high speed DDR MMC card at address 0001
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Waiting for root device /dev/mmcblk0p1...
mmcblk0: mmc0:0001 SEM04G 3.68 GiB
mmcblk0boot0: mmc0:0001 SEM04G partition 1 1.00 MiB
mmcblk0boot1: mmc0:0001 SEM04G partition 2 1.00 MiB
mmcblk0: p1
mmcblk0boot1: unknown partition table
mmcblk0boot0: unknown partition table
EXT3-fs: barriers not enabled
smsc95xx v1.0.4
smsc95xx 2-1:1.0: eth0: register 'smsc95xx' at usb-fsl-ehci.1-1, smsc95xx USB 2.0 Ethernet, 00:80:0f:9e:04:23
在 2014-03-27 20:27:15，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/27/2014 06:24 AM, 嵌入式工程师 wrote:
>> I do as you said ,the result is the matter still has ,but when i change
>>
>> UIMAGE arch/arm/boot/uImage
>> Image Name: Linux-3.0.43-ge13355f
>> Created: Thu Mar 27 11:07:59 2014
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 3448764 Bytes = 3367.93 kB = 3.29 MB
>> Load Address: 10008000
>> Entry Point: 10008000
>> Image arch/arm/boot/uImage is ready
>>
>>
>> CONFIG_SMP=y
>> CONFIG_SMP_ON_UP=y
>> to
>> CONFIG_SMP=n
>> CONFIG_SMP_ON_UP=n
>> CONFIG_BROKEN_ON_SMP=y
>> the up-kernal start and latency start and do my program
>
>Turning off SMP improves latency, that is a general rule, for all
>processors. The problem is that if you do that you do not take advantage
>of all the cores your processor has. The question is: what latency did
>you have with the correct branch? If it is, say, less than 80us, it is a
>bit high but may still be normal. If it is 300us, then you may still
>have a problem, it depends on the answer you give to the questions I
>asked about your usage of rt_pipes.
>
>To be sure that you are running the kernel I expect, could you show us
>the boot logs?
>
>Regards.
>
>--
> Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??2.png
Type: image/png
Size: 224790 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140328/ba1ca153/attachment.png>
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-28 8:19 ` 嵌入式工程师
@ 2014-03-28 17:37 ` Gilles Chanteperdrix
0 siblings, 0 replies; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-28 17:37 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 03/28/2014 09:19 AM, 嵌入式工程师 wrote:
> THis is my newtest on my imx6q board with ipipe-3.0-imx6q
Note that the latency test only really make sense if no other real-time
activity is running on the board. Otherwise you are not really measuring
the system worst case latency.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-27 12:27 ` Gilles Chanteperdrix
2014-03-28 5:02 ` 嵌入式工程师
2014-03-28 8:19 ` 嵌入式工程师
@ 2014-03-28 9:08 ` 嵌入式工程师
2014-03-28 17:38 ` Gilles Chanteperdrix
2 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-28 9:08 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
sorry , I thought of a problem on the cpu0 binding a rt_pipe used to write and on the cpu1 binding another rt_pipe used to read ,if it can cause realtime lost?
THis is my newtest on my imx6q board with ipipe-3.0-imx6q
my boot logs
WARNING! The remote SSH server rejected X11 forwarding request.
-sh-2.05b# dmesg
Linux version 3.0.43 (lucid@ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #10 SMP PREEMPT Fri Mar 28 00:58:23 PDT 2014
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX 6Quad/DualLite/Solo LYNUC EVB Board
======================fire lynuc evb ========================
======================######################## ========================
Ignoring unrecognised tag 0x54410008
Memory policy: ECC disabled, Data cache writealloc
CPU identified as i.MX6Q, silicon rev 1.2
On node 0 totalpages: 229376
free_area_init_node: node 0, pgdat 806e0f80, node_mem_map 8b800000
DMA zone: 368 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 46736 pages, LIFO batch:15
Normal zone: 1680 pages used for memmap
Normal zone: 180592 pages, LIFO batch:31
PERCPU: Embedded 9 pages/cpu @8c008000 s14464 r8192 d14208 u36864
pcpu-alloc: s14464 r8192 d14208 u36864 alloc=9*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 227328
Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk0p1 rootwait
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 640MB 256MB = 896MB total
Memory: 900976k/900976k available, 147600k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xf4600000 - 0xffe00000 ( 184 MB)
vmalloc : 0xc0800000 - 0xf2000000 ( 792 MB)
lowmem : 0x80000000 - 0xc0000000 (1024 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.init : 0x80008000 - 0x80040000 ( 224 kB)
.text : 0x80040000 - 0x8069bec0 (6512 kB)
.data : 0x8069c000 - 0x806e2020 ( 281 kB)
.bss : 0x806e2044 - 0x80731c0c ( 319 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:496
MXC GPIO hardware
sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms
MXC_Early serial console at MMIO 0x2020000 (options '115200')
bootconsole [ttymxc0] enabled
I-pipe 1.18-13: pipeline enabled.
Console: colour dummy device 80x30
Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
I-pipe, 396.000 MHz timer
I-pipe, 396.000 MHz clocksource
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated (6324.22 BogoMIPS).
print_constraints: dummy:
NET: Registered protocol family 16
print_constraints: vddpu: 725 <--> 1300 mV at 700 mV fast normal
print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV fast normal
print_constraints: vddsoc: 725 <--> 1300 mV at 1200 mV fast normal
print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV fast normal
print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV fast normal
print_constraints: vdd3p0: 2800 <--> 3150 mV at 3000 mV fast normal
CLKCTL_CCGR6=c00
cscmr1=12700007
rate=52800000
Warning: emi_slow_clk not set to 132 MHz! WEIM NOR timing may be incorrect!
No AHCI save PWR: PDDQ enabled
hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.
hw-breakpoint: maximum watchpoint size is 4 bytes.
L310 cache controller enabled
l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02870000, Cache size: 1048576 B
IMX usb wakeup probe
the wakeup pdata is 0xbfe37500
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Freescale USB OTG Driver loaded, $Revision: 1.55 $
add wake up source irq 75
imx-ipuv3 imx-ipuv3.0: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)
imx-ipuv3 imx-ipuv3.1: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)
MIPI CSI2 driver module loaded
Advanced Linux Sound Architecture Driver Version 1.0.24.
Bluetooth: Core ver 2.16
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
cfg80211: Calling CRDA to update world regulatory domain
i2c-core: driver [max17135] using legacy suspend method
i2c-core: driver [max17135] using legacy resume method
Switching to clocksource ipipe_tsc
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Static Power Management for Freescale i.MX6
wait mode is disabled for i.MX6
cpaddr = c0880000 suspend_iram_base=c08ec000
PM driver module loaded
IMX usb wakeup probe
the wakeup pdata is 0xbfe8bb40
I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
JFFS2 version 2.2. (NAND) 漏 2001-2006 Red Hat, Inc.
msgmni has been set to 1759
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver ldb
mxc_sdc_fb mxc_sdc_fb.0: NO mxc display driver found!
mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver ldb
mxc_sdc_fb mxc_sdc_fb.1: NO mxc display driver found!
mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver lcd
imx-sdma imx-sdma: loaded firmware 1.1
imx-sdma imx-sdma: initialized
Serial: IMX driver
imx-uart.0: ttymxc0 at MMIO 0x2020000 (irq = 58) is a IMX
console [ttymxc0] enabled, bootconsole disabled
loop: module loaded
vcan: Virtual CAN interface driver
CAN device driver interface
flexcan netdevice driver
flexcan imx6q-flexcan.0: device registered (reg_base=c0938000, irq=142)
usbcore: registered new interface driver smsc95xx
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 75, io base 0x02184000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
add wake up source irq 72
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
fsl-ehci fsl-ehci.1: irq 72, io base 0x02184200
fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ARC USBOTG Device Controller driver (1 August 2005)
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC ee:3a:a3:34:e2:9f
usb0: HOST MAC 52:55:42:06:24:27
g_ether gadget: controller 'fsl-usb2-udc' not recognized; trying CDC Ethernet (EEM)
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
Suspend udc for OTG auto detect
USB Host suspend begins
will suspend roothub and its children
ehci_fsl_bus_suspend begins, DR
ehci_fsl_bus_suspend ends, DR
host suspend ends
USB Gadget resume begins
fsl_udc_resume, Wait for wakeup thread finishes
dr_controller_run: udc enter low power mode
USB Gadget resume ends
fsl-usb2-udc: bind to driver g_ether
mousedev: PS/2 mouse device common for all mice
input: gpio-keys as /devices/platform/gpio-keys/input/input0
i2c-core: driver [isl29023] using legacy suspend method
i2c-core: driver [isl29023] using legacy resume method
i2c /dev entries driver
imx2-wdt imx2-wdt.0: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=1)
Bluetooth: Virtual HCI driver ver 1.3
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCIATH3K protocol initialized
Bluetooth: Generic Bluetooth USB driver ver 0.6
usbcore: registered new interface driver btusb
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
mmc0: no vmmc regulator found
mmc0: SDHCI controller on platform [sdhci-esdhc-imx.2] using DMA
mmc1: no vmmc regulator found
mmc1: SDHCI controller on platform [sdhci-esdhc-imx.1] using DMA
mxc_asrc registered
Thermal calibration data is 0x5ec55d69
Anatop Thermal registered as thermal_zone0
anatop_thermal_probe: default cooling device is cpufreq!
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver snd-usb-audio
Cirrus Logic CS42888 ALSA SoC Codec Driver
i2c-core: driver [cs42888] using legacy suspend method
i2c-core: driver [cs42888] using legacy resume method
imx_3stack asoc driver
ALSA device list:
No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t)
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
lib80211: common routines for IEEE802.11 drivers
lib80211_crypt: registered algorithm 'NULL'
lib80211_crypt: registered algorithm 'WEP'
lib80211_crypt: registered algorithm 'CCMP'
lib80211_crypt: registered algorithm 'TKIP'
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
Bus freq driver module loaded
usb 2-1: new high speed USB device number 2 using fsl-ehci
Bus freq driver Enabled
mxc_dvfs_core_probe
DVFS driver module loaded
mmc0: new high speed DDR MMC card at address 0001
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Waiting for root device /dev/mmcblk0p1...
mmcblk0: mmc0:0001 SEM04G 3.68 GiB
mmcblk0boot0: mmc0:0001 SEM04G partition 1 1.00 MiB
mmcblk0boot1: mmc0:0001 SEM04G partition 2 1.00 MiB
mmcblk0: p1
mmcblk0boot1: unknown partition table
mmcblk0boot0: unknown partition table
EXT3-fs: barriers not enabled
smsc95xx v1.0.4
smsc95xx 2-1:1.0: eth0: register 'smsc95xx' at usb-fsl-ehci.1-1, smsc95xx USB 2.0 Ethernet, 00:80:0f:9e:04:23
在 2014-03-27 20:27:15，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/27/2014 06:24 AM, 嵌入式工程师 wrote:
>> I do as you said ,the result is the matter still has ,but when i change
>>
>> UIMAGE arch/arm/boot/uImage
>> Image Name: Linux-3.0.43-ge13355f
>> Created: Thu Mar 27 11:07:59 2014
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 3448764 Bytes = 3367.93 kB = 3.29 MB
>> Load Address: 10008000
>> Entry Point: 10008000
>> Image arch/arm/boot/uImage is ready
>>
>>
>> CONFIG_SMP=y
>> CONFIG_SMP_ON_UP=y
>> to
>> CONFIG_SMP=n
>> CONFIG_SMP_ON_UP=n
>> CONFIG_BROKEN_ON_SMP=y
>> the up-kernal start and latency start and do my program
>
>Turning off SMP improves latency, that is a general rule, for all
>processors. The problem is that if you do that you do not take advantage
>of all the cores your processor has. The question is: what latency did
>you have with the correct branch? If it is, say, less than 80us, it is a
>bit high but may still be normal. If it is 300us, then you may still
>have a problem, it depends on the answer you give to the questions I
>asked about your usage of rt_pipes.
>
>To be sure that you are running the kernel I expect, could you show us
>the boot logs?
>
>Regards.
>
>--
> Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??2.png
Type: image/png
Size: 224790 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140328/4c793e0d/attachment.png>
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-28 9:08 ` 嵌入式工程师
@ 2014-03-28 17:38 ` Gilles Chanteperdrix
2014-03-29 6:21 ` 嵌入式工程师
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-28 17:38 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 03/28/2014 10:08 AM, 嵌入式工程师 wrote:
>
> sorry , I thought of a problemon the cpu0 binding a rt_pipe used to
> write and on the cpu1 binding another rt_pipe used to read ,if it can
> cause realtime lost?
No, but I asked you some questions about your usage of rt_pipe to which
I would appreciate you give an answer.
Also, please do not use top-posting.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-03-28 17:38 ` Gilles Chanteperdrix
@ 2014-03-29 6:21 ` 嵌入式工程师
2014-03-29 13:51 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-03-29 6:21 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
I just know my colleagues use rt_pipe to Interactive data，and on different cpu will cause realtime lost ,we are trying to find the main position cause the real time lost .I will ask him the usage about rt_pipe,than you very much!!!
在 2014-03-29 01:38:58，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 03/28/2014 10:08 AM, 嵌入式工程师 wrote:
>>
>> sorry , I thought of a problemon the cpu0 binding a rt_pipe used to
>> write and on the cpu1 binding another rt_pipe used to read ,if it can
>> cause realtime lost?
>
>No, but I asked you some questions about your usage of rt_pipe to which
>I would appreciate you give an answer.
>
>Also, please do not use top-posting.
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Xenomai] imx6q xenomai ipipe-3.0-imx6q
@ 2014-04-01 2:35 嵌入式工程师
2014-04-01 10:49 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-04-01 2:35 UTC (permalink / raw)
To: Gilles Chanteperdrix, xenomai
Hello Gilles ，this is my test about xenomai ，this can also effect the my program and the latency test
，thanks 。
== Sampling period: 1000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT| 00:00:01 (in-kernel periodic task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.452| 17.221| 16637.492| 16| 0| 0.452| 16637.492
RTD| 0.431| 17.253| 16641.974| 32| 0| 0.431| 16641.974
RTD| 0.459| 17.233| 16639.224| 48| 0| 0.431| 16641.974
RTD| 0.439| 17.231| 16638.423| 64| 0| 0.431| 16641.974
RTD| 0.454| 17.232| 16638.489| 80| 0| 0.431| 16641.974
RTD| 0.453| 17.223| 16638.569| 96| 0| 0.431| 16641.974
RTD| 0.440| 17.227| 16638.612| 112| 0| 0.431| 16641.974
RTD| 0.458| 17.224| 16637.822| 128| 0| 0.431| 16641.974
RTD| 0.407| 17.269| 16639.417| 144| 0| 0.407| 16641.974
RTD| 0.432| 17.237| 16638.607| 160| 0| 0.407| 16641.974
RTD| 0.442| 17.278| 16638.695| 176| 0| 0.407| 16641.974
RTD| 0.437| 17.226| 16639.202| 192| 0| 0.407| 16641.974
RTD| 0.427| 17.232| 16637.467| 208| 0| 0.407| 16641.974
RTD| 0.454| 17.280| 16638.828| 224| 0| 0.407| 16641.974
RTD| 0.421| 17.241| 16637.866| 240| 0| 0.407| 16641.974
RTD| 0.398| 17.236| 16639.530| 256| 0| 0.398| 16641.974
RTD| 0.431| 17.252| 16637.032| 272| 0| 0.398| 16641.974
RTD| 0.446| 17.256| 16638.845| 288| 0| 0.398| 16641.974
RTD| 0.446| 17.253| 16638.981| 304| 0| 0.398| 16641.974
RTD| 0.433| 17.243| 16637.329| 320| 0| 0.398| 16641.974
^C---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 0.398| 17.242| 16641.974| 320| 0| 00:00:21/00:00:21
-sh-2.05b#
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/mman.h>
#include <native/task.h>
#include <native/timer.h>
RT_TASK demo_task;
/* NOTE: error handling omitted. */
void demo(void *arg)
{
RTIME now, previous;
/*
* Arguments: &task (NULL=self),
* start time,
* period (here: 1 s)
*/
rt_task_set_periodic(NULL, TM_NOW, 1000000000);
previous = rt_timer_read();
long long i,j,k;
while (1) {
rt_task_wait_period(NULL);
now = rt_timer_read();
for(i=1;i<1000;i++)
for(j=1;j<i;j++)
k=i*j;
/*
* NOTE: printf may have unexpected impact on the timing of
* your program. It is used here in the critical loop
* only for demonstration purposes.
*/
printf("Time since last turn: %ld.%06ld ms\n",
(long)(now - previous) / 1000000,
(long)(now - previous) % 1000000);
previous = now;
}
}
void catch_signal(int sig)
{
}
int main(int argc, char* argv[])
{
signal(SIGTERM, catch_signal);
signal(SIGINT, catch_signal);
/* Avoids memory swapping for this program */
mlockall(MCL_CURRENT|MCL_FUTURE);
/*
* Arguments: &task,
* name,
* stack size (0=default),
* priority,
* mode (FPU, start suspended, ...)
*/
rt_task_create(&demo_task, "trivial", 0, 99, 0);
/*
* Arguments: &task,
* task function,
* function argument
*/
rt_task_start(&demo_task, &demo, NULL);
pause();
rt_task_delete(&demo_task);
}
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-01 2:35 嵌入式工程师
@ 2014-04-01 10:49 ` Gilles Chanteperdrix
2014-04-02 0:53 ` 嵌入式工程师
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-01 10:49 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 04/01/2014 04:35 AM, 嵌入式工程师 wrote:
> Hello Gilles ，this is my test about xenomai ，this can also effect the
> my program and the latency test
> ，thanks 。
For the third time: running the latency test while other real-time
activity is running gives meaningless results. Here, the following piece
of code:
> for(i=1;i<1000;i++)
> for(j=1;j<i;j++)
> k=i*j;
Takes 1.6ms to execute, this is what the latency test measures.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-01 10:49 ` Gilles Chanteperdrix
@ 2014-04-02 0:53 ` 嵌入式工程师
2014-04-02 7:28 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-04-02 0:53 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
I know latency test can not run with e other real-time activity, but my program will run some real-time activties at the same time ,now it looks like because multiple cpu shared memory causes a great difference jitter .
在 2014-04-01 18:49:17，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 04/01/2014 04:35 AM, 嵌入式工程师 wrote:
>> Hello Gilles ，this is my test about xenomai ，this can also effect the
>> my program and the latency test
>> ，thanks 。
>
>For the third time: running the latency test while other real-time
>activity is running gives meaningless results. Here, the following piece
>of code:
>> for(i=1;i<1000;i++)
>> for(j=1;j<i;j++)
>> k=i*j;
>
>Takes 1.6ms to execute, this is what the latency test measures.
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-02 0:53 ` 嵌入式工程师
@ 2014-04-02 7:28 ` Gilles Chanteperdrix
2014-04-03 10:25 ` 嵌入式工程师
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-02 7:28 UTC (permalink / raw)
To: 嵌入式工程师; +Cc: xenomai
On 04/02/2014 02:53 AM, 嵌入式工程师 wrote:
> I know latency test can not run with e other real-time activity, but
> my program will run some real-time activties at the same time ,now it
> looks like because multiple cpu shared memory causes a great
> difference jitter .
That is not your problem. Your problem is that if you run a task with
priority 99 on the same cpu as the latency test, the time this task
prevents the latency test from running is counted by the latency test as
latency, which gives wrong results. This is not latency, this is simply
the scheduler doing its job: letting a task running until it suspends
before letting the latency task running. That is because the two tasks
have the same priority.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-02 7:28 ` Gilles Chanteperdrix
@ 2014-04-03 10:25 ` 嵌入式工程师
0 siblings, 0 replies; 35+ messages in thread
From: 嵌入式工程师 @ 2014-04-03 10:25 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
oh ，thanks
在 2014-04-02 15:28:10，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>On 04/02/2014 02:53 AM, 嵌入式工程师 wrote:
>> I know latency test can not run with e other real-time activity, but
>> my program will run some real-time activties at the same time ,now it
>> looks like because multiple cpu shared memory causes a great
>> difference jitter .
>
>That is not your problem. Your problem is that if you run a task with
>priority 99 on the same cpu as the latency test, the time this task
>prevents the latency test from running is counted by the latency test as
>latency, which gives wrong results. This is not latency, this is simply
>the scheduler doing its job: letting a task running until it suspends
>before letting the latency task running. That is because the two tasks
>have the same priority.
>
>--
> Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Xenomai] imx6q xenomai ipipe-3.0-imx6q
@ 2014-04-17 7:43 嵌入式工程师
2014-04-17 11:42 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-04-17 7:43 UTC (permalink / raw)
To: Gilles Chanteperdrix, xenomai, liu.h.f, huang.c.h
I use the ipipe-3.0-imx6q and xenomai-2.6.3 ,my board is imx6q 800MHz . And I analog my actual application. when I use share memery in different rt_tasks and bind with different cpus . The latency in 1000us at beginning it is about 14us but when i run more tasks it will reach 150us or higher .My tasks run more contents than the blow examples . I do not know if some thing wrong with my task.
result:
1task: 0.000421 ms
pmax: 0.014372 ms
1task: 0.057951 ms
1max: 0.153273 ms
the example test. Thank you very much
#include <linux/module.h>
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/cdev.h>
#include <linux/ioctl.h>
#include <linux/gpio.h>
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/uaccess.h>
#include <linux/slab.h>
#include <asm/io.h>
#include <linux/sched.h>
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <nucleus/module.h>
#include <linux/string.h>
#include <native/timer.h>
#include <native/alarm.h>
#include <native/task.h>
#include <native/sem.h>
#include <native/intr.h>
#include <native/heap.h>
#include <native/pipe.h>
#define TASK_PRIO 99 /* Highest RT priority */
#define TASK_MODE 0 /* No flags */
#define TASK_STKSZ 0 /* Stack size (use default one) */
RTIME now, previous;
RTIME pnow, pprevious;
RT_TASK t1,t2,t3;
RT_SEM semt1,semt2,semt3;
RT_HEAP heap_desc;
long * mem_spvm;
void *block;
MODULE_LICENSE("GPL");
static unsigned char logo[6957]={0};
long long tmp=0;
void taskOne(void*arg)
{
rt_task_set_periodic(NULL,TM_NOW,1000000);//1000us
long i;
long max,pmax;
int j;
previous = rt_timer_read();
pprevious=rt_timer_read();
while(1)
{
rt_sem_v(&semt2);
pnow = rt_timer_read();
if(pmax<(long)(pnow - pprevious-tmp))
pmax=(long)(pnow - pprevious-tmp);
if(j<10000)
pmax=0;
if(i%20000==0){
printk("1task: %d.%06d ms\n",
(int)(pnow - pprevious-tmp) / 1000000,
(int)(pnow - previous-tmp) % 1000000);
printk("pmax: %ld.%06ld ms\n",(long)pmax/1000000,(long)pmax%1000000);// first I read a max delay it is littile aboot 10us
}
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
now = rt_timer_read();
if(max<(long)(now - previous-tmp))
max=(long)(now - previous-tmp);
if(j++<10000)
max=0;
if(i++%20000==0){
printk("1task: %d.%06d ms\n",
(int)(now - previous-tmp) / 1000000,
(int)(now - previous-tmp) % 1000000);
printk("1max: %ld.%06ld ms\n",(long)max/1000000,(long)max%1000000);//the max delay about 154 us
printk("spvm6: %d \n",(char)mem_spvm[6]);
printk("spvm1: %d ",(char)mem_spvm[sizeof(logo)]);
}
tmp=tmp+1000000;
rt_task_wait_period(NULL);
}
}
void taskTwo(void*arg)
{
int i=0;
long max=0;
while(1)
{
rt_sem_p(&semt2,TM_INFINITE);
now = rt_timer_read();
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
if(i++%20000==0){
printk("2spvm6: %d \n",(char)mem_spvm[6]);
printk("2spvm1: %d\n",(char)mem_spvm[sizeof(logo)]);
}
rt_sem_v(&semt3);
}
}
void taskThree(void*arg)
{
int i;
while(1)
{
rt_sem_p(&semt3,TM_INFINITE);
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
if(i++%20000==0){
printk("3spvm6: %d \n",(char)mem_spvm[6]);
printk("3spvm1: %d\n",(char)mem_spvm[sizeof(logo)]);
}
}
}
#define HEAP_SIZE (15*1024*1024)
#define HEAP_MODE 0 /* Local heap. */
static int __init rtex_init(void){
int ret,err;
err =rt_heap_create(&heap_desc,"MyHeapName1",HEAP_SIZE,HEAP_MODE);
if (err)
printk("rt_heap_create wrong\n");
err = rt_heap_alloc(&heap_desc,1024*1024,TM_INFINITE,&block);
if (err)
printk("rt_heap_alloc wrong\n");
mem_spvm=(long*)block;
if(mem_spvm == NULL )
printk("mem_spvm failed!\n");
else
printk("mem_spvm successfully! \naddr = 0x%lx\n",(unsigned long)mem_spvm);
rt_sem_create(&semt1,"",0,S_FIFO);
rt_sem_create(&semt2,"",0,S_FIFO);
rt_sem_create(&semt3,"",0,S_FIFO);
if(!rt_task_create(&t1, "task1", 4096, 99, T_FPU|T_CPU(0)))
rt_task_start(&t1, taskOne, NULL);
if(!rt_task_create(&t2, "task2", 4096, 85, T_FPU|T_CPU(1)))
rt_task_start(&t2, taskTwo, NULL);
if(!rt_task_create(&t3, "task3", 4096, 80, T_FPU|T_CPU(2)))
rt_task_start(&t3,taskThree, NULL);
return ret;
}
static void __exit rtex_exit(void)
{
rt_heap_free(&heap_desc,block);
rt_heap_delete(&heap_desc);
rt_task_delete(&t1);
rt_task_delete(&t2);
rt_task_delete(&t3);
printk("rtex_exit \n");
}
module_init(rtex_init);
module_exit(rtex_exit);
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-17 7:43 嵌入式工程师
@ 2014-04-17 11:42 ` Gilles Chanteperdrix
0 siblings, 0 replies; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-17 11:42 UTC (permalink / raw)
To: 嵌入式工程师
Cc: huang.c.h, liu.h.f, xenomai
On 04/17/2014 09:43 AM, 嵌入式工程师 wrote:
> I use the ipipe-3.0-imx6q and xenomai-2.6.3 ,my board is imx6q 800MHz . And I analog my actual application. when I use share memery in different rt_tasks and bind with different cpus . The latency in 1000us at beginning it is about 14us but when i run more tasks it will reach 150us or higher .My tasks run more contents than the blow examples . I do not know if some thing wrong with my task.
>
>
> result:
> 1task: 0.000421 ms
> pmax: 0.014372 ms
> 1task: 0.057951 ms
> 1max: 0.153273 ms
>
>
> the example test. Thank you very much
Do you observe high latencies when running the latency test with no
other real-time activity but all the non real-time activity you want?
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Xenomai] imx6q xenomai ipipe-3.0-imx6q
@ 2014-04-17 7:58 嵌入式工程师
0 siblings, 0 replies; 35+ messages in thread
From: 嵌入式工程师 @ 2014-04-17 7:58 UTC (permalink / raw)
To: Gilles Chanteperdrix, xenomai, liu.h.f, huang.c.h
I use the ipipe-3.0-imx6q and xenomai-2.6.3 ,my board is imx6q 800MHz . And I analog my actual application. when I use share memery in different rt_tasks and bind with different cpus . The latency in 1000us at beginning it is about 14us but when i run more tasks it will reach 150us or higher .My tasks run more contents than the blow examples . I do not know if some thing wrong with my task. And if copy some large file about 30M to /tmp the latency will more higher . cp larg.tar.bz2 /tmp (/tmp is memery directory )
result:
1task: 0.000421 ms
pmax: 0.014372 ms
1task: 0.057951 ms
1max: 0.153273 ms
the example test. Thank you very much
#include <linux/module.h>
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/cdev.h>
#include <linux/ioctl.h>
#include <linux/gpio.h>
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/uaccess.h>
#include <linux/slab.h>
#include <asm/io.h>
#include <linux/sched.h>
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <nucleus/module.h>
#include <linux/string.h>
#include <native/timer.h>
#include <native/alarm.h>
#include <native/task.h>
#include <native/sem.h>
#include <native/intr.h>
#include <native/heap.h>
#include <native/pipe.h>
#define TASK_PRIO 99 /* Highest RT priority */
#define TASK_MODE 0 /* No flags */
#define TASK_STKSZ 0 /* Stack size (use default one) */
RTIME now, previous;
RTIME pnow, pprevious;
RT_TASK t1,t2,t3;
RT_SEM semt1,semt2,semt3;
RT_HEAP heap_desc;
long * mem_spvm;
void *block;
MODULE_LICENSE("GPL");
static unsigned char logo[6957]={0};
long long tmp=0;
void taskOne(void*arg)
{
rt_task_set_periodic(NULL,TM_NOW,1000000);//1000us
long i;
long max,pmax;
int j;
previous = rt_timer_read();
pprevious=rt_timer_read();
while(1)
{
rt_sem_v(&semt2);
pnow = rt_timer_read();
if(pmax<(long)(pnow - pprevious-tmp))
pmax=(long)(pnow - pprevious-tmp);
if(j<10000)
pmax=0;
if(i%20000==0){
printk("1task: %d.%06d ms\n",
(int)(pnow - pprevious-tmp) / 1000000,
(int)(pnow - previous-tmp) % 1000000);
printk("pmax: %ld.%06ld ms\n",(long)pmax/1000000,(long)pmax%1000000);// first I read a max delay it is littile aboot 10us
}
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
now = rt_timer_read();
if(max<(long)(now - previous-tmp))
max=(long)(now - previous-tmp);
if(j++<10000)
max=0;
if(i++%20000==0){
printk("1task: %d.%06d ms\n",
(int)(now - previous-tmp) / 1000000,
(int)(now - previous-tmp) % 1000000);
printk("1max: %ld.%06ld ms\n",(long)max/1000000,(long)max%1000000);//the max delay about 154 us
printk("spvm6: %d \n",(char)mem_spvm[6]);
printk("spvm1: %d ",(char)mem_spvm[sizeof(logo)]);
}
tmp=tmp+1000000;
rt_task_wait_period(NULL);
}
}
void taskTwo(void*arg)
{
int i=0;
long max=0;
while(1)
{
rt_sem_p(&semt2,TM_INFINITE);
now = rt_timer_read();
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
if(i++%20000==0){
printk("2spvm6: %d \n",(char)mem_spvm[6]);
printk("2spvm1: %d\n",(char)mem_spvm[sizeof(logo)]);
}
rt_sem_v(&semt3);
}
}
void taskThree(void*arg)
{
int i;
while(1)
{
rt_sem_p(&semt3,TM_INFINITE);
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
if(i++%20000==0){
printk("3spvm6: %d \n",(char)mem_spvm[6]);
printk("3spvm1: %d\n",(char)mem_spvm[sizeof(logo)]);
}
}
}
#define HEAP_SIZE (15*1024*1024)
#define HEAP_MODE 0 /* Local heap. */
static int __init rtex_init(void){
int ret,err;
err =rt_heap_create(&heap_desc,"MyHeapName1",HEAP_SIZE,HEAP_MODE);
if (err)
printk("rt_heap_create wrong\n");
err = rt_heap_alloc(&heap_desc,1024*1024,TM_INFINITE,&block);
if (err)
printk("rt_heap_alloc wrong\n");
mem_spvm=(long*)block;
if(mem_spvm == NULL )
printk("mem_spvm failed!\n");
else
printk("mem_spvm successfully! \naddr = 0x%lx\n",(unsigned long)mem_spvm);
rt_sem_create(&semt1,"",0,S_FIFO);
rt_sem_create(&semt2,"",0,S_FIFO);
rt_sem_create(&semt3,"",0,S_FIFO);
if(!rt_task_create(&t1, "task1", 4096, 99, T_FPU|T_CPU(0)))
rt_task_start(&t1, taskOne, NULL);
if(!rt_task_create(&t2, "task2", 4096, 85, T_FPU|T_CPU(1)))
rt_task_start(&t2, taskTwo, NULL);
if(!rt_task_create(&t3, "task3", 4096, 80, T_FPU|T_CPU(2)))
rt_task_start(&t3,taskThree, NULL);
return ret;
}
static void __exit rtex_exit(void)
{
rt_heap_free(&heap_desc,block);
rt_heap_delete(&heap_desc);
rt_task_delete(&t1);
rt_task_delete(&t2);
rt_task_delete(&t3);
printk("rtex_exit \n");
}
module_init(rtex_init);
module_exit(rtex_exit);
^ permalink raw reply [flat|nested] 35+ messages in thread* [Xenomai] imx6q xenomai ipipe-3.0-imx6q
@ 2014-04-17 8:13 嵌入式工程师
0 siblings, 0 replies; 35+ messages in thread
From: 嵌入式工程师 @ 2014-04-17 8:13 UTC (permalink / raw)
To: Gilles Chanteperdrix, xenomai, liu.h.f, huang.c.h
I mean, when I run the more user-level program on memory operations，the latency from 154us to 391us
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Xenomai] imx6q xenomai ipipe-3.0-imx6q
@ 2014-04-18 10:28 嵌入式工程师
2014-04-18 11:47 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: 嵌入式工程师 @ 2014-04-18 10:28 UTC (permalink / raw)
To: Gilles Chanteperdrix, xenomai, liu.h.f, huang.c.h
I do the same on the imx53 with imx6 test, in the process of real-time task to run the same operation content, start the qt deform demo and copy large file to memory, in 250 us the latency on imx6 board began to accumulate, lost real-time, but latency on the imx53 only value within 20 us. I do not run anyother rt task on my below test：
#include <linux/module.h>
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/cdev.h>
#include <linux/ioctl.h>
#include <linux/gpio.h>
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/uaccess.h>
#include <linux/slab.h>
#include <asm/io.h>
#include <linux/sched.h>
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <nucleus/module.h>
#include <linux/string.h>
#include <native/timer.h>
#include <native/alarm.h>
#include <native/task.h>
#include <native/sem.h>
#include <native/intr.h>
#include <native/heap.h>
#include <rtdm/rtdm_driver.h>
#include <native/pipe.h>
#include <linux/spinlock.h>
#include <linux/io.h>
#include <linux/ipipe.h>
#include <nucleus/timer.h>
#define TASK_PRIO 99 /* Highest RT priority */
#define TASK_MODE 0 /* No flags */
#define TASK_STKSZ 0 /* Stack size (use default one) */
RTIME now, previous;
RTIME pnow, pprevious;
rtdm_task_t t1,t2,t3;
//RT_SEM semt1,semt2,semt3,irq_sem;
rtdm_sem_t semt1,semt2,semt3;
RT_HEAP heap_desc;
long * mem_spvm;
void *block;
//static xntimer_t rtimer;
static rtdm_timer_t rtimer;
static IPIPE_DEFINE_SPINLOCK(mem_lock);
#define CAT_IRQ IMX_GPIO_NR(5, 0)
MODULE_LICENSE("GPL");
int irq = -1;
#define HEARTBEAT_PERIOD250000 /* 100 ms */
static rtdm_task_t heartbeat_task,heartbeat_task1,heartbeat_task2;
static unsigned char logo[1024*10]={0};
long long tmp=0;
int irq_taskOne(int irq, void *device_id)
{
//rt_task_set_periodic(NULL,TM_NOW,250000);
//rt_sem_v(&irq_sem);
return RT_INTR_HANDLED;
}
long i;
long max,pmax;
int j;
void taskOne(void*arg)
{
previous = rt_timer_read();
pprevious=rt_timer_read();
while(1)
{
//rt_sem_p(&irq_sem,TM_INFINITE);
unsigned long flags;
pnow = rt_timer_read();
if(pmax<(long)(pnow - pprevious-tmp))
pmax=(long)(pnow - pprevious-tmp);
if(j<10000)
pmax=0;
if(i%20000==0){
rtdm_printk ("1task: %d.%06d ms\n",
(int)(pnow - pprevious-tmp) / 1000000,
(int)(pnow - previous-tmp) % 1000000);
rtdm_printk ("pmax: %ld.%06ld ms\n",(long)pmax/1000000,(long)pmax%1000000);
}
//spin_lock_irqsave(&mem_lock, flags);
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
/*memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));*/
//spin_unlock_irqrestore(&mem_lock, flags);
now = rt_timer_read();
if(max<(long)(now - previous-tmp))
max=(long)(now - previous-tmp);
if(j++<10000)
max=0;
if(i++%20000==0){
printk("1task: %d.%06d ms\n",
(int)(now - previous-tmp) / 1000000,
(int)(now - previous-tmp) % 1000000);
rtdm_printk ("1max: %ld.%06ld ms\n",(long)max/1000000,(long)max%1000000);
rtdm_printk ("spvm6: %d \n",(char)mem_spvm[6]);
rtdm_printk ("spvm1: %d ",(char)mem_spvm[sizeof(logo)]);
}
tmp=tmp+250000;
rtdm_sem_up(&semt1);
//rt_sem_v(&semt2);
//rt_task_wait_period(NULL);
rtdm_task_wait_period();
}
}
void taskTwo(void*arg)
{
int i=0;
long max=0;
while(1)
{
//rt_sem_p(&semt2,TM_INFINITE);
rtdm_sem_down(&semt1) ;
now = rt_timer_read();
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
if(i++%20000==0){
rtdm_printk ("2spvm6: %d \n",(char)mem_spvm[6]);
rtdm_printk ("2spvm1: %d\n",(char)mem_spvm[sizeof(logo)]);
}
rtdm_sem_up(&semt2);
}
}
void taskThree(void*arg)
{
int i;
while(1)
{
rtdm_sem_down(&semt2) ;
memset(mem_spvm,255,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
if(i++%20000==0){
rtdm_printk ("3spvm6: %d \n",(char)mem_spvm[6]);
rtdm_printk ("3spvm1: %d\n",(char)mem_spvm[sizeof(logo)]);
}
}
}
#define HEAP_SIZE (15*1024*1024)
#define HEAP_MODE 0 /* Local heap. */
RT_INTR intr_desc;
static int periode_us = 1000;
static int __init rtex_init(void){
int ret,err;
/*err = gpio_request(CAT_IRQ,NULL);
if(err < 0){
printk("gpio_request failure !\n");
return err;
}
err = gpio_direction_input(CAT_IRQ);
if(err < 0){
printk("gpio_direction_input failure !\n");
return err;
}
irq = gpio_to_irq(CAT_IRQ);
irq_set_irq_type(irq,IRQ_TYPE_EDGE_RISING);
err = rt_intr_create(&intr_desc,"MyIrq",irq,irq_taskOne,NULL,I_SHARED|I_EDGE);
if(err){
printk("rt_intr_create failure !\n");
return err;
}
printk("rt_intr_create irq=%d\n",irq);
rt_intr_enable(&intr_desc);
printk("I have enable the irq\n");*/
/*err =rt_heap_create(&heap_desc,"MyHeapName1",HEAP_SIZE,HEAP_MODE);
if (err)
printk("rt_heap_create wrong\n");
err = rt_heap_alloc(&heap_desc,1024*1024,TM_INFINITE,&block);
if (err)
printk("rt_heap_alloc wrong\n");*/
block=(long*)rtdm_malloc(1024*11);
mem_spvm=(long*)block;
if(mem_spvm == NULL )
printk("mem_spvm failed!\n");
else
printk("mem_spvm successfully! \naddr = 0x%lx\n",(unsigned long)mem_spvm);
/*rt_sem_create(&semt1,"",0,S_FIFO);
rt_sem_create(&semt2,"",0,S_FIFO);
rt_sem_create(&semt3,"",0,S_FIFO);
rt_sem_create(&irq_sem,"",0,S_FIFO);*/
rtdm_sem_init(&semt1,0) ;
rtdm_sem_init(&semt2,0) ;
rtdm_sem_init(&semt3,0) ;
/*if(!rt_task_create(&t1, "task1", 4096, 99, T_FPU|T_CPU(0)))
rt_task_start(&t1, taskOne, NULL);*/
/*if(!rt_task_create(&t2, "task2", 4096, 85, T_FPU|T_CPU(1)))
rt_task_start(&t2, taskTwo, NULL);
if(!rt_task_create(&t3, "task3", 4096, 80, T_FPU|T_CPU(2)))
rt_task_start(&t3,taskThree, NULL);*/
printk("mem_spv ! \naddr = 0x%lx\n",(unsigned long)mem_spvm);
rtdm_task_init(&heartbeat_task, "heartbeat", taskOne, NULL,
99, HEARTBEAT_PERIOD);
rtdm_task_set_period(&heartbeat_task,250000) ;
rtdm_task_set_priority(&heartbeat_task,99);
rtdm_task_unblock(&heartbeat_task);
printk("mem_spvm successfully! \naddr = 0x%lx\n",(unsigned long)mem_spvm);
rtdm_task_init(&heartbeat_task2, "heartbeat1", taskThree, NULL,
80, HEARTBEAT_PERIOD);
rtdm_task_init(&heartbeat_task1, "heartbeat1", taskTwo, NULL,
85, HEARTBEAT_PERIOD);
//xnticks_t now;
//now = xntbase_get_jiffies(&nktbase);
/*if ((err = rtdm_timer_init(& rtimer, taskOne, "Oscillateur")) != 0) {
return err;
}
if ((err = rtdm_timer_start(& rtimer, periode_us*250, periode_us*250, RTDM_TIMERMODE_RELATIVE)) != 0) {
rtdm_timer_destroy(& rtimer);
return err;
}*/
/*xntbase_enabled_p(&nktbase);
xntimer_init(&rtimer, &nktbase, taskOne);
xntimer_set_priority(&rtimer, XNTIMER_HIPRIO);
xntimer_start(&rtimer, 250000UL, 250000UL, XN_RELATIVE);*/
return ret;
}
static void __exit rtex_exit(void)
{
//rt_heap_free(&heap_desc,block);
//rt_heap_delete(&heap_desc);
rtdm_free(block);
rtdm_task_join_nrt(&heartbeat_task, 100);
//rt_task_delete(&t1);
rt_task_delete(&t2);
rt_task_delete(&t3);
printk("rtex_exit \n");
}
module_init(rtex_init);
module_exit(rtex_exit);
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-18 10:28 嵌入式工程师
@ 2014-04-18 11:47 ` Gilles Chanteperdrix
2014-04-20 5:06 ` eric
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-18 11:47 UTC (permalink / raw)
To: 嵌入式工程师
Cc: huang.c.h, liu.h.f, xenomai
On 04/18/2014 12:28 PM, 嵌入式工程师 wrote:
>
>
> I do the same on the imx53 with imx6 test, in the process of
> real-time task to run the same operation content, start the qt deform
> demo and copy large file to memory, in 250 us the latency on imx6
> board began to accumulate, lost real-time, but latency on the imx53
> only value within 20 us. I do not run anyother rt task on my below
> test：
Looking at your code, it seems your problem (if I understand correctly),
is that a series of memcpy and memset takes a long time to execute when
non real-time activities are given an opportunity to thrash the cache.
Am I understanding correctly?
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-18 11:47 ` Gilles Chanteperdrix
@ 2014-04-20 5:06 ` eric
2014-04-20 9:03 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: eric @ 2014-04-20 5:06 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: huang.c.h, liu.h.f, xenomai
So if my program use lots of memory operations for a long time it maybe gives non real-time activities opportunity to thrash the cache?
--
发自我的网易邮箱平板适配版
<br/><br/><br/>
----- Original Message -----
From: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
To: "嵌入式工程师" <ericvic@163.com>
Cc: "xenomai@xenomai.org" <xenomai@xenomai.org>, liu.h.f@lynuc.cn, huang.c.h@lynuc.cn
Sent: Fri, 18 Apr 2014 13:47:15 +0200
Subject: Re: imx6q xenomai ipipe-3.0-imx6q
On 04/18/2014 12:28 PM, 嵌入式工程师 wrote:
>
>
> I do the same on the imx53 with imx6 test, in the process of
> real-time task to run the same operation content, start the qt deform
> demo and copy large file to memory, in 250 us the latency on imx6
> board began to accumulate, lost real-time, but latency on the imx53
> only value within 20 us. I do not run anyother rt task on my below
> test：
Looking at your code, it seems your problem (if I understand correctly),
is that a series of memcpy and memset takes a long time to execute when
non real-time activities are given an opportunity to thrash the cache.
Am I understanding correctly?
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-20 5:06 ` eric
@ 2014-04-20 9:03 ` Gilles Chanteperdrix
2014-04-20 9:23 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-20 9:03 UTC (permalink / raw)
To: eric; +Cc: huang.c.h, liu.h.f, xenomai
Le 20/04/2014 07:06, eric a écrit :
> So if my program use lots of memory operations for a long time it maybe
> gives non real-time activities opportunity to thrash the cache?
It is unrelated, but on a multi-core processor even when one core is
running a real-time task, other cores can thrash the cache at will, or
slow down the real-time task by using a shared ressource (for instance
DDR) and starving the core where the real-time task runs. By default the
L2 cache is shared between all cores, you can try and reserve parts of
the cache for each core (check the l2x0 registers documentation to see
how), I tried this on omap4, but it results on worse latencies,
situation may be different on imx6 though. Another problem is that since
the L1 cache is per-core, I believe, and we disable L2 write allocate,
reading on one core memory written on another core results in accesses
at the DDR speed, and not at the cache speed.
All this to say that Xenomai focuses on trying to schedule your driver
interrupts and application threads in a deterministic fashion but it is
your job to make sure that these interrupts and threads do not take too
long a time to execute, because if they do, yes, your application will
not meet its deadlines, but it is not Xenomai's fault.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-20 9:03 ` Gilles Chanteperdrix
@ 2014-04-20 9:23 ` Gilles Chanteperdrix
2014-04-20 10:46 ` eric
0 siblings, 1 reply; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-20 9:23 UTC (permalink / raw)
To: eric; +Cc: huang.c.h, liu.h.f, xenomai
Le 20/04/2014 11:03, Gilles Chanteperdrix a écrit :
> Le 20/04/2014 07:06, eric a écrit :
>> So if my program use lots of memory operations for a long time it maybe
>> gives non real-time activities opportunity to thrash the cache?
>
> It is unrelated, but on a multi-core processor even when one core is
> running a real-time task, other cores can thrash the cache at will, or
> slow down the real-time task by using a shared ressource (for instance
> DDR) and starving the core where the real-time task runs. By default the
> L2 cache is shared between all cores, you can try and reserve parts of
> the cache for each core (check the l2x0 registers documentation to see
> how), I tried this on omap4, but it results on worse latencies,
> situation may be different on imx6 though. Another problem is that since
> the L1 cache is per-core, I believe, and we disable L2 write allocate,
> reading on one core memory written on another core results in accesses
> at the DDR speed, and not at the cache speed.
>
> All this to say that Xenomai focuses on trying to schedule your driver
> interrupts and application threads in a deterministic fashion but it is
> your job to make sure that these interrupts and threads do not take too
> long a time to execute, because if they do, yes, your application will
> not meet its deadlines, but it is not Xenomai's fault.
I do not mean to say that you do not have a problem with Xenomai on
imx6q, but so far, I have not understood what this problem was.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-20 9:23 ` Gilles Chanteperdrix
@ 2014-04-20 10:46 ` eric
2014-04-23 4:40 ` eric
0 siblings, 1 reply; 35+ messages in thread
From: eric @ 2014-04-20 10:46 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: huang.c.h, liu.h.f, xenomai
OK thank you for the information
在 2014-04-20 17:23:19，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
Le 20/04/2014 11:03, Gilles Chanteperdrix a écrit :
> Le 20/04/2014 07:06, eric a écrit :
>> So if my program use lots of memory operations for a long time it maybe
>> gives non real-time activities opportunity to thrash the cache?
>
> It is unrelated, but on a multi-core processor even when one core is
> running a real-time task, other cores can thrash the cache at will, or
> slow down the real-time task by using a shared ressource (for instance
> DDR) and starving the core where the real-time task runs. By default the
> L2 cache is shared between all cores, you can try and reserve parts of
> the cache for each core (check the l2x0 registers documentation to see
> how), I tried this on omap4, but it results on worse latencies,
> situation may be different on imx6 though. Another problem is that since
> the L1 cache is per-core, I believe, and we disable L2 write allocate,
> reading on one core memory written on another core results in accesses
> at the DDR speed, and not at the cache speed.
>
> All this to say that Xenomai focuses on trying to schedule your driver
> interrupts and application threads in a deterministic fashion but it is
> your job to make sure that these interrupts and threads do not take too
> long a time to execute, because if they do, yes, your application will
> not meet its deadlines, but it is not Xenomai's fault.
I do not mean to say that you do not have a problem with Xenomai on
imx6q, but so far, I have not understood what this problem was.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-20 10:46 ` eric
@ 2014-04-23 4:40 ` eric
2014-04-23 12:24 ` Gilles Chanteperdrix
0 siblings, 1 reply; 35+ messages in thread
From: eric @ 2014-04-23 4:40 UTC (permalink / raw)
To: eric; +Cc: huang.c.h, liu.h.f, xenomai
在 2014-04-20 18:46:21，eric <ericvic@163.com> 写道：
>在 2014-04-20 17:23:19，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>Le 20/04/2014 11:03, Gilles Chanteperdrix a écrit :
>> Le 20/04/2014 07:06, eric a écrit :
>>> So if my program use lots of memory operations for a long time it maybe
>>> gives non real-time activities opportunity to thrash the cache?
>>
>> It is unrelated, but on a multi-core processor even when one core is
>> running a real-time task, other cores can thrash the cache at will, or
>> slow down the real-time task by using a shared ressource (for instance
>> DDR) and starving the core where the real-time task runs. By default the
>> L2 cache is shared between all cores, you can try and reserve parts of
>> the cache for each core (check the l2x0 registers documentation to see
>> how), I tried this on omap4, but it results on worse latencies,
>> situation may be different on imx6 though. Another problem is that since
>> the L1 cache is per-core, I believe, and we disable L2 write allocate,
>> reading on one core memory written on another core results in accesses
>> at the DDR speed, and not at the cache speed.
>>
>> All this to say that Xenomai focuses on trying to schedule your driver
>> interrupts and application threads in a deterministic fashion but it is
>> your job to make sure that these interrupts and threads do not take too
>> long a time to execute, because if they do, yes, your application will
>> not meet its deadlines, but it is not Xenomai's fault.
>
>I do not mean to say that you do not have a problem with Xenomai on
>imx6q, but so far, I have not understood what this problem was.
>
>
>--
>Gilles.
Hello Gilles I found the same test on x86 double cores and enble smp with rtai will not have the max delay ,it is just 50us latencies ,this is my test with rtai , the multi-core processor with shared cache can be thrashed just appears on imx6 and omap4 or all arm with multi-core has the same problems? thank you
#include <linux/module.h>
#include <rtai.h>
#include <rtai_sched.h>
#include <asm/timex.h>
#define LPT1_BASE 0x378
#define STACK_SIZE 4096
#define TIMERTICKS 1000000
static RT_TASK tasks;
char logo[40*1024]={0};
char mem_spvm[40*1024];
RTIME previous,pprevious,now,pnow,pmax;
long long tmp=0;
long i=0;
unsigned long start,stop,task_max;
static void task(int t)
{
previous = rt_get_time_ns();
while(1){
rt_task_wait_period();
start=get_cycles();
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memset(mem_spvm,0,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
memset(mem_spvm,127,sizeof(logo));
memcpy(mem_spvm,logo,sizeof(logo));
pnow=rt_get_time_ns();
stop=get_cycles();
pmax=(pnow-previous);
pmax=pmax<0?-pmax:pmax;
if(task_max<(stop-start))
task_max=stop-start;
if(i++<10000)
task_max=0;
printk("otime: %ld.%06ld ms\n",(long)pmax/1000000,(long)pmax%1000000);//the max delay about 154 us
printk("stime: %ld.%06ld ms\n",(long)task_max/1000000,(long)task_max%1000000);//the max delay about 154 us
//previous=pnow;
previous=previous+1000000;
}
}
int init_module(void)
{
RTIME tick_period, now;
rt_set_periodic_mode();
rt_task_init(&task, task, 0, STACK_SIZE, 0, 0, 0);
tick_period = start_rt_timer(nano2count (TIMERTICKS));
now = rt_get_time();
rt_task_make_periodic(&tasks, now + tick_period, tick_period);
return 0;
}
void cleanup_module(void)
{
stop_rt_timer();
rt_busy_sleep(10000000);
rt_task_delete(&tasks[0]);
rt_task_delete(&tasks[1]);
}
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Xenomai] imx6q xenomai ipipe-3.0-imx6q
2014-04-23 4:40 ` eric
@ 2014-04-23 12:24 ` Gilles Chanteperdrix
0 siblings, 0 replies; 35+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-23 12:24 UTC (permalink / raw)
To: eric; +Cc: huang.c.h, liu.h.f, xenomai
On 04/23/2014 06:40 AM, eric wrote:
>
>
>
>
>
>
>
>
>
> 在 2014-04-20 18:46:21，eric <ericvic@163.com> 写道：
>
>> 在 2014-04-20 17:23:19，"Gilles Chanteperdrix"
>> <gilles.chanteperdrix@xenomai.org> 写道： Le 20/04/2014 11:03, Gilles
>> Chanteperdrix a écrit :
>>> Le 20/04/2014 07:06, eric a écrit :
>>>> So if my program use lots of memory operations for a long time
>>>> it maybe gives non real-time activities opportunity to thrash
>>>> the cache?
>>>
>>> It is unrelated, but on a multi-core processor even when one core
>>> is running a real-time task, other cores can thrash the cache at
>>> will, or slow down the real-time task by using a shared ressource
>>> (for instance DDR) and starving the core where the real-time task
>>> runs. By default the L2 cache is shared between all cores, you
>>> can try and reserve parts of the cache for each core (check the
>>> l2x0 registers documentation to see how), I tried this on omap4,
>>> but it results on worse latencies, situation may be different on
>>> imx6 though. Another problem is that since the L1 cache is
>>> per-core, I believe, and we disable L2 write allocate, reading on
>>> one core memory written on another core results in accesses at
>>> the DDR speed, and not at the cache speed.
>>>
>>> All this to say that Xenomai focuses on trying to schedule your
>>> driver interrupts and application threads in a deterministic
>>> fashion but it is your job to make sure that these interrupts and
>>> threads do not take too long a time to execute, because if they
>>> do, yes, your application will not meet its deadlines, but it is
>>> not Xenomai's fault.
>>
>> I do not mean to say that you do not have a problem with Xenomai
>> on imx6q, but so far, I have not understood what this problem was.
>>
>>
>> -- Gilles.
>
>
>
>
>
> Hello Gilles I found the same test on x86 double cores and enble smp
> with rtai will not have the max delay ,it is just 50us latencies
> ,this is my test with rtai , the multi-core processor with shared
> cache can be thrashed just appears on imx6 and omap4 or all arm with
> multi-core has the same problems? thank you
Yes, the behaviour of cache is highly dependent on the processor you are
using. Besides, disabling L2 write allocate may be bad for you use case,
you may want to re-enable it to see if it leads to better throughput in
your case.
--
Gilles.
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2014-04-23 12:24 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-26 11:36 [Xenomai] imx6q xenomai ipipe-3.0-imx6q 嵌入式工程师
2014-03-26 11:50 ` Gilles Chanteperdrix
2014-03-26 13:31 ` 嵌入式工程师
2014-03-26 13:34 ` Gilles Chanteperdrix
2014-03-26 14:29 ` 嵌入式工程师
2014-03-26 23:09 ` Gilles Chanteperdrix
2014-03-27 1:41 ` 嵌入式工程师
2014-03-27 5:24 ` 嵌入式工程师
2014-03-27 12:27 ` Gilles Chanteperdrix
2014-03-28 5:02 ` 嵌入式工程师
2014-03-28 17:35 ` Gilles Chanteperdrix
2014-03-29 5:54 ` 嵌入式工程师
2014-03-28 8:19 ` 嵌入式工程师
2014-03-28 17:37 ` Gilles Chanteperdrix
2014-03-28 9:08 ` 嵌入式工程师
2014-03-28 17:38 ` Gilles Chanteperdrix
2014-03-29 6:21 ` 嵌入式工程师
2014-03-29 13:51 ` Gilles Chanteperdrix
2014-04-01 2:35 嵌入式工程师
2014-04-01 10:49 ` Gilles Chanteperdrix
2014-04-02 0:53 ` 嵌入式工程师
2014-04-02 7:28 ` Gilles Chanteperdrix
2014-04-03 10:25 ` 嵌入式工程师
2014-04-17 7:43 嵌入式工程师
2014-04-17 11:42 ` Gilles Chanteperdrix
2014-04-17 7:58 嵌入式工程师
2014-04-17 8:13 嵌入式工程师
2014-04-18 10:28 嵌入式工程师
2014-04-18 11:47 ` Gilles Chanteperdrix
2014-04-20 5:06 ` eric
2014-04-20 9:03 ` Gilles Chanteperdrix
2014-04-20 9:23 ` Gilles Chanteperdrix
2014-04-20 10:46 ` eric
2014-04-23 4:40 ` eric
2014-04-23 12:24 ` Gilles Chanteperdrix
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.
