Re: [PATCH] ramoops appears geared to not support ARM

From: Marco Stornelli
Date: Mon Oct 31 2011 - 05:03:49 EST

Il 31/10/2011 07:03, Bryan Freed ha scritto:
On Sun, Oct 30, 2011 at 4:33 AM, Marco Stornelli
<marco.stornelli@xxxxxxxxx> 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.


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.

I don't understand this point. We have different virtual addresses and then? The linear transformation with a fixed offset is the normal way for the kernel to have a virtual address from a physical one when you are using a memory address directly mapped. The virtual address returned by ioremap it can be an address not directly mapped, I mean it isn't a simple linear transformation of the physical address used in input.
It isn't normal to have a kernel panic, even if there is something wrong, you should receive EINVAL or something similar.

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

It's an arch problem not related to the driver.

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_

no mmap calls?! I don't understand how you are using /dev/mem.

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