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@xxxxxxxxxxxxxxx > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
