[PATCH] UBUNTU: [Config] Enable OMAP4 support in master

Bryan Wu bryan.wu at canonical.com
Mon Aug 2 06:09:29 UTC 2010


I back-ported b970ecd55364ba3be1b6a500bf16abda3c8ec7e2 to our master tree and
built the kernel. Kernel works fine on my Panda board with console=ttyS2 instead
of ttyO2 and the rootfs is maverick.

Please find the kernel package here:

I also pushed patches here:

But I do find the conflict issue between OMAP2/3 and OMAP4. As we got 2 core in
OMAP4 processor first time, we need CONFIG_SMP=y to activate the second CPU
core. But in omap3_defconfig and upstream single kernel config, CONFIG_SMP is off.

If we enable CONFIG_SMP=y in OMAP2/3/4 single kernel config, we will got
following building error:
  AS      arch/arm/kernel/entry-armv.o
arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:47: Error: bad instruction `test_for_ipi r0,r6,r5,lr'
arch/arm/kernel/entry-armv.S:47: Error: bad instruction `test_for_ltirq r0,r6,r5,lr'
arch/arm/kernel/entry-armv.S:47: Error: bad instruction `test_for_ipi r0,r6,r5,lr'
arch/arm/kernel/entry-armv.S:47: Error: bad instruction `test_for_ltirq r0,r6,r5,lr'
make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1
make: *** [arch/arm/kernel] Error 2

I will try to fix this.

So currently, if we wanna enable OMAP4 in our master tree, we need turn off the
CONFIG_SMP. Kernel works fine, but we just got 1 core.

In our -omap4 branch, we got dual core with CONFIG_SMP=y.


On 07/30/2010 10:34 PM, Bryan Wu wrote:
> On 07/30/2010 08:20 PM, Amit Kucheria wrote:
>> On 10 Jul 30, Bryan Wu wrote:
>>> I did some investigation today and found that even upstream Tony's for-next
>>> branch cannot support a single kernel for OMAP2/3/4. I tried to compile it but
>>> building failed. I just built for ARCH_OMAP4, the kernel can boots and serial
>>> port works fine. Hope we can fix this single kernel issue in the future.
>> That sounds like a bug in the for-next branch. I just compiled the tip of
>> linux-omap (Tony's tree) with omap3_defconfig and it compiled fine. On
>> looking at the for-next error I realised it was fixed in master. (So
>> eventually Tony will put it into for-next as well)
> I realized that I am trying omap_4430sdp_defconfig instead of omap3_defconfig.
> If I enabled ARCH_OMAP3 + omap_4430sdp_defconfig, building will fail due some
> assemble code undefined error.
>>> So I'm afraid that we can't simply enable OMAP4 in our master branch omap
>>> flavor, since our omap flavor is for OMAP3. In the future, after all the OMAP4
>>> stuff are merged into mainline, we can remove ti-omap4 topic branch but still
>>> need an additional armel flavor - omap4 in master branch.
>> No, this is all wrong!
>> Cherry-picking c040fd888b448a227c14e686eb67c09b625f75ac from the master
>> branch to for-next fixes the compile of an omap2/3/4 kernel.
> OK, I found omap3_defconfig enabled all OMAP2/3/4 and after cherry-picking
> c040fd888b448a227c14e686eb67c09b625f75ac, building omap2/3/4 kernel works fine.
>> Could you please try adding b970ecd55364ba3be1b6a500bf16abda3c8ec7e2 to our
>> maverick tree (master branch), compiling an -omap flavour and testing on your
>> panda?
> No problem, I will try to enable that soon. Since we can get a single kernel for
> omap2/3/4, one -omap flavor will be our goal.
> Thanks a lot,
> -Bryan

More information about the kernel-team mailing list