[lkml]   [2011]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] ramoops appears geared to not support ARM
    On Sun, Oct 30, 2011 at 4:33 AM, Marco Stornelli
    <> wrote:
    > Il 30/10/2011 03:07, Bryan Freed ha scritto:
    >> Right, and that is what I do to get ARM working.  The reserve() function
    >> calls memblock_reserve() to reserve the memory for RAMOOPS.  Keeping it
    >> part of main memory (by not using memblock_remove()) gets the memory
    >> properly mapped.
    > According to Russell, it needs to use memblock_remove to exclude that piece of memory.
    >> The problem I think we need to resolve is that this makes the ramoops
    >> driver messy.
    > I agree. Indeed I think we don't need to do anything in the driver. The problem is only how to exclude a piece of memory from kernel main memory view. For x86 it's trivial, for ARM it doesn't, but it's still possible.
    > Marco

    I will give that (using mem_remove()) a shot tomorrow.
    My recollection on using it in last week's investigation showed the
    ramoops driver ioremap() giving a mapping that did not correspond with
    what the /dev/mem expected to see.  I vaguely recall /dev/mem was
    effectively calling __va(0x02000000) which added a base address of
    0xc0000000 giving 0xc2000000 as the resulting virtual address.  The
    ramoops ioremap(), however, gave some arbitrary virtual address for
    this memory.
    The result was that using /dev/mem to read 0x02000000 caused a panic.

    Another problem was that removing just 512KiB of memory for ramoops
    screwed up the system memory initialization.  It appeared to me that
    the ARM memory code expected sections to be 1MiB aligned. I could
    memblock_reserve anything, but I could only memblock_remove on a 1MiB

    And I cannot shake the feeling that we have a fairly simple disconnect
    here.  Ramoops expects to use _device_ memory because it uses
    ioremap().  But the buffer itself is accessed through /dev/mem which
    (as we use it with no mmap() calls) expects to give access to _system_
    It seems this disconnect could be removed if we provided a
    /sys/class/ramoops/buffer file that an application could read instead
    of having to rely on /dev/mem.

    Marco, what is your opinion on that?

    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: 2011-10-31 07:11    [W:0.023 / U:2.996 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site