[lkml]   [2007]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
    On Thu 3 May 2007 07:03, Greg Ungerer pondered:
    > Robin Getz wrote:
    > > On Wed 2 May 2007 07:32, Greg Ungerer pondered:
    > >> Robin Getz wrote:
    > >>> I was trying to understand why we don't want to do the same checking on
    > >>> noMMU?
    > >>
    > >> The problem is on systems that have RAM mapped at high physical
    > >> addresses. TASK_SIZE may well be a numerically smaller number
    > >> than the address range that RAM sits in. So this test fails when
    > >> it shouldn't.
    > >
    > > So, then this is a problem only on one or two architectures, not all
    > > noMMU platforms?
    > Its not an architecture problem. It can effect any board that
    > has RAM mapped at a large numerical addresses (larger than TASK_SIZE).
    > So it can effect any non-MMU platform.

    Depending on how TASK_SIZE is defined - it looks like everyone else forces it
    to end of memory, except 68k[nommu].

    asm-arm/memory.h:#define TASK_SIZE (CONFIG_DRAM_SIZE)
    asm-blackfin/processor.h:#define TASK_SIZE (memory_end)
    asm-frv/mem-layout.h:#define TASK_SIZE __UL(0xFFFFFFFFUL)

    asm-m68k/processor.h:#define TASK_SIZE (0xF0000000UL)
    asm-m68k/processor.h:#define TASK_SIZE (0x0E000000)
    asm-m68k/processor.h:#define TASK_SIZE (0x0E000000UL)
    asm-m68knommu/processor.h:#define TASK_SIZE (0xF0000000UL)

    I'm happy to learn we are doing something wrong, but I think that we just
    copied the arm/frv setup.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-03 13:35    [W:0.037 / U:16.380 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site