• Locked Locked
  • Replies 8 replies
  • Subscribers 119 subscribers
  • Views 6967 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-A9 AMP

Clemens Fischer
Note: This was originally posted on 8th January 2012 at http://forums.arm.com

Hi,

I am currently examining amp for embedded devices.

Is it possible to boot two operating systems on an Cortex-A9 in amp mode?

The p2020 power processor is capable of amp and there is an  implementation in u-boot that makes it possible to boot two os in amp  mode. Is there a similar implementation for the Cortex-A9? And if  not, is it possible and what steps are necessary to implement amp with  the Cortex-A9 cpu using u-boot or a different boot loader?

 

Any information would be helpful.

Best regards

Clemens

  • Note: This was originally posted on 9th January 2012 at http://forums.arm.com


    Yes, you can run 2+ OSes on a Cortex-A9 MPCore processor.  It's just that most people don't (at least, that is my experience).

    Technically, the challenge is co-ordinating the use of shared resources between the 2+ OSes.  For example, there is a shared interrupt controller (IC) in the MPCore processors.  You need some way to decided which OS is allowed to configure which parts of the IC.  The same goes for all the other things visible to both OSes.


    That are good news for me.
    Since I am focusing on Linux, I was thinking about device trees for coordinating the ressource sharing. That is the way it is done on the p2020 platform, when using Linux. With the p2020 u-boot can be used to assign a device tree blob (dtb) to the running OSes. For example the first OS gets a dtb with the first cpu deactivated and the second cpu active, since the p2020 is usually equiped with several ethernet ports the first os gets one ethernet port assigned and the second OS gets another port. In this case Linux only knows about the assigned hardware and (in my opinion) doesn't look for other hardware. Is that true?

    I understand the issue with the IC, I guess this could be solved with a dtb too?
    One thing I am concerned about is the MMU. I was thinking about compiling the multiple Linux Kernels with hard coded memory regions assigned. Is there any problem with multiple OSes and memory management on Cortex-A9 MPCore?

    What other shared ressources are there that are visible to both OSes?

    Best regards
    Clemens
  • Note: This was originally posted on 10th January 2012 at http://forums.arm.com

    Hi,
    I still have some questions/comments:

    I can't comment on Linux, usually at the point the OS starts my job is done.

    Do you have any hands-on experience with preparations for a multi-os boot on Cortex-A9 cpus, or do you know someone who does?

    On the MMU side, each core has its own independent MMU.  So having different mappings shouldn't be a problem.

    Do you have any idea where I can find documentation that describes how the MMUs work and where and how they are placed on a Cortex A-9 MP? Until now I can only find Information about the MMU in a single core Cortex.

    My main concern are the things both OSes must share, that is the IC and the SCU.

    In the Cortex-A9 MPCore Technical Reference Manual I found the SMPnAMP Signal which switches between SMP or AMP for each Processor. I think I read that this signal  turns off the SCU if it is set to AMP? I guess this is so, because  it would not make sense to have the SCU running in AMP mode, because with AMP no cache coherency is needed between the two processors?

    Concerning the IC, I was thinking about programming it before starting the OS and to disable the components on the board that are not needed for the specific OS and enabling them on the other OS, so that only interrupts occur to a OS that also has the corresponding hardware enabled.
    Is this approach realistic or am I misunderstanding the way an IC is used?

    I am very thankful that you take the time to answer my questions. You are a big help!

    Regards
    Clemens
  • Note: This was originally posted on 19th April 2012 at http://forums.arm.com

    Hey,
    I am still on to this topic and finally managed to start linux on the  second core of my OMAP4430 Pandaboard with the first core disabled.
    As ttfn already brought up, it seems the Interrupts are a problem.
    Linux stops quite early and stays in an endless loop waiting for a timer  to through an interrupt which should increase the jiffies so that  bogomips can be calculated.
    This Interrupt never occurs so that for me there are two possibilities:

    1. The timer is not active. I checked that via GPT_TCLR register which  is mapped to 0x4A318024. Bit 0 indicated that the GPTIMER1 is started.  This bit is set.

    2. The timer generated interrupt is not delivered to the right cpu. I  think this is the problem. I checked if the mask of the interrupts are  set correct:
    0x48241800 should be the address of GICD_ITARGETSR where the interrupt masks are stored:
    48241800 : 01010101 01010101 01010101 01010101
    48241810 : 00000000 00000000 01000000 01010101
    48241820 : 02020202 02020202 02020202 02020202
    48241830 : 02020202 02020202 02020202 02020202
    48241840 : 02020202 02020202 02020202 02020202
    48241850 : 02020202 02020202 02020202 02020202
    48241860 : 02020202 02020202 02020202 02020202
    48241870 : 02020202 02020202 02020202 02020202
    48241880 : 02020202 02020202 02020202 02020202
    48241890 : 02020202 02020202 02020202 02020202
    So beginning with Interrupt 32 all Interrupts are masked to go to cpu interface 1 (the second cpu).

    But still there are no interrupts arriving at the second cpu.

    Could it be that the CPU Interface of the gic for the second cpu is not activated?

    I know that the register GICC_CTLR enabled the signaling of interrupts  on a cpu interface, but I don't know how to be sure. Neither In the gic  architecture reference or any other references I could find a way to  read this register. Does anybody have an idea?

    In general, am I misunderstanding something?

    Regards
    Clemens
  • Note: This was originally posted on 13th January 2012 at http://forums.arm.com

    Clemens,
    >>What other shared ressources are there that are visible to both OSes?

    Is there external cache controller on your H/W (PL310)? That would be another shared resource. Without any synchronization among OSs there will be limited set of PL310 cache maintenance operations. (Only atomic operation by physical address can be issued concurrently by both CPUs.)

    I understand that you would keep SCU (snoop control unit) off & all memory marked as not-shared. That will also prevent broadcasts of MMU maintenance operations on internal cache, TLB & branch predictor.
  • Arm Employee Badge
    Note: This was originally posted on 9th January 2012 at http://forums.arm.com

    Yes, you can run 2+ OSes on a Cortex-A9 MPCore processor.  It's just that most people don't (at least, that is my experience).

    Technically, the challenge is co-ordinating the use of shared resources between the 2+ OSes.  For example, there is a shared interrupt controller (IC) in the MPCore processors.  You need some way to decided which OS is allowed to configure which parts of the IC.  The same goes for all the other things visible to both OSes.
  • Arm Employee Badge
    Note: This was originally posted on 9th January 2012 at http://forums.arm.com

    I can't comment on Linux, usually at the point the OS starts my job is done.

    On the MMU side, each core has its own independent MMU.  So having different mappings shouldn't be a problem.

    My main concern are the things both OSes must share, that is the IC and the SCU.
  • Arm Employee Badge
    Note: This was originally posted on 11th January 2012 at http://forums.arm.com

    Information on the MMU is architectural.  So you need to see the ARM Architecture Reference Manual.

    The SMP/AMP naming thing is somewhat misleading.  Enabling the MMU and setting the ACTLR.SMP bit enables the hardware coherency management.  That does not necessarily mean you have to being running a SMP OS.  Assuming that the different OSes have to talk to each other, hardware coherency could still be beneficial.
  • Note: This was originally posted on 21st August 2012 at http://forums.arm.com

    i'm going to implement what you have said,but not succeed yet.
    did you do this successful that run two os on a soc with two cores?

    thanks a lot.