From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:30:31
Hi,
I am sending bunch of patches which I have made for a Xilinx Zynq remoteproc AMP solution +
some patches around.
Xilinx Zynq is dual core ARM Cortex A9. Remoteproc in new interface for controlling other cpus
is the system. I have created solution where on one ARM runs Linux and the second ARM
runs RTOS or any other standalone firmware. It is AMP between two ARM cores.
Communication is done via shared memory with kicking via IPI interrupts.
Based on that I had to do some changes in the kernel which I am sending.
Thanks for your review,
Michal
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:30:41
gic_set_affinity doesn't support force option. Force option
should work with all possible cpus in the system not only with
online cpus.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
arch/arm/common/gic.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:30:50
This is just preparation patch for dynamic IPI allocation.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
arch/arm/kernel/smp.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:30:55
GIC supports up to 16 IPIs.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
Please correct me if this code is also designed for different
interrupt controller which doesn't support 16 IPIs.
---
arch/arm/include/asm/hardirq.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:31:00
Support dynamic IPI allocation. It supports cases
where user wants to use IPI for communication among cpus
and setup own handler for it.
New functions set_ipi_handler/clear_ipi_handler are used
for dynamic allocation.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
arch/arm/include/asm/smp.h | 3 +
arch/arm/kernel/smp.c | 104 +++++++++++++++++++++++++------------------
2 files changed, 63 insertions(+), 44 deletions(-)
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:31:13
linker script setups entry point to virtual address.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
Not sure what is the reason to setup entry point to virtual address.
---
arch/arm/kernel/vmlinux.lds.S | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:32:12
This function can be used by device driver for raising
software irqs. For example AMP(remoteproc) on Zynq.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
arch/arm/common/gic.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-06-18 11:33:50
On Mon, Jun 18, 2012 at 01:30:04PM +0200, Michal Simek wrote:
gic_set_affinity doesn't support force option. Force option
should work with all possible cpus in the system not only with
online cpus.
Neither does x86. Why do you want this? Offline CPUs are unable to
receive the interrupt in any case (and must not receive interrupts in
the bringup path until they are online.)
From: Russell King - ARM Linux <hidden> Date: 2012-06-18 11:35:55
On Mon, Jun 18, 2012 at 01:30:08PM +0200, Michal Simek wrote:
GIC supports up to 16 IPIs.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
Please correct me if this code is also designed for different
interrupt controller which doesn't support 16 IPIs.
This code is not specific to the GIC. We use NR_IPI to indicate the
number of IPIs that the kernel actually uses, not the number which the
hardware provides.
From: Russell King - ARM Linux <hidden> Date: 2012-06-18 11:36:25
On Mon, Jun 18, 2012 at 01:30:09PM +0200, Michal Simek wrote:
Support dynamic IPI allocation. It supports cases
where user wants to use IPI for communication among cpus
and setup own handler for it.
New functions set_ipi_handler/clear_ipi_handler are used
for dynamic allocation.
From: Russell King - ARM Linux <hidden> Date: 2012-06-18 11:37:23
On Mon, Jun 18, 2012 at 01:30:11PM +0200, Michal Simek wrote:
quoted hunk
linker script setups entry point to virtual address.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
Not sure what is the reason to setup entry point to virtual address.
---
arch/arm/kernel/vmlinux.lds.S | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:41:59
On 06/18/2012 01:33 PM, Russell King - ARM Linux wrote:
On Mon, Jun 18, 2012 at 01:30:04PM +0200, Michal Simek wrote:
quoted
gic_set_affinity doesn't support force option. Force option
should work with all possible cpus in the system not only with
online cpus.
Neither does x86. Why do you want this? Offline CPUs are unable to
receive the interrupt in any case (and must not receive interrupts in
the bringup path until they are online.)
The whole reason for all these changes in AMP on dual core Cortex A9 where
on one cpu runs Linux and on the second RTOS/standlone.
It means that the second cpu is from Linux point of view offline all the time.
But GIC has to be (and can be) setup to forward IRQ directly to the second cpu.
GIC should be controlled by Linux.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:45:48
On 06/18/2012 01:37 PM, Russell King - ARM Linux wrote:
On Mon, Jun 18, 2012 at 01:30:11PM +0200, Michal Simek wrote:
quoted
linker script setups entry point to virtual address.
Signed-off-by: Michal Simek<monstr@monstr.eu>
---
Not sure what is the reason to setup entry point to virtual address.
---
arch/arm/kernel/vmlinux.lds.S | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
stext etc better stay as the virtual address through this change. The
kernel makes use of all stext/etext etc symbols as virtual addresses.
I am not changing stext to physical address. Just elf entry point.
What's it reason to have entry point in virtual address space?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:53:48
On 06/18/2012 01:34 PM, Russell King - ARM Linux wrote:
On Mon, Jun 18, 2012 at 01:30:07PM +0200, Michal Simek wrote:
quoted
This is just preparation patch for dynamic IPI allocation.
Why?
Let's start with this one first.
The reason for dynamic IPI allocation is that IPI interrupts can be used (and I am using them)
for sending IRQ to the second cpu and the second cpu doesn't run Linux.
But still I need functionality for sending interrupts to the second core for Linux. A also need
to have any hook to be able to receive irq from the second core.
Based on that I have looked at this code where only static allocation is used and it is not possible
to use it in this model because no driver can allocate IPI handler.
Based on that I have changed it to model where dynamic IPIs can be allocated dynamically.
As you see from the code. Origin static IPI allocation is still there.
Maybe what it is not visible is that NR_IPI value. As you commented in 5/8 NR_IPI stores number of
IPI used by Linux and I am using is as maximum IPIs in the system.
I am completely fine with not changing NR_IPI value and introduce new one like MAX_NR_IPI value which
will be for Xilinx Zynq GIC setup to 16.
Hope I have clarify it a little bit.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:54:42
On 06/18/2012 01:36 PM, Russell King - ARM Linux wrote:
On Mon, Jun 18, 2012 at 01:30:09PM +0200, Michal Simek wrote:
quoted
Support dynamic IPI allocation. It supports cases
where user wants to use IPI for communication among cpus
and setup own handler for it.
New functions set_ipi_handler/clear_ipi_handler are used
for dynamic allocation.
For what purpose?
Please look at my reaction in 4/8. It is the part of dynamic IPI allocation.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 11:55:00
On 06/18/2012 01:35 PM, Russell King - ARM Linux wrote:
On Mon, Jun 18, 2012 at 01:30:08PM +0200, Michal Simek wrote:
quoted
GIC supports up to 16 IPIs.
Signed-off-by: Michal Simek<monstr@monstr.eu>
---
Please correct me if this code is also designed for different
interrupt controller which doesn't support 16 IPIs.
This code is not specific to the GIC. We use NR_IPI to indicate the
number of IPIs that the kernel actually uses, not the number which the
hardware provides.
ok.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
From: Nicolas Pitre <hidden> Date: 2012-06-18 14:13:25
On Mon, 18 Jun 2012, Michal Simek wrote:
Setup correct virtual and physical address in ELF LOAD section.
We are moving to a single kernel binary for multiple targets, including
targets with different physical load addresses. The kernel code figures
out at run time what the actual physical address is when
CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days. In
other words, we don't know the physical offset at build time in that
case and CONFIG_PHYS_OFFSET is simply not defined.
Why do you need this change? Your patch comments are lacking
justification for them.
Setup correct virtual and physical address in ELF LOAD section.
We are moving to a single kernel binary for multiple targets, including
targets with different physical load addresses. The kernel code figures
out at run time what the actual physical address is when
CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days. In
other words, we don't know the physical offset at build time in that
case and CONFIG_PHYS_OFFSET is simply not defined.
ok. good to know and nice features. In that case I expect that you are
using any binary format
and you copy it to memory and run it. Code find out where it runs and based
on that setup things.
(BTW: This is very interesting for me to implement it on Microblaze. Can
you point me to that kernel code part? or any doc?)
But can you do it with elf? From my experience elf loaders are reading
physical address from program headers
and load all load sections. At the end they read entry point address and
setup PC on it and run it
(readelf -l -h). If these values are setup incorrectly to virtual addresses
elf loader just load them to virtual memory address
or just failed.
Why do you need this change? Your patch comments are lacking
justification for them.
The main reason is to elf loaders.
Please correct me if I am wrong IRC ARM Qemu uses zImage but it is no
problem to use elf file. For this case
Qemu elf loader also uses physical addresses from ELF and also entry point.
There is one more thing in connection with this patch which is that exactly
the same description is done
in asm-generic/vmlinux.lds.h macros which arm lds.S includes. For example
INIT_TEXT_SECTION.
If you look at vmlinux before and after my changes you will see some
differences which shouldn't affect your binary format
at all. Look below to readelf outputs.
I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf
entry point for this case?
Thanks,
Michal
Before:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x80008000
Start of program headers: 52 (bytes into file)
Start of section headers: 84873104 (bytes into file)
Flags: 0x5000002, has entry point, Version5
EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 37
Section header string table index: 34
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x008000 0x80008000 0x80008000 0x254a204 0x255e814 RWE
0x8000
NOTE 0x25521e0 0x825521e0 0x825521e0 0x00024 0x00024 R E 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
After:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x10008000
Start of program headers: 52 (bytes into file)
Start of section headers: 84873088 (bytes into file)
Flags: 0x5000002, has entry point, Version5
EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 37
Section header string table index: 34
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x008000 0x80008000 0x10008000 0x254a204 0x255e814 RWE
0x8000
NOTE 0x25521e0 0x825521e0 0x125521e0 0x00024 0x00024 R E 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120618/f66f580d/attachment-0001.html>
From: Nicolas Pitre <hidden> Date: 2012-06-18 19:02:58
On Mon, 18 Jun 2012, Michal Simek wrote:
2012/6/18 Nicolas Pitre [off-list ref]
quoted
On Mon, 18 Jun 2012, Michal Simek wrote:
quoted
Setup correct virtual and physical address in ELF LOAD section.
We are moving to a single kernel binary for multiple targets, including
targets with different physical load addresses. The kernel code figures
out at run time what the actual physical address is when
CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days. In
other words, we don't know the physical offset at build time in that
case and CONFIG_PHYS_OFFSET is simply not defined.
ok. good to know and nice features. In that case I expect that you are
using any binary format and you copy it to memory and run it. Code
find out where it runs and based on that setup things.
Exact.
(BTW: This is very interesting for me to implement it on Microblaze. Can
you point me to that kernel code part? or any doc?)
You could have a look at https://wiki.ubuntu.com/Specs/ARMSingleKernel,
especially the section "Optimized virt_to_phys() with a runtime
determined PHYS_OFFSET".
Then the following commits should be of interest:
72a20e22f4 "ARM: P2V: eliminate head.S use of PHYS_OFFSET for !XIP_KERNEL"
dc21af99fa "ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching"
But can you do it with elf?
No.
Please correct me if I am wrong IRC ARM Qemu uses zImage but it is no
problem to use elf file. For this case
Qemu elf loader also uses physical addresses from ELF and also entry point.
If you want to use the ELF image, then you need to hardcode the physical
memory location in its header, and that's something we want to get away
from because it prevents a single kernel binary image from being used on
different targets with different memory layouts. Same issue with
u-Boot's legacy uImage format.
I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf
entry point for this case?
For the kernel image itself it is the kernel virtual address.
For the relocatable zImage decompressor wrapper it is 0.
Nicolas
From: Michal Simek <monstr@monstr.eu> Date: 2012-06-18 19:24:03
On 06/18/2012 09:02 PM, Nicolas Pitre wrote:
On Mon, 18 Jun 2012, Michal Simek wrote:
quoted
2012/6/18 Nicolas Pitre[off-list ref]
quoted
On Mon, 18 Jun 2012, Michal Simek wrote:
quoted
Setup correct virtual and physical address in ELF LOAD section.
We are moving to a single kernel binary for multiple targets, including
targets with different physical load addresses. The kernel code figures
out at run time what the actual physical address is when
CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days. In
other words, we don't know the physical offset at build time in that
case and CONFIG_PHYS_OFFSET is simply not defined.
ok. good to know and nice features. In that case I expect that you are
using any binary format and you copy it to memory and run it. Code
find out where it runs and based on that setup things.
Exact.
ok. One more question about this feature. What is the alignment for it?
I mean I have done the similar feature for Xilinx ppc440 and alignment depends on
MMU TLB size.
quoted
(BTW: This is very interesting for me to implement it on Microblaze. Can
you point me to that kernel code part? or any doc?)
You could have a look at https://wiki.ubuntu.com/Specs/ARMSingleKernel,
especially the section "Optimized virt_to_phys() with a runtime
determined PHYS_OFFSET".
Then the following commits should be of interest:
72a20e22f4 "ARM: P2V: eliminate head.S use of PHYS_OFFSET for !XIP_KERNEL"
dc21af99fa "ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching"
ok. Thanks will look at it.
quoted
But can you do it with elf?
No.
ok
quoted
Please correct me if I am wrong IRC ARM Qemu uses zImage but it is no
problem to use elf file. For this case
Qemu elf loader also uses physical addresses from ELF and also entry point.
If you want to use the ELF image, then you need to hardcode the physical
memory location in its header, and that's something we want to get away
from because it prevents a single kernel binary image from being used on
different targets with different memory layouts. Same issue with
u-Boot's legacy uImage format.
And are you able to get these information away from ELF? Or you just need to set it up
to any default value. I would expect to 0x0.
quoted
I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf
entry point for this case?
For the kernel image itself it is the kernel virtual address.
Is it used somewhere? Or is it just setup to virtual address and no code use it?
I mean that kernel virtual entry point.
I expect that if CONFIG_ARM_PATCH_PHYS_VIRT=y then CONFIG_PHYS_OFFSET is not setup
Then LOAD_OFFSET should be equal to CONFIG_PAGE_OFFSET.
For the relocatable zImage decompressor wrapper it is 0.
ok.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
From: Nicolas Pitre <hidden> Date: 2012-06-18 21:10:21
On Mon, 18 Jun 2012, Michal Simek wrote:
On 06/18/2012 09:02 PM, Nicolas Pitre wrote:
quoted
On Mon, 18 Jun 2012, Michal Simek wrote:
quoted
2012/6/18 Nicolas Pitre[off-list ref]
quoted
On Mon, 18 Jun 2012, Michal Simek wrote:
quoted
Setup correct virtual and physical address in ELF LOAD section.
We are moving to a single kernel binary for multiple targets, including
targets with different physical load addresses. The kernel code figures
out at run time what the actual physical address is when
CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days. In
other words, we don't know the physical offset at build time in that
case and CONFIG_PHYS_OFFSET is simply not defined.
ok. good to know and nice features. In that case I expect that you are
using any binary format and you copy it to memory and run it. Code
find out where it runs and based on that setup things.
Exact.
ok. One more question about this feature. What is the alignment for
it? I mean I have done the similar feature for Xilinx ppc440 and
alignment depends on MMU TLB size.
Currently the alignment is 16MB as this is the granularity that a single
add or sub instruction can cover with an immediate argument. This is
highly specific to the ARM instruction set. At some point we needed 2MB
alignment which required two adds or subs, but that requirement has now
been removed.
quoted
If you want to use the ELF image, then you need to hardcode the physical
memory location in its header, and that's something we want to get away
from because it prevents a single kernel binary image from being used on
different targets with different memory layouts. Same issue with
u-Boot's legacy uImage format.
And are you able to get these information away from ELF? Or you just
need to set it up to any default value. I would expect to 0x0.
We just don't use the ELF image format with bootloaders.
quoted
quoted
I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf
entry point for this case?
For the kernel image itself it is the kernel virtual address.
Is it used somewhere? Or is it just setup to virtual address and no
code use it? I mean that kernel virtual entry point.
Nothing uses it. The official ARM kernel image format is a binary image
and its entry point is the very beginning of it.
I expect that if CONFIG_ARM_PATCH_PHYS_VIRT=y then CONFIG_PHYS_OFFSET
is not setup Then LOAD_OFFSET should be equal to CONFIG_PAGE_OFFSET.
No. CONFIG_PAGE_OFFSET is the virtual address that the kernel uses for
the beginning of its memory view. That is not where the kernel is
loaded.
Nicolas
Setup correct virtual and physical address in ELF LOAD section.
We are moving to a single kernel binary for multiple targets,
including
quoted
quoted
quoted
quoted
targets with different physical load addresses. The kernel code
figures
quoted
quoted
quoted
quoted
out at run time what the actual physical address is when
CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days.
In
quoted
quoted
quoted
quoted
other words, we don't know the physical offset at build time in
that
quoted
quoted
quoted
quoted
case and CONFIG_PHYS_OFFSET is simply not defined.
ok. good to know and nice features. In that case I expect that you
are
quoted
quoted
quoted
using any binary format and you copy it to memory and run it. Code
find out where it runs and based on that setup things.
Exact.
ok. One more question about this feature. What is the alignment for
it? I mean I have done the similar feature for Xilinx ppc440 and
alignment depends on MMU TLB size.
Currently the alignment is 16MB as this is the granularity that a single
add or sub instruction can cover with an immediate argument. This is
highly specific to the ARM instruction set. At some point we needed 2MB
alignment which required two adds or subs, but that requirement has now
been removed.
ok.
quoted
quoted
If you want to use the ELF image, then you need to hardcode the
physical
quoted
quoted
memory location in its header, and that's something we want to get away
from because it prevents a single kernel binary image from being used
on
quoted
quoted
different targets with different memory layouts. Same issue with
u-Boot's legacy uImage format.
And are you able to get these information away from ELF? Or you just
need to set it up to any default value. I would expect to 0x0.
We just don't use the ELF image format with bootloaders.
ok
quoted
quoted
quoted
I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is
elf
quoted
quoted
quoted
entry point for this case?
For the kernel image itself it is the kernel virtual address.
Is it used somewhere? Or is it just setup to virtual address and no
code use it? I mean that kernel virtual entry point.
Nothing uses it. The official ARM kernel image format is a binary image
and its entry point is the very beginning of it.
ok.
quoted
I expect that if CONFIG_ARM_PATCH_PHYS_VIRT=y then CONFIG_PHYS_OFFSET
is not setup Then LOAD_OFFSET should be equal to CONFIG_PAGE_OFFSET.
No. CONFIG_PAGE_OFFSET is the virtual address that the kernel uses for
the beginning of its memory view. That is not where the kernel is
loaded.
On 06/18/2012 01:33 PM, Russell King - ARM Linux wrote:
quoted
On Mon, Jun 18, 2012 at 01:30:04PM +0200, Michal Simek wrote:
quoted
gic_set_affinity doesn't support force option. Force option
should work with all possible cpus in the system not only with
online cpus.
Neither does x86. Why do you want this? Offline CPUs are unable to
receive the interrupt in any case (and must not receive interrupts in
the bringup path until they are online.)
The whole reason for all these changes in AMP on dual core Cortex A9 where
on one cpu runs Linux and on the second RTOS/standlone.
It means that the second cpu is from Linux point of view offline all the
time.
But GIC has to be (and can be) setup to forward IRQ directly to the second
cpu.
GIC should be controlled by Linux.
Russel: Any other reaction?
Can you see a way how to get this feature to the mainline Linux kernel?
Some patches needs to be refactored a little bit but the point is if you
are willing to
support this type of configuration.
Not sure if Ohad has any information that someone else would like to use it
remoteproc(AMP) among ARM cores.
Thanks,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120620/5d1c190a/attachment-0001.html>