Hi!
We have an i.MX6 quadcore SoC and obviously we would like to use more than 1 core in L4Linux. So far I have not succeeded to do that.
jdb shows 4 CPUs and some tasks on different ones, so I assume our Fiasco configuration supports SMP. Still all L4Linux tasks are on the same one and CPU stress testing shows clearly that only 1 CPU is in use.
From an earlier posting on this list I found the L4.Proto.Scheduler
configuration for ned. I tried various options but there was no effect, L4Linux user space runs on 1 core only.
-- CPUs 1 + 2 -- scheduler = L4.Env.user_factory:create(L4.Proto.Scheduler, 0x18, 0x8, 6), -- maybe no mask means all CPUs? scheduler = L4.Env.user_factory:create(L4.Proto.Scheduler, 0x18, 0x8),
Next I looked at our L4Linux configuration and indeed CONFIG_SMP was not set. However after enabling it the kernel does no longer build:
arch/arm/mach-imx/built-in.o: In function `imx_smp_prepare': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable' /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable' arch/arm/mach-imx/built-in.o: In function `imx_smp_init_cpus': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:71: undefined reference to `scu_get_core_count' arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/headsmp.S:33: undefined reference to `v7_invalidate_l1' /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/headsmp.S:35: undefined reference to `secondary_startup'
The SCU http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407e/CDDEHDD... has to do with cache coherency, obviously important on SMP.
The SCU code is in native ARM, but not in L4 ARM. I somehow have the feeling just copying it is not enough. Does the virtual CPU seen by L4Linux need to control/use the SCU or is that something made completely transparent by the virtual cpu offered by L4?
v7_secondary_startup code is behind !defined(CONFIG_L4). The code does a lot of MMU initializion stuff, so my guess is this cannot worked unchanged under L4.
So the question is: Is SMP for i.MX6 unimplemented or at least untested or am I doing something completely wrong here?
Somebody here mentioned VCPU. I have not studied that concept yet. We have CONFIG_L4_VCPU=y
Regards,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@nomovok.com (bot test: humans correct 1 obvious spelling error)
Hi,
On Mon Oct 13, 2014 at 19:12:25 +0300, Uwe Geuder wrote:
We have an i.MX6 quadcore SoC and obviously we would like to use more than 1 core in L4Linux. So far I have not succeeded to do that.
jdb shows 4 CPUs and some tasks on different ones, so I assume our Fiasco configuration supports SMP. Still all L4Linux tasks are on the
Yes, that looks good.
same one and CPU stress testing shows clearly that only 1 CPU is in use.
From an earlier posting on this list I found the L4.Proto.Scheduler
configuration for ned. I tried various options but there was no effect, L4Linux user space runs on 1 core only.
For L4Linux, you need to specify how many CPUs it should use via cmdline option: l4x_cpus=X
-- CPUs 1 + 2 -- scheduler = L4.Env.user_factory:create(L4.Proto.Scheduler, 0x18, 0x8, 6), -- maybe no mask means all CPUs? scheduler = L4.Env.user_factory:create(L4.Proto.Scheduler, 0x18, 0x8),
Do not use any of those in this case.
Next I looked at our L4Linux configuration and indeed CONFIG_SMP was not set. However after enabling it the kernel does no longer build:
arch/arm/mach-imx/built-in.o: In function `imx_smp_prepare': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable' /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable'
So why does this happen? For L4Linux, no arch/arm/mach-*/*smp* file should need to be taken (must not be taken).
The SCU http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407e/CDDEHDD... has to do with cache coherency, obviously important on SMP.
Yes, it is.
The SCU code is in native ARM, but not in L4 ARM. I somehow have the feeling just copying it is not enough. Does the virtual CPU seen by L4Linux need to control/use the SCU or is that something made completely transparent by the virtual cpu offered by L4?
User programs, such as L4Linux, have nothing to do with the SCU, i.e. it is completely transparent.
v7_secondary_startup code is behind !defined(CONFIG_L4). The code does a lot of MMU initializion stuff, so my guess is this cannot worked unchanged under L4.
L4Linux has its own secondary_startup routine. Do not use any BSP specific one.
Adam
On 13 October 2014 21:19, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
Hi,
On Mon Oct 13, 2014 at 19:12:25 +0300, Uwe Geuder wrote:
We have an i.MX6 quadcore SoC and obviously we would like to use more than 1 core in L4Linux. So far I have not succeeded to do that.
...
For L4Linux, you need to specify how many CPUs it should use via cmdline option: l4x_cpus=X
Thanks for your answer, done now.
-- CPUs 1 + 2 -- scheduler = L4.Env.user_factory:create(L4.Proto.Scheduler, 0x18, 0x8, 6), -- maybe no mask means all CPUs? scheduler = L4.Env.user_factory:create(L4.Proto.Scheduler, 0x18, 0x8),
Do not use any of those in this case.
Removed.
Does the virtual CPU seen by L4Linux need to control/use the SCU or is that something made completely transparent by the virtual cpu offered by L4?
User programs, such as L4Linux, have nothing to do with the SCU, i.e. it is completely transparent.
OK, good.
So I measured again and could not find any effects whether l4x_cpus=3 is present or not.
Next I looked at the code what l4x_cpus= does. And indeed it does nothing. To be more exact all it does is inside #ifdef CONFIG_SMP. You did not explicitly say that I should disable that option, but I still concluded I should do so to get rid of the build failures.
But as I wrote before, I had not been able to build with that option enabled
Next I looked at our L4Linux configuration and indeed CONFIG_SMP was not set. However after enabling it the kernel does no longer build:
arch/arm/mach-imx/built-in.o: In function `imx_smp_prepare': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable' /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable' arch/arm/mach-imx/built-in.o: In function `imx_smp_init_cpus': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:71: undefined reference to `scu_get_core_count' arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/headsmp.S:33: undefined reference to `v7_invalidate_l1' /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/headsmp.S:35: undefined reference to `secondary_startup'
So if CONFIG_SMP is needed to be selected, how can I solve the build problems?
Regards,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@nomovok.com (bot test: humans correct 1 obvious spelling error)
On Thu Oct 16, 2014 at 23:33:28 +0300, Uwe Geuder wrote:
On 13 October 2014 21:19, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
Does the virtual CPU seen by L4Linux need to control/use the SCU or is that something made completely transparent by the virtual cpu offered by L4?
User programs, such as L4Linux, have nothing to do with the SCU, i.e. it is completely transparent.
OK, good.
So I measured again and could not find any effects whether l4x_cpus=3 is present or not.
Next I looked at the code what l4x_cpus= does. And indeed it does nothing. To be more exact all it does is inside #ifdef CONFIG_SMP. You did not explicitly say that I should disable that option, but I still concluded I should do so to get rid of the build failures.
CONFIG_SMP must be enabled.
But as I wrote before, I had not been able to build with that option enabled
Next I looked at our L4Linux configuration and indeed CONFIG_SMP was not set. However after enabling it the kernel does no longer build:
arch/arm/mach-imx/built-in.o: In function `imx_smp_prepare': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable' /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:79: undefined reference to `scu_enable' arch/arm/mach-imx/built-in.o: In function `imx_smp_init_cpus': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/platsmp.c:71: undefined reference to `scu_get_core_count' arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup': /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/headsmp.S:33: undefined reference to `v7_invalidate_l1' /home/geuder/projects/c4c/l4-bundle/l4linux/arch/arm/mach-imx/headsmp.S:35: undefined reference to `secondary_startup'
So if CONFIG_SMP is needed to be selected, how can I solve the build problems?
Are there any build issues when you use an unmodified L4Linux, i.e. one that does not have any adaptions for imx?
Adam
l4-hackers@os.inf.tu-dresden.de