• Locked Locked
  • Replies 8 replies
  • Subscribers 119 subscribers
  • Views 6917 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

Parents
  • 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
Reply
  • 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
Children
No data