* Fwd: kernel 3.0.93 on s3c2410 problome.
From: Kernux Zhang @ 2013-08-30 1:13 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <CAB-=yQeb8FN++rp6qdNbb_Yhi3zx_9o1gwxvGCeM4AECO8MB+A@mail.gmail.com>
in the download source,I only run : make s3c2410_defconfig ; make
uImage. then get the uImage and I download it in my board to boot.and
I got the follows:
## Booting kernel from Legacy Image at 30800000 ...
Image Name: Linux-3.0.93
Created: 2013-08-29 5:03:32 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2298128 Bytes = 2.2 MiB
Load Address: 30108000
Entry Point: 30108000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 3.0.93 (root@localhost.localdomain) (gcc version 4.7.3
(Sourcery CodeBench Lite 2013.05-24) ) #8 Thu Aug 29 13:03:14 CST 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=00007177
CPU: VIVT data cache, VIVT instruction cache
Machine: SMDK2410
Memory policy: ECC disabled, Data cache writeback
CPU S3C2410A (id 0x32410002)
S3C24XX Clocks, Copyright 2004 Simtec Electronics
S3C2410: core 202.800 MHz, memory 101.400 MHz, peripheral 50.700 MHz
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: noinitrd root=/dev/mtdblock2 rw console=ttySAC0,115200
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60216k/60216k available, 5320k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
vmalloc : 0xc4800000 - 0xf6000000 ( 792 MB)
lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.init : 0xc0108000 - 0xc012f000 ( 156 kB)
.text : 0xc012f000 - 0xc0543000 (4176 kB)
.data : 0xc0544000 - 0xc05724a0 ( 186 kB)
.bss : 0xc05724c4 - 0xc059b1f8 ( 164 kB)
NR_IRQS:99
irq: clearing subpending status 00000002
Console: colour dummy device 80x30
console [ttySAC0] enabled
Calibrating delay loop... 50.17 BogoMIPS (lpj=125440)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Internal error: Oops - undefined instruction: 0 [#1]
Modules linked in:
CPU: 0 Not tainted (3.0.93 #8)
PC is at 0xc0545f28
LR is at alloc_inode+0x28/0xac
pc : [<c0545f28>] lr : [<c01ca9f4>] psr: 40000053
sp : c0545e88 ip : c0545ea0 fp : c0545e9c
r10: 000002fb r9 : 41129200 r8 : c0092540
r7 : c009312c r6 : c0545ea8 r5 : c0545ea8 r4 : 00000000
r3 : c0545ea8 r2 : c3801520 r1 : c009312c r0 : c0545ea8
Flags: nZcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment user
Control: 0000717f Table: 30104000 DAC: 00000015
Process swapper (pid: 0, stack limit = 0xc0544260)
Stack: (0xc0545e88 to 0xc0546000)
5e80: 00000000 c3801520 c0545ec4 c0545ea0 c01cafb4 c01ca9dc
5ea0: c3801520 c0545ea8 00400000 c0545ea8 c045d1a0 30127880 c0545ee4 c0545ec8
5ec0: c0203d84 c01caf38 c0545ed4 c04541a8 c3801520 c0545ea8 c0545f08 c0545ee8
5ee0: c02067d4 c0203d78 c04ee5f8 c38139e0 c0559ab0 c0559ab0 00000000 c0545f2c
5f00: c0545f0c c01b808c c02066ec 00000000 00400000 c04ee5f8 c38139e0 00400000
5f20: c0545f50 c0545f30 c01cdd54 c01b8080 00000000 00000000 c0586628 c0545f7c
5f40: 30104000 c0545f60 c0545f54 c01cddb0 c01cdd10 c0545f80 c0545f64 c0118fb8
5f60: c01cdda4 00000000 00000000 c0546258 c054622c c0545fa4 c0545f84 c0118134
5f80: c0118f64 00000000 c0117ae4 c01b67d0 00000000 00003ab2 c0545fd0 c0545fa8
5fa0: c0117d5c c01180b4 00000000 c0545fd0 c0545fbc c0118278 c05460e0 c012975c
5fc0: c0080280 c0545ff4 c0545fd4 c0108908 c0117ccc c0108350 c012975c 00007175
5fe0: c0546068 c0129758 00000000 c0545ff8 3010803c c01086c0 00000000 00000000
Backtrace:
[<c01ca9cc>] (alloc_inode+0x0/0xac) from [<c01cafb4>] (iget_locked+0x8c/0x138)
r5:c3801520 r4:00000000
[<c01caf28>] (iget_locked+0x0/0x138) from [<c0203d84>]
(sysfs_get_inode+0x1c/0x1a8)
[<c0203d68>] (sysfs_get_inode+0x0/0x1a8) from [<c02067d4>]
(sysfs_mount+0xf8/0x178)
r5:c0545ea8 r4:c3801520
[<c02066dc>] (sysfs_mount+0x0/0x178) from [<c01b808c>] (mount_fs+0x1c/0xe0)
r8:00000000 r7:c0559ab0 r6:c0559ab0 r5:c38139e0 r4:c04ee5f8
[<c01b8070>] (mount_fs+0x0/0xe0) from [<c01cdd54>] (vfs_kern_mount+0x54/0x94)
r6:00400000 r5:c38139e0 r4:c04ee5f8
[<c01cdd00>] (vfs_kern_mount+0x0/0x94) from [<c01cddb0>]
(kern_mount_data+0x1c/0x20)
r8:30104000 r7:c0545f7c r6:c0586628 r5:00000000 r4:00000000
[<c01cdd94>] (kern_mount_data+0x0/0x20) from [<c0118fb8>] (sysfs_init+0x64/0xc0)
[<c0118f54>] (sysfs_init+0x0/0xc0) from [<c0118134>] (mnt_init+0x90/0x19c)
r6:c054622c r5:c0546258 r4:00000000
[<c01180a4>] (mnt_init+0x0/0x19c) from [<c0117d5c>] (vfs_caches_init+0xa0/0x130)
r5:00003ab2 r4:00000000
[<c0117cbc>] (vfs_caches_init+0x0/0x130) from [<c0108908>]
(start_kernel+0x258/0x2bc)
r6:c0080280 r5:c012975c r4:c05460e0
[<c01086b0>] (start_kernel+0x0/0x2bc) from [<3010803c>] (0x3010803c)
r6:c0129758 r5:c0546068 r4:00007175
Code: c38139e0 00400000 c0545f50 c0545f30 (c01cdd54)
---[ end trace 1b75b31a2719ed1c ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Backtrace:
[<c013dec4>] (dump_backtrace+0x0/0x10c) from [<c0450378>] (dump_stack+0x18/0x1c)
r6:c0548440 r5:00000000 r4:c0572a1c
[<c0450360>] (dump_stack+0x0/0x1c) from [<c04504f8>] (panic+0x60/0x180)
[<c0450498>] (panic+0x0/0x180) from [<c0156968>] (do_exit+0x600/0x6a0)
r3:00000000 r2:c0544000 r1:c0545d30 r0:c04e549c
r7:c0545e40
[<c0156368>] (do_exit+0x0/0x6a0) from [<c013e37c>] (die+0x18c/0x1c4)
r7:c0545e40
[<c013e1f0>] (die+0x0/0x1c4) from [<c013e3d4>] (arm_notify_die+0x20/0x58)
r8:00000000 r7:c0545f28 r6:c0545e40 r5:c0549220 r4:ffffffff
[<c013e3b4>] (arm_notify_die+0x0/0x58) from [<c012f1a4>]
(do_undefinstr+0x118/0x168)
[<c012f08c>] (do_undefinstr+0x0/0x168) from [<c013adb8>] (__und_svc+0x38/0x60)
Exception stack(0xc0545e40 to 0xc0545e88)
5e40: c0545ea8 c009312c c3801520 c0545ea8 00000000 c0545ea8 c0545ea8 c009312c
5e60: c0092540 41129200 000002fb c0545e9c c0545ea0 c0545e88 c01ca9f4 c0545f28
5e80: 40000053 ffffffff
r8:c0092540 r7:c009312c r6:c0545ea8 r5:c0545e74 r4:ffffffff
[<c01ca9cc>] (alloc_inode+0x0/0xac) from [<c01cafb4>] (iget_locked+0x8c/0x138)
r5:c3801520 r4:00000000
[<c01caf28>] (iget_locked+0x0/0x138) from [<c0203d84>]
(sysfs_get_inode+0x1c/0x1a8)
[<c0203d68>] (sysfs_get_inode+0x0/0x1a8) from [<c02067d4>]
(sysfs_mount+0xf8/0x178)
r5:c0545ea8 r4:c3801520
[<c02066dc>] (sysfs_mount+0x0/0x178) from [<c01b808c>] (mount_fs+0x1c/0xe0)
r8:00000000 r7:c0559ab0 r6:c0559ab0 r5:c38139e0 r4:c04ee5f8
[<c01b8070>] (mount_fs+0x0/0xe0) from [<c01cdd54>] (vfs_kern_mount+0x54/0x94)
r6:00400000 r5:c38139e0 r4:c04ee5f8
[<c01cdd00>] (vfs_kern_mount+0x0/0x94) from [<c01cddb0>]
(kern_mount_data+0x1c/0x20)
r8:30104000 r7:c0545f7c r6:c0586628 r5:00000000 r4:00000000
[<c01cdd94>] (kern_mount_data+0x0/0x20) from [<c0118fb8>] (sysfs_init+0x64/0xc0)
[<c0118f54>] (sysfs_init+0x0/0xc0) from [<c0118134>] (mnt_init+0x90/0x19c)
r6:c054622c r5:c0546258 r4:00000000
[<c01180a4>] (mnt_init+0x0/0x19c) from [<c0117d5c>] (vfs_caches_init+0xa0/0x130)
r5:00003ab2 r4:00000000
[<c0117cbc>] (vfs_caches_init+0x0/0x130) from [<c0108908>]
(start_kernel+0x258/0x2bc)
r6:c0080280 r5:c012975c r4:c05460e0
[<c01086b0>] (start_kernel+0x0/0x2bc) from [<3010803c>] (0x3010803c)
r6:c0129758 r5:c0546068 r4:00007175
what should I do???
^ permalink raw reply
* Help wake from standby with ARM external nIRQ line
From: Steve deRosier @ 2013-08-29 4:49 UTC (permalink / raw)
To: linux-embedded
Hi,
I need some help trying to get an ARM based system to wake from
standby using the external nIRQ line.
It's a custom system based on the at91sam9g25ek. We have a
push-button attached to the nIRQ line on PB18. I want to be able to
put the system in standby (`echo standby > /sys/power/state`) and then
wake it by pressing the IRQ button.
I've taken the following steps:
1. Added the proper pinctrl entry in the DT to put PB18 on
perhipherial A (nIRQ function):
pinctrl@fffff400 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "atmel,at91sam9x5-pinctrl",
"atmel,at91rm9200-pinctrl", "simple-bus";
ranges = <0xfffff400 0xfffff400 0x800>;
/* shared pinctrl settings */
irqbtn {
pinctrl_irqbtn: irqb-0 {
atmel,pins =
<1 18 0x1 0x1>; /* PB18 periph A (IRQ) with pullup */
};
};
Unfortunately, problem #1: when I checked PIO_PSR on the running
system the pin was still set as GPIO. There's no conflicting setting
that I can find, so maybe I need to do more to get PB18 set as periph
A?
2. OK, fine, I manually set the PB18 pin on the running system to
perhph A so it does the nIRQ function to the interrupt controller. As
a test, I also manually set the interrupt mask to enable an interrupt
on that pin. Quick push test shows a result in dmesg:
[12547.023437] irq 0, desc: c38040a0, depth: 1, count: 0, unhandled: 0
[12547.023437] ->handle_irq(): c006155c, handle_bad_irq+0x0/0x21c
[12547.023437] ->irq_data.chip(): c04f59fc, no_irq_chip+0x0/0x5c
[12547.023437] ->action(): (null)
[12547.023437] IRQ_NOPROBE set
[12547.023437] IRQ_NOREQUEST set
Yay, did something good. Yes, I know I don't have a handler set,
should be OK for now...
3. Now, I put the thing into standby. Based on the Datasheet and what
I know about ARMs and what I read in the pm.c and related files, if
the nIRQ button is set as IRQ function, on standby the AIC will still
be clocked and when the ARM is in cpu idle (wait for interrupt),
either the nIRQ or nFIQ line can wake the processor, and it'll pull
out of the idle mode (cpu_arm926_do_idle line 102 in
arch/arm/mm/proc-arm926.S). In pm.c's at91_pm_enter(), it will return
from the at91sam9_standby() call, turn on interrupts and gpios and
continue.
Yet, I setup my pin, my IMR and put the sucker to standby. Press the
button... no response. Can't wake it.
4. Fine, try one more thing. I noticed when I force pm to bypass the
real standby code so I can see the various log messages, I see that
the one it prints that gives me the wakeup masks and my pin doesn't
show. OK, so I hack at91_irq_suspend() to || 0x80000000. Still no
joy.
Clearly there's something fundamental I don't understand about waking
the processor from idle mode via an external nIRQ interrupt. I can't
even get this thing setup manually to make it work. I do know the pin
functions and I've managed to get it in nIRQ mode. Just can't get
standby to wake.
I don't mind figuring out how to hack it up and get it manually
configured to work and then later figuring how to properly integrate
this into my system. I need it to work and I'll make it pretty in my
next step.
Any Linux ARM experts out there that can give me a push in the right direction?
Thanks,
- Steve
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-08 7:41 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <51FB6EE1.3090708@lumino.de>
As a résumé of this discussion I feel that it would be very viable to to
a commercial or non-commercial project that allows for easy use of a
single (or even multiple ) dedicated AMP CPU(s) working together with an
SMP Linux system in a multi core ARM Cortex A9 chip.
Here the supplier would need to provide:
- means to dedicate one (or more) CPU(s) to an AMP system(s)
(including setting the AMP Bit to prevent 1st level cache
synchronization for this CPU(s), and possibly including a patch for the
scheduler that performance prevents degradation due to the count of
managed CPUs being not identical with those found in hardware)
- means for communication with the AMP system(s) (i.e. a prototype for
a Kernel driver that allows for bidirectional "message-queue"- / pipe-
like communication using a DMA-alike non-cached memory region and mutual
interrupts for notification
- means to load and start a program in an AMP system (supposedly
provided by the same Kernel driver). Here supposedly some kind of cache
flush needs to be done as the cache synchronization is switched off for
the AMP CPU(s).
- appropriate documentation (including a definition on how to do the
software for the AMP system and including hints on how to calculate the
max latency)
What do you think ?
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-07 9:04 UTC (permalink / raw)
Cc: linux-embedded@vger.kernel.org
In-Reply-To: <520203E4.3070204@lumino.de>
I also found:
"This processor is in the inner shared domain, and uses its cache
coherency protocol."
I understand that some kind of memory coherency needs to be guaranteed
in AMP applications as well, if memory is used for communication between
the systems.
Of course with AMP can avoid using shared memory or restrict shared
memory usage to certain small areas necessary for communication. Perhaps
some kind of "cache bypass" method (that might be provided by the MPU
for DMA purpose) for the memory region used for communication can be
requested.
Thus, maybe setting SMPnAMP to "AMP" helps avoiding cache synchronizing
latency and by this greatly improves the calculated max latency and thus
especially in my favorite issue "virtual peripheral" is exactly the
missing feature that allows to avoid most of the "non-determinism"
problems Robert makes us aware of.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-07 8:29 UTC (permalink / raw)
Cc: linux-embedded@vger.kernel.org
In-Reply-To: <520203E4.3070204@lumino.de>
On 08/07/2013 10:23 AM, Michael Schnell wrote:
>
>
> "In the Cortex-A9 MPCore Technical Reference Manual I found the
> SMPnAMP Signal which switches between SMP or AMP for each Processor."
>
I found this:
SMPnAMP -> "Set whether the processor is part of a coherent domain."
Which does not help, because I don't know what a "coherent domain" is
supposed to mean.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-07 8:23 UTC (permalink / raw)
Cc: linux-embedded@vger.kernel.org
In-Reply-To: <51FF77A2.7030904@televic.com>
On 08/05/2013 12:00 PM, Lambrecht Jürgen wrote:
> "Actually, you can check on ARM community web site, where you will see that the CortexA9/GIC infrastructure enables AMP implementation.
> http://forums.arm.com/index.php?/topic/15656-cortex-a9-amp/
>
Here I see:
"In the Cortex-A9 MPCore Technical Reference Manual I found the SMPnAMP
Signal which switches between SMP or AMP for each Processor."
While it is encouraging to see that AMP _is_ a supported feature with
A9, I fail to understand what the use of making this known to the
hardware might be.
I supposed AMP vs SMP would be just a matter of software.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Lambrecht Jürgen @ 2013-08-05 10:00 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded@vger.kernel.org
In-Reply-To: <51FEC76C.70908@televic.com>
On 08/04/2013 11:28 PM, Lambrecht Jürgen wrote:
> On 08/02/2013 10:33 AM, Michael Schnell wrote:
> [snip]
>> - how to assign certain interrupts to that core and have ISRs run
>> there only dedicatedly interrupting the "main loop" and not ever being
>> blocked by any Linux activity ?
>> here I found this:
>> https://access.redhat.com/site/solutions/15482
>> In fact of course the hardware defines if/how a certain Interrupt can be
>> assigned to a certain CPU. How is this usually done when using ARM
>> Cortex A9+ cores ?.
> The ARM A9 datasheet will say what registers to write to assign IRQs to
> CPU1, and make Linux not to use those IRQs.
> Then the max. latency is determined by the clock speed and CPU cycles
> the bare metal program needs to react (should be in datasheet).
I asked a Freescale FAE and the cortex A9 is AMP capable (I also needed
to know this for my project):
"Actually, you can check on ARM community web site, where you will see that the CortexA9/GIC infrastructure enables AMP implementation.
http://forums.arm.com/index.php?/topic/15656-cortex-a9-amp/
The Global Interrupt Controller gives you the possibility to assign specific IT to specific cores. But a CortexA9 is not very RT oriented (for that ARM has created the Cortex R Family, with improved RT execution time)."
>
> About the non-determinism of modern hardware: if a chip is AMP capable
> the heating up of 1 core should not influence the other core. I believe
> heat spreads vertically (to the heatsink) and not so much horizontally.
> So an RTOS should run with a stable frequency. (anyhow, Linux should not
> touch the other CPU, or need to touch it).
That Freescale FAE warns about the voltage scaling: "you have only one
power line to supply all the cores, so all processor would be impacted.
There is no way to change that."
So indeed a problem with modern hardware..
Kind regards,
Jürgen--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-05 9:34 UTC (permalink / raw)
To: Guenter Ebermann; +Cc: linux-embedded
In-Reply-To: <CAJJW4y5tjinOxxCeovQFDf+E7w4Nadkv38iWxCKXzTbOTuJvVg@mail.gmail.com>
On 08/05/2013 11:06 AM, Guenter Ebermann wrote:
> I am using vanilla linux in an AMP setup on freescale P1022
> successfully....
Great to know this !
Thanks,
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Guenter Ebermann @ 2013-08-05 9:06 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded
Hi,
I am using vanilla linux in an AMP setup on freescale P1022
successfully. The needed
linux bootargs are:
maxcpus=1 mem=448M memmap=64M$0x1C000000
Then there is a linux userspace program and a kernel module (using kernel
function mpic_reset_core) to start an application (another OS) on the
second core.
For communication with the seconds core I use a non-blocking FIFO
in a shared RAM section.
Best regards,
Günter
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-05 9:04 UTC (permalink / raw)
Cc: linux-embedded
In-Reply-To: <20130805081758.GI30920@pengutronix.de>
On 08/05/2013 10:17 AM, Robert Schwebel wrote:
> On Mon, Aug 05, 2013 at 09:25:18AM +0200, Michael Schnell wrote:
>>> You can't. And you can't, even if you try to run bare-metal software
>>> on a dedicated core. I can't imagine how for example the cache
>>> influences between the cores could be determined.
>> This would render all efforts for hard realtime embedded Linux
>> applications useless. You always need to calculate the max latency.
> You can't calculate the max latency with today's complex processor
> hardware any more. It's all a matter of system failure probabilities.
So don't use them for realtime embedded applications ?
There are companies such as SysGo that seem to claim this possibility
with their PikeOS (see
http://www.sysgo.com/products/pikeos-rtos-and-virtualization-concept/rtos-technology/
). AFAIK, they don't even are able to use dedicated cores (yet). Of
course they don't support "virtual peripheral" technology here, but
strict determinism is a strung requirement with the critical "security"
applications they have in mind.
> Nevertheless, there always have been settings where you could get rid
> of all realtime complexity by spending a 1-Euro microcontroller to the
> BOM.
For "virtual peripherals" applications you will need either a fast CPU
or an FPGA.
> AM335x has PRU subprocessors (not ARM architecture).
The 4788 page "AM335x Applications Processor Technical Reference Manual"
(SPRUH73 – October 2011) on page 226 depicts the "ARM Cortex M3 Memory
Map".
> What kind of application is that?
At first we are discussion DMX I/O (there already is a running project
doing this with the 335x PRUS (on a BeagleBone board).
But this is only sample "virtual peripheral" project with rather low
demand that easily could be done with "a 1-Euro microcontroller". (and
in fact we already did this using a PIC33).
But in future we are planning for several kinds of propriety digital
waveforms that are to be generated or analyzed.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-05 8:42 UTC (permalink / raw)
Cc: linux-embedded
In-Reply-To: <20130805082100.GJ30920@pengutronix.de>
On 08/05/2013 10:21 AM, Robert Schwebel wrote:
> https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
Interesting stuff !
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Robert Schwebel @ 2013-08-05 8:21 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded
In-Reply-To: <51FF5813.701@lumino.de>
On Mon, Aug 05, 2013 at 09:45:23AM +0200, Michael Schnell wrote:
> On 08/02/2013 06:16 PM, Jon Sevy wrote:
> >You might try the Open Source Automation Development Labs website for real-time Linux latency measurements and methodology:
> >http://www.osadl.org/
> Thanks for the pointer !
>
> On the first glace I see that this might help with legal and similar
> issues, but I did not find anything regarding latency, yet.
https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: AMP on an SMP system
From: Robert Schwebel @ 2013-08-05 8:17 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded
In-Reply-To: <51FF535E.2050006@lumino.de>
On Mon, Aug 05, 2013 at 09:25:18AM +0200, Michael Schnell wrote:
> > You can't. And you can't, even if you try to run bare-metal software
> > on a dedicated core. I can't imagine how for example the cache
> > influences between the cores could be determined.
>
> This would render all efforts for hard realtime embedded Linux
> applications useless. You always need to calculate the max latency.
You can't calculate the max latency with today's complex processor
hardware any more. It's all a matter of system failure probabilities.
> Using a dedicated Core will certainly reduce the max latency, but of
> course it will not do away with the necessary calculations that take
> into account what the other CPUs might do (regarding second level
> Cache, cache synchronization, bus scheduling, etc.)
I don't think it is possible to get an analytic result for the max
latency introduced by other CPUs.
What we do today is to run preempt-rt systems, measure them under
realistic and extreme load and look at the max latencies. If you design
your system in a way that it runs at factor X above this max latency, it
should be fine.
The advantage of preempt-rt is that you have only one software
environment for rt and non-rt. Nevertheless, there always have been
settings where you could get rid of all realtime complexity by spending
a 1-Euro microcontroller to the BOM.
> IMHO, a good compromise is the TI 335x chip that has a single 1 GHz
> Cortex A8 and two 300 MHz Cortex A3 cores for a very reasonable price
> and and "embedded" specs for temperature range and future chip
> availability.
AM335x has PRU subprocessors (not ARM architecture). Yes, that can be a
solution. Freescale's Vybrid has Cortex-M3 cores.
> Right now, I am just investigating viable ways to do things, before
> doing a pre-decision for any hardware and starting do dive into that.
What kind of application is that?
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-05 7:45 UTC (permalink / raw)
Cc: linux-embedded
In-Reply-To: <yubr9upq3v2s0lvt9ljxqj6a.1375460180792@email.android.com>
On 08/02/2013 06:16 PM, Jon Sevy wrote:
> You might try the Open Source Automation Development Labs website for real-time Linux latency measurements and methodology:
> http://www.osadl.org/
Thanks for the pointer !
On the first glace I see that this might help with legal and similar
issues, but I did not find anything regarding latency, yet.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-05 7:36 UTC (permalink / raw)
Cc: linux-embedded@vger.kernel.org
In-Reply-To: <51FEC76C.70908@televic.com>
On 08/04/2013 11:28 PM, Lambrecht Jürgen wrote:
> The Xilinx Zynq is of course purpose-built for this kind of stuff.
> Also Altera has such a SoC (System on Chip). My student also found
> examples of an AMP solution with Linux/FreeRTOS and Linux/eCos.
I feel that for many "virtual Peripheral" applications (at least for
those I have in mind right now), a single dedicated 1 GHz Cortex should
be good enough. So I'd like to avoid the cost for hardware and
development of an additional FPGA .
> Let me know if you need more info, but I fear my answer is too deep
> embedded an away from Linux (when I read the other answers).
Thanks a lot for your encouraging notes. I think the gap between
embedded Linux and more propriety embedded OSes.
> Success anyhow, and I would be happy to read about your project!
Of course I am "here to stay". But in fact this is not really a project
yet but a rather long term thingy.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-05 7:25 UTC (permalink / raw)
Cc: linux-embedded
In-Reply-To: <20130803191149.GU3880@pengutronix.de>
On 08/03/2013 09:11 PM, Robert Schwebel wrote:
> One recent example: on MX6 (quadcore Cortex-A9), when you run a
> certain cpuburn tool, the temperature rises up to the maximum allowed
> value in just a couple of seconds, and then you either have the choice
> to burn your hardware or to use the tempmon interrupt to throttle down
> the speed of the cpu. You can imagine what all that means for
> latencies. So if you want to use a reasonably modern hardware, it is
> always a matter of "high system probability" of not missing a cycle.
I see.
OTOH. with hard realtime embedded Systems, you always need to determine
the max latency for any critical reaction (which of course is missed
when the system is defective, e.g. because the temperature gets higher
than predicted by design in worst case - e.g. because of a fan fail - or
things like power fail. Here of course the system needs to do a save
shutdown before such a worst case hits. )
(In fact what I have in mind is "virtual peripherals", which I define as
"hard realtime with extremely low latency", usable as an alternative to
FPGAs.)
> You can't. And you can't, even if you try to run bare-metal software on
> a dedicated core. I can't imagine how for example the cache influences
> between the cores could be determined.
This would render all efforts for hard realtime embedded Linux
applications useless. You always need to calculate the max latency.
Of course you are right that cache issues need to be taken into account.
But this is on top of the latency that is imposed by process scheduling
(if you consider user space) Kernel locks and interrupt delays (if you
consider Kernel space).
Using a dedicated Core will certainly reduce the max latency, but of
course it will not do away with the necessary calculations that take
into account what the other CPUs might do (regarding second level Cache,
cache synchronization, bus scheduling, etc.)
To eliminate this, you would need another dedicated chip (Processor or
FPGA). And this is exactly, what I would like to avoid regarding that a
quad core system with much higher Clock rate nowadays will cost less
than any homebrew multi chip solution.
IMHO, a good compromise is the TI 335x chip that has a single 1 GHz
Cortex A8 and two 300 MHz Cortex A3 cores for a very reasonable price
and and "embedded" specs for temperature range and future chip
availability.
> The really great thing with preempt-rt is that it is all Linx and
> POSIX. No need to invent new things like program starters, inter-
> process-communication and even inter-processor-communication.
Sounds very good - provided it is possible to calculate the the max
latency and same is a lot better than "usual".
> I'd suggest that you measure yourself.
That of course is necessary in any case.
Right now, I am just investigating viable ways to do things, before
doing a pre-decision for any hardware and starting do dive into that.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Lambrecht Jürgen @ 2013-08-04 21:28 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded@vger.kernel.org
In-Reply-To: <51FB6EE1.3090708@lumino.de>
On 08/02/2013 10:33 AM, Michael Schnell wrote:
> Hi Experts.
Hi, I am rather new to Linux, but now the RTOS eCos quite well, and have
done some bare metal coding.
This year, a student did his Master's project with my topic: evaluating
the Xilinx Zynq: a dual core ARM Cortex A9 with an FPGA (as sort of
co-processor).
And he demonstrated AMP with Linux on CPU0 and a bare metal program
running on CPU1.
> Is there a kind of "official" way to set aside one of the available
> cores in an SMP system from the Linux OS to do deeply embedded
> extremely-low-latency stuff in a kind of single task "main loop" type
> environment ? I.e. creating a true coprocessor from an SMP hardware.
I should start reading some multi-core datasheets, but I would expect
all embedded multi-core processors AMP capable
>
> Some of the problems that come in ind here include:
>
> - how to make the Linux initialization ignore one of the available
> cores or free a core later on ?
> Here I found this:
> http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re46.html
> So using one of the four cores for special purpose in fact is viable.
My student used Device Tree with 'maxcpus=1'
>
> - how to have a Linux task start the free running main loop ?
He followed Xilinx application notes (and google..) and it is
implemented that always CPU0 starts first, and CPU1 waits to start until
the start address is written to a specific address - my student did it
with a small Linux program.
>
> - how to assign certain interrupts to that core and have ISRs run
> there only dedicatedly interrupting the "main loop" and not ever being
> blocked by any Linux activity ?
> here I found this:
> https://access.redhat.com/site/solutions/15482
> In fact of course the hardware defines if/how a certain Interrupt can be
> assigned to a certain CPU. How is this usually done when using ARM
> Cortex A9+ cores ?.
The ARM A9 datasheet will say what registers to write to assign IRQs to
CPU1, and make Linux not to use those IRQs.
Then the max. latency is determined by the clock speed and CPU cycles
the bare metal program needs to react (should be in datasheet).
About the non-determinism of modern hardware: if a chip is AMP capable
the heating up of 1 core should not influence the other core. I believe
heat spreads vertically (to the heatsink) and not so much horizontally.
So an RTOS should run with a stable frequency. (anyhow, Linux should not
touch the other CPU, or need to touch it).
>
> - what about MMU issues ?
The bare metal program does not use the MMU. The L1 cache is separated,
and the shared L2 cache was not used by CPU1 to avoid problems.
The RAM was divided in 2 separate parts.
I think it is not too difficult to share some RAM (a third section in
the RAM) and let 1 of the core be the master of it to share data.
>
> - how to have a Linux application communicate with the non.-Linux
> application running on the dedicated core ?
> Here I found this:
> http://lwn.net/Articles/464391
>
>
> For example I (e.g.) would like a (now rather cheap) standard quadcore
> ARM Cortex A9 processor chip and modify a Debian distribution in a way
> that support this stuff.
>
> Thanks for any pointers ?
The Xilinx Zynq is of course purpose-built for this kind of stuff. Also
Altera has such a SoC (System on Chip).
My student also found examples of an AMP solution with Linux/FreeRTOS
and Linux/eCos.
Let me know if you need more info, but I fear my answer is too deep
embedded an away from Linux (when I read the other answers).
Success anyhow, and I would be happy to read about your project!
Jürgen
>
> -Michael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Jürgen Lambrecht
R&D Associate
Mobile: +32 499 644 531
Tel: +32 (0)51 303045 Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk
^ permalink raw reply
* Re: AMP on an SMP system
From: Robert Schwebel @ 2013-08-03 19:11 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Michael Schnell, linux-embedded
In-Reply-To: <51FBC7FE.4000403@gmail.com>
Hi,
On Fri, Aug 02, 2013 at 04:53:50PM +0200, Marco Stornelli wrote:
> > In fact I need a way to do very guaranteed low latency. regarding the
> > high clock rate (about 1 GHz) modern ARM chips can provide, maybe
> > preempt-rt with the cpu affinity might be a decent way to go.
Modern hardware has lots of features which makes them basically not
deterministic.
One recent example: on MX6 (quadcore Cortex-A9), when you run a certain
cpuburn tool, the temperature rises up to the maximum allowed value in
just a couple of seconds, and then you either have the choice to burn
your hardware or to use the tempmon interrupt to throttle down the speed
of the cpu. You can imagine what all that means for latencies.
So if you want to use a reasonably modern hardware, it is always a
matter of "high system probability" of not missing a cycle.
> Just to be clear: at the moment there isn't an easy way to dedicate
> "completely" a cpu for a task. The last time I tried (some years ago
> actually) to use exclusive cpu set, the scheduler didn't do a good
> work because it was designed for SMP, not SMP minus some piece.
> However you can try and you can report your results. It would be
> interesting.
Without having done some tests myself, I would expect that the -rt folks
have such scenarios.
> > The raining questions include
> > - how to calculate the maximum latency that can be guaranteed ? (i.e.
> > does the Kernel impose any spinlocks and interrupt disables on the would
> > be AMP subsystem ?)
You can't. And you can't, even if you try to run bare-metal software on
a dedicated core. I can't imagine how for example the cache influences
between the cores could be determined.
> No. You can use full dyn tick for example to disable timer
> interrupt, but it has got some pros and cons, especially with very
> low latency requirement.
>
> > - how to assign an interrupt (e.g. a dedicated timer) to the subsystem ?
>
> Interrupt handler are kernel thread, so you can schedule your kernel
> thread on your "normal" cpu.
The really great thing with preempt-rt is that it is all Linux and
POSIX. No need to invent new things like program starters, inter-
process-communication and even inter-processor-communication.
> > - Do the interrupts immediately call the ISR of the cpu "under
> >affinity" or is some additional latency imposed by the Kernel
>
> AFAIC, no latency for cpu "under affinity".
>
> >(and how
> >many cpu cycles at max are needed to enter the ISR) ?
>
> It's difficult to answer to this question because the performance
> depends on your system. From my last statistics I saw that with an
> rt linux kernel you can stay below 50us for the interrupt latency.
Here is an MX53 (single core cortex-a8) in the OSADL testlab:
https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencyplot-r0s5.0.html
But note that multicore is quite different. I'd suggest that you measure
yourself.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: AMP on an SMP system
From: Jon Sevy @ 2013-08-02 16:16 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Michael Schnell, linux-embedded
You might try the Open Source Automation Development Labs website for real-time Linux latency measurements and methodology:
http://www.osadl.org/
\
Jon
Marco Stornelli <marco.stornelli@gmail.com> wrote:
>Il 02/08/2013 18:00, Michael Schnell ha scritto:
>> On 08/02/2013 05:37 PM, Marco Stornelli wrote:
>>>
>>> I don't know your hw so my consideration are really general.
>> The hardware is not decided yet (it will be some A9 thingy). So for me
>> "really general" is just fine.
>>
>>> ISRs in rt kernel doesn't exist or at least the only work is to wake
>>> up the kernel thread for the management.
>> I see.
>>
>> But how to determine the max latency for this ?
>>
>
>Maybe on eLinux.org you can find some number.
>
>Marco
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-02 16:00 UTC (permalink / raw)
Cc: linux-embedded
In-Reply-To: <51FBD223.9020809@gmail.com>
On 08/02/2013 05:37 PM, Marco Stornelli wrote:
>
> I don't know your hw so my consideration are really general.
The hardware is not decided yet (it will be some A9 thingy). So for me
"really general" is just fine.
> ISRs in rt kernel doesn't exist or at least the only work is to wake
> up the kernel thread for the management.
I see.
But how to determine the max latency for this ?
> The thing you can do is to move the kernel thread for interrupt X
> where you want to manage it, or you can set a specific scheduler
> policy. For example you can set a SCHED_FIFO with a very high priority
> for your "really low latency" tasks. RT kernel does the work for you
> :) You can see here: http://lwn.net/Articles/146861/
This seems be rather easy to do. If this is "good enough" latency wise,
it seems to be the way to go.
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Marco Stornelli @ 2013-08-02 15:58 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded
In-Reply-To: <51FBD782.9070309@lumino.de>
Il 02/08/2013 18:00, Michael Schnell ha scritto:
> On 08/02/2013 05:37 PM, Marco Stornelli wrote:
>>
>> I don't know your hw so my consideration are really general.
> The hardware is not decided yet (it will be some A9 thingy). So for me
> "really general" is just fine.
>
>> ISRs in rt kernel doesn't exist or at least the only work is to wake
>> up the kernel thread for the management.
> I see.
>
> But how to determine the max latency for this ?
>
Maybe on eLinux.org you can find some number.
Marco
^ permalink raw reply
* Re: AMP on an SMP system
From: Marco Stornelli @ 2013-08-02 15:37 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded
In-Reply-To: <51FBCF46.4080700@lumino.de>
Il 02/08/2013 17:24, Michael Schnell ha scritto:
> On 08/02/2013 04:53 PM, Marco Stornelli wrote:
>>
>>> - how to assign an interrupt (e.g. a dedicated timer) to the
>>> subsystem ?
>>
>> Interrupt handler are kernel thread, so you can schedule your kernel
>> thread on your "normal" cpu.
> Sorry. I don't understand.
>
> The point I'd like to make is, that for really low latency stuff the ISR
> needs to take place immediately when the hardware fires an interrupt.
>
> As the Linux kernel will (for the SMP CPUs it handles) need to disable
> interrupt in certain cases, it is essential that the "really low
> latency" interrupt is assigned to the AMP cpu (that the Kernel will
> never touch).
>
>> AFAIC, no latency for cpu "under affinity".
> That would be great but it need the stuff described above.
> In fact the interrupt would need to be assigned to the AMP cpu by some
> hardware means (that I don't know anything about yet), and not be
> "forwarded" in any way from some other cpu (which is managed by the
> Kernel) and thus might be in a "interrupt disable state at some point in
> time.
>
I don't know your hw so my consideration are really general. ISRs in rt
kernel doesn't exist or at least the only work is to wake up the kernel
thread for the management. The thing you can do is to move the kernel
thread for interrupt X where you want to manage it, or you can set a
specific scheduler policy. For example you can set a SCHED_FIFO with a
very high priority for your "really low latency" tasks. RT kernel does
the work for you :) You can see here: http://lwn.net/Articles/146861/
Marco
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-02 15:24 UTC (permalink / raw)
Cc: linux-embedded
In-Reply-To: <51FBC7FE.4000403@gmail.com>
On 08/02/2013 04:53 PM, Marco Stornelli wrote:
>
>> - how to assign an interrupt (e.g. a dedicated timer) to the
>> subsystem ?
>
> Interrupt handler are kernel thread, so you can schedule your kernel
> thread on your "normal" cpu.
Sorry. I don't understand.
The point I'd like to make is, that for really low latency stuff the ISR
needs to take place immediately when the hardware fires an interrupt.
As the Linux kernel will (for the SMP CPUs it handles) need to disable
interrupt in certain cases, it is essential that the "really low
latency" interrupt is assigned to the AMP cpu (that the Kernel will
never touch).
> AFAIC, no latency for cpu "under affinity".
That would be great but it need the stuff described above.
In fact the interrupt would need to be assigned to the AMP cpu by some
hardware means (that I don't know anything about yet), and not be
"forwarded" in any way from some other cpu (which is managed by the
Kernel) and thus might be in a "interrupt disable state at some point in
time.
>> (and how
>> many cpu cycles at max are needed to enter the ISR) ?
>
> It's difficult to answer to this question because the performance
> depends on your system. From my last statistics I saw that with an rt
> linux kernel you can stay below 50us for the interrupt latency.
Of course (sorry for unclear language). I tried to ask for a pointer to
start developing an algorithm that allows to predict the max latency the
system can offer.
Here we could try to do these calculations as well with a "really
dedicated AMP" CPU and with a system using "preempt-rt" and "cpu
affinity" appropriately. to see if a more "standard" way to do things
might be good enough.
Thanks for your answers,
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Marco Stornelli @ 2013-08-02 14:53 UTC (permalink / raw)
To: Michael Schnell; +Cc: Robert Schwebel, linux-embedded
In-Reply-To: <51FBA261.10301@lumino.de>
Il 02/08/2013 14:13, Michael Schnell ha scritto:
> On 08/02/2013 01:42 PM, Robert Schwebel wrote:
>> Before hacking around (which might also lead to interesting solutions),
>> I would start using a kernel with preempt-rt support and play with the
>> cpu affinity:
>>
>> http://lxr.linux.no/#linux+v3.10.4/Documentation/kernel-parameters.txt#L1257
>>
>>
>
> Robert !
> Nice to see you here (I do own your "Embedded Linux Handbuch für
> Entwickler" :-) )
>
> Thanks for the pointer !
>
> I do already know "preempt-rt", but I was not aware of cpu affinity.
>
> So this might help.
>
> In fact I need a way to do very guaranteed low latency. regarding the
> high clock rate (about 1 GHz) modern ARM chips can provide, maybe
> preempt-rt with the cpu affinity might be a decent way to go.
>
Just to be clear: at the moment there isn't an easy way to dedicate
"completely" a cpu for a task. The last time I tried (some years ago
actually) to use exclusive cpu set, the scheduler didn't do a good work
because it was designed for SMP, not SMP minus some piece. However you
can try and you can report your results. It would be interesting.
> The raining questions include
> - how to calculate the maximum latency that can be guaranteed ? (i.e.
> does the Kernel impose any spinlocks and interrupt disables on the would
> be AMP subsystem ?)
No. You can use full dyn tick for example to disable timer interrupt,
but it has got some pros and cons, especially with very low latency
requirement.
> - how to assign an interrupt (e.g. a dedicated timer) to the subsystem ?
Interrupt handler are kernel thread, so you can schedule your kernel
thread on your "normal" cpu.
> - Do the interrupts immediately call the ISR of the cpu "under
> affinity" or is some additional latency imposed by the Kernel
AFAIC, no latency for cpu "under affinity".
> (and how
> many cpu cycles at max are needed to enter the ISR) ?
It's difficult to answer to this question because the performance
depends on your system. From my last statistics I saw that with an rt
linux kernel you can stay below 50us for the interrupt latency.
Marco
^ permalink raw reply
* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-02 12:13 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded
In-Reply-To: <20130802114225.GR3880@pengutronix.de>
On 08/02/2013 01:42 PM, Robert Schwebel wrote:
> Before hacking around (which might also lead to interesting solutions),
> I would start using a kernel with preempt-rt support and play with the
> cpu affinity:
>
> http://lxr.linux.no/#linux+v3.10.4/Documentation/kernel-parameters.txt#L1257
>
Robert !
Nice to see you here (I do own your "Embedded Linux Handbuch für
Entwickler" :-) )
Thanks for the pointer !
I do already know "preempt-rt", but I was not aware of cpu affinity.
So this might help.
In fact I need a way to do very guaranteed low latency. regarding the
high clock rate (about 1 GHz) modern ARM chips can provide, maybe
preempt-rt with the cpu affinity might be a decent way to go.
The raining questions include
- how to calculate the maximum latency that can be guaranteed ? (i.e.
does the Kernel impose any spinlocks and interrupt disables on the would
be AMP subsystem ?)
- how to assign an interrupt (e.g. a dedicated timer) to the subsystem ?
- Do the interrupts immediately call the ISR of the cpu "under
affinity" or is some additional latency imposed by the Kernel (and how
many cpu cycles at max are needed to enter the ISR) ?
Thanks,
-Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox