Messages in this thread | | | Date | Mon, 31 Oct 2011 09:57:46 +0100 | From | Marco Stornelli <> | Subject | Re: [PATCH] ramoops appears geared to not support ARM |
| |
Il 31/10/2011 07:03, Bryan Freed ha scritto: > On Sun, Oct 30, 2011 at 4:33 AM, Marco Stornelli > <marco.stornelli@gmail.com> 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.
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 > boundary. >
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.
Marco
| |