On Sun, Oct 30, 2011 at 4:33 AM, Marco Stornelli
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
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
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
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_