[Clemens]

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

[ttfn]

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.

[Clemens]

ttfn, on 09 January 2012 - 08:11 AM, said:

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

[ttfn]

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.

[Clemens]

Hi,
I still have some questions/comments:

Quote

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?

Quote

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.

Quote

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

[ttfn]

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.

[djordje]

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.

[Clemens]

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

[Ezio]

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.