SMP for L4Linux on i.MX6

Adam Lackorzynski adam at
Mon Oct 13 20:19:36 CEST 2014


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 
> 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                 adam at

More information about the l4-hackers mailing list