[Maverick] [ti-omap4] SRU: A workaround for highmem issue on OMAP4 platform

[Dechesne, Nicolas]

Bryan, Ricardo,

before 'acking' this patch, we will need to run OMAP4 video use cases too. As you know OMAP4 has a custom coprocessor for video encode/decode which is sharing memory with the main core running Linux. We never tested the 2G/2G split for video use cases, and I cannot claim whether it's safe or not without doing more testing.

For sure building the kernel is a good testcase, but we need video use cases to be functional too.

nicolas


> On Fri, Sep 24, 2010 at 3:50 PM, Tim Gardner<tim.gardner at canonical.com>  wrote:
>> On 09/24/2010 11:21 AM, Bryan Wu wrote:
>>>
>>> SRU Justification:
>>>
>>> Impact:
>>> There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When
>>> we
>>> build kernel package natively on ES2.0 platform with mem=1G and highmem
>>> enabled, we will meet 'Bus Error' corruption from gcc shortly. And
>>> 'Unhandled
>>> imprecised external abort' kernel oops messages. Then the whole system
>>> will be
>>> very instable.
>>>
>>> Fix: After some debugging, this issue is related to highmem. If we don't
>>> use
>>> mem=1G (no memory in highmem), the corruption is gone. So there is a
>>> workaround
>>> which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G
>>> instead
>>> of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
>>> memory in highmem. As a result, the issue is gone.
>>>
>>> Testcase: Add kernel boot command line mem=1G, build kernel package on
>>> ES2.0
>>> hardware after booting the kernel. The issue is supposed to be gone with
>>> 2G:2G
>>> split config.
>>>
>>> A testing kernel is also here:
>>> http://people.canonical.com/~roc/kernel/lp633227/
>>>
>>> Notes: the VMALLOC_END value is wrong in mach-omap2, Nicolas Pitre posted
>>> a fixing
>>> patch to upstream, which is required in this workaround.
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/#633227
>>>
>>> Plese consider pull from
>>>   git://kernel.ubuntu.com/roc/ubuntu-maverick lp633227
>>>
>>> Bryan Wu (1):
>>>    UBUNTU: [Config] Enable CONFIG_VMSPLIT_2G=y for OMAP4
>>>
>>> Nicolas Pitre (1):
>>>    ARM: do not define VMALLOC_END relative to PAGE_OFFSET
>>>
>>>   arch/arm/mach-aaec2000/include/mach/vmalloc.h   |    2 +-
>>>   arch/arm/mach-bcmring/include/mach/vmalloc.h    |    2 +-
>>>   arch/arm/mach-clps711x/include/mach/vmalloc.h   |    2 +-
>>>   arch/arm/mach-ebsa110/include/mach/vmalloc.h    |    2 +-
>>>   arch/arm/mach-footbridge/include/mach/vmalloc.h |    2 +-
>>>   arch/arm/mach-h720x/include/mach/vmalloc.h      |    2 +-
>>>   arch/arm/mach-integrator/include/mach/vmalloc.h |    2 +-
>>>   arch/arm/mach-msm/include/mach/vmalloc.h        |    2 +-
>>>   arch/arm/mach-netx/include/mach/vmalloc.h       |    2 +-
>>>   arch/arm/mach-omap1/include/mach/vmalloc.h      |    2 +-
>>>   arch/arm/mach-omap2/include/mach/vmalloc.h      |    2 +-
>>>   arch/arm/mach-pnx4008/include/mach/vmalloc.h    |    2 +-
>>>   arch/arm/mach-rpc/include/mach/vmalloc.h        |    2 +-
>>>   arch/arm/mach-shark/include/mach/vmalloc.h      |    2 +-
>>>   arch/arm/mach-versatile/include/mach/vmalloc.h  |    2 +-
>>>   debian.ti-omap4/config/config.common.ubuntu     |    6 +++---
>>>   16 files changed, 18 insertions(+), 18 deletions(-)
>>>
>>
>> So, what do you want me to do? Ricardo is saying this workaround is not
>> sufficient.
>>
>
> Please ignore this pull request. We are working on it.
>
> Thanks,