From: "Lambrecht Jürgen" <J.Lambrecht@TELEVIC.com>
To: Michael Schnell <mschnell@lumino.de>
Cc: "linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>
Subject: Re: AMP on an SMP system
Date: Sun, 4 Aug 2013 23:28:12 +0200 [thread overview]
Message-ID: <51FEC76C.70908@televic.com> (raw)
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
next prev parent reply other threads:[~2013-08-04 21:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-02 8:33 AMP on an SMP system Michael Schnell
2013-08-02 11:42 ` Robert Schwebel
2013-08-02 12:13 ` Michael Schnell
2013-08-02 14:53 ` Marco Stornelli
2013-08-02 15:24 ` Michael Schnell
2013-08-02 15:37 ` Marco Stornelli
2013-08-02 16:00 ` Michael Schnell
2013-08-02 15:58 ` Marco Stornelli
2013-08-03 19:11 ` Robert Schwebel
2013-08-05 7:25 ` Michael Schnell
2013-08-05 8:17 ` Robert Schwebel
2013-08-05 9:04 ` Michael Schnell
2013-08-04 21:28 ` Lambrecht Jürgen [this message]
2013-08-05 7:36 ` Michael Schnell
2013-08-05 10:00 ` Lambrecht Jürgen
2013-08-07 8:23 ` Michael Schnell
2013-08-07 8:29 ` Michael Schnell
2013-08-07 9:04 ` Michael Schnell
2013-08-08 7:41 ` Michael Schnell
-- strict thread matches above, loose matches on Subject: below --
2013-08-02 16:16 Jon Sevy
2013-08-05 7:45 ` Michael Schnell
2013-08-05 8:21 ` Robert Schwebel
2013-08-05 8:42 ` Michael Schnell
2013-08-05 9:06 Guenter Ebermann
2013-08-05 9:34 ` Michael Schnell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51FEC76C.70908@televic.com \
--to=j.lambrecht@televic.com \
--cc=linux-embedded@vger.kernel.org \
--cc=mschnell@lumino.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).