[PATCH] ramoops appears geared to not support ARM

[PATCH] ramoops appears geared to not support ARM

[Marco Stornelli]

(Added linux-arm)

Il 29/10/2011 01:21, Bryan Freed ha scritto:
> I had some difficulty in getting ramoops to work on our ARM systems.
> The driver maps memory with ioremap() which is supposed to map IO memory,
> not physical RAM.  This happens to work on x86 and apparently some other
> architectures, but it does not work on ARM.
> Specifically, I see this comment in __arm_ioremap_pfn_caller():
> 	Don't allow RAM to be mapped - this causes problems with ARMv6+
>
> So here is a patch that hacks around the issue using page_is_ram() to
> differentiate between the two.
>
> Am I missing something here?
> Is ramoops working on any ARM systems yet, and I am just doing something wrong?
>
> My ARM platform reserves a section of RAM for use by ramoops, but it is still
> mapped along with the rest of main memory.  This is so /dev/mem can find it
> with xlate_dev_mem_ptr().
> On x86, I see our BIOS reserves the memory so that it is not counted as main
> memory, and it is not mapped until ramoops ioremaps it.
>
> Bryan Freed (1):
>    ramoops: Add support for ARM systems.
>
>   drivers/char/ramoops.c |   67 +++++++++++++++++++++++++++++++++++++----------
>   1 files changed, 52 insertions(+), 15 deletions(-)
>

Can some ARM guys give an opinion about that?

Thanks.

Marco

[PATCH] ramoops appears geared to not support ARM

[Russell King - ARM Linux]

On Sat, Oct 29, 2011 at 10:39:47AM +0200, Marco Stornelli wrote:
> (Added linux-arm)
>
> Il 29/10/2011 01:21, Bryan Freed ha scritto:
>> I had some difficulty in getting ramoops to work on our ARM systems.
>> The driver maps memory with ioremap() which is supposed to map IO memory,
>> not physical RAM.  This happens to work on x86 and apparently some other
>> architectures, but it does not work on ARM.
>> Specifically, I see this comment in __arm_ioremap_pfn_caller():
>> 	Don't allow RAM to be mapped - this causes problems with ARMv6+
>>
>> So here is a patch that hacks around the issue using page_is_ram() to
>> differentiate between the two.
>>
>> Am I missing something here?
>> Is ramoops working on any ARM systems yet, and I am just doing something wrong?
>>
>> My ARM platform reserves a section of RAM for use by ramoops, but it is still
>> mapped along with the rest of main memory.  This is so /dev/mem can find it
>> with xlate_dev_mem_ptr().
>> On x86, I see our BIOS reserves the memory so that it is not counted as main
>> memory, and it is not mapped until ramoops ioremaps it.
>>
>> Bryan Freed (1):
>>    ramoops: Add support for ARM systems.
>>
>>   drivers/char/ramoops.c |   67 +++++++++++++++++++++++++++++++++++++----------
>>   1 files changed, 52 insertions(+), 15 deletions(-)
>>
>
> Can some ARM guys give an opinion about that?

Opinion about the patch which isn't present in this email (so we can't
see it) or about the commentry above?

[PATCH] ramoops appears geared to not support ARM

[Marco Stornelli]

Il 29/10/2011 11:34, Russell King - ARM Linux ha scritto:
> On Sat, Oct 29, 2011 at 10:39:47AM +0200, Marco Stornelli wrote:
>> (Added linux-arm)
>>
>> Il 29/10/2011 01:21, Bryan Freed ha scritto:
>>> I had some difficulty in getting ramoops to work on our ARM systems.
>>> The driver maps memory with ioremap() which is supposed to map IO memory,
>>> not physical RAM.  This happens to work on x86 and apparently some other
>>> architectures, but it does not work on ARM.
>>> Specifically, I see this comment in __arm_ioremap_pfn_caller():
>>> 	Don't allow RAM to be mapped - this causes problems with ARMv6+
>>>
>>> So here is a patch that hacks around the issue using page_is_ram() to
>>> differentiate between the two.
>>>
>>> Am I missing something here?
>>> Is ramoops working on any ARM systems yet, and I am just doing something wrong?
>>>
>>> My ARM platform reserves a section of RAM for use by ramoops, but it is still
>>> mapped along with the rest of main memory.  This is so /dev/mem can find it
>>> with xlate_dev_mem_ptr().
>>> On x86, I see our BIOS reserves the memory so that it is not counted as main
>>> memory, and it is not mapped until ramoops ioremaps it.
>>>
>>> Bryan Freed (1):
>>>     ramoops: Add support for ARM systems.
>>>
>>>    drivers/char/ramoops.c |   67 +++++++++++++++++++++++++++++++++++++----------
>>>    1 files changed, 52 insertions(+), 15 deletions(-)
>>>
>>
>> Can some ARM guys give an opinion about that?
>
> Opinion about the patch which isn't present in this email (so we can't
> see it) or about the commentry above?
>

About the ioremap problem. It seems there is a problem on some ARM arch 
to use ioremap (ramoops driver) to remap a piece of RAM even if it's not 
used by kernel (reserved at boot with mem option, Bryan can you 
confirm?). It has been suggested by Bryan to use xlate_dev_mem_ptr(), 
but I'm not sure if the problem is how to reserve the memory on these 
ARM archs. I believe ioremap is a general way to do it, of course not 
using kernel already used by kernel, am I right? Or to be compliant with 
all archs (in this particular case with ARMv6+) we should use 
xlate_dev_mem_ptr()?

Marco

[PATCH] ramoops appears geared to not support ARM

[Russell King - ARM Linux]

On Sat, Oct 29, 2011 at 01:04:30PM +0200, Marco Stornelli wrote:
> About the ioremap problem. It seems there is a problem on some ARM arch  
> to use ioremap (ramoops driver) to remap a piece of RAM even if it's not  
> used by kernel (reserved at boot with mem option, Bryan can you  
> confirm?).

It's all very simple.

We have three major 'memory types' - 'normal memory' which must be used
for things like RAM that we execute code from and use atomic operations
within.  This can be prefetched and reordered at will.

'device memory' is for devices, which tighter restrictions on reordering
and guarantees concerning reads and writes.

'strongly ordered memory' is much like device memory.

It is absolutely not permitted to map the same physical addresses with
different types - this is a stronger requirement than getting the cache
attributes the same.

System memory is mapped using 'normal memory' - obviously because we need
to be able to execute code and have working atomic operations throughout
kernel memory.

Now, ioremap creates device memory - because its main function is to
dynamically map memory regions in devices.

Now think: if we have system memory mapped as 'normal memory', and then
we try to use ioremap() to remap some of that memory, that will create
a new 'device memory' mapping with the existing 'normal memory' mapping
still present.  Now look at the paragraph 'It is absolutely not permitted'
and realise that the requirements for the architecture are being violated
if we permitted this to occur.

Also realise that if that condition is violated, 'unpredictable behaviour'
will occur - not to the extent that the CPU will hang, but it could cause
data errors which could influence overall system stability.

So, the whole idea of using plain ioremap() with system memory is one
that is just completely unsupportable on ARM without _first_ removing
memory from the system mapping, which in turn means updating the page
tables for every task in the system.

[PATCH] ramoops appears geared to not support ARM

[Marco Stornelli]

Il 29/10/2011 13:55, Russell King - ARM Linux ha scritto:
> On Sat, Oct 29, 2011 at 01:04:30PM +0200, Marco Stornelli wrote:
>> About the ioremap problem. It seems there is a problem on some ARM arch
>> to use ioremap (ramoops driver) to remap a piece of RAM even if it's not
>> used by kernel (reserved at boot with mem option, Bryan can you
>> confirm?).
>
> It's all very simple.
>
> We have three major 'memory types' - 'normal memory' which must be used
> for things like RAM that we execute code from and use atomic operations
> within.  This can be prefetched and reordered at will.
>
> 'device memory' is for devices, which tighter restrictions on reordering
> and guarantees concerning reads and writes.
>
> 'strongly ordered memory' is much like device memory.
>
> It is absolutely not permitted to map the same physical addresses with
> different types - this is a stronger requirement than getting the cache
> attributes the same.
>
> System memory is mapped using 'normal memory' - obviously because we need
> to be able to execute code and have working atomic operations throughout
> kernel memory.
>
> Now, ioremap creates device memory - because its main function is to
> dynamically map memory regions in devices.
>
> Now think: if we have system memory mapped as 'normal memory', and then
> we try to use ioremap() to remap some of that memory, that will create
> a new 'device memory' mapping with the existing 'normal memory' mapping
> still present.  Now look at the paragraph 'It is absolutely not permitted'
> and realise that the requirements for the architecture are being violated
> if we permitted this to occur.
>
> Also realise that if that condition is violated, 'unpredictable behaviour'
> will occur - not to the extent that the CPU will hang, but it could cause
> data errors which could influence overall system stability.
>
> So, the whole idea of using plain ioremap() with system memory is one
> that is just completely unsupportable on ARM without _first_ removing
> memory from the system mapping, which in turn means updating the page
> tables for every task in the system.
>

Ok, I understand, but other question: isn't there any way to reserve 
normal memory? Or at least, hasn't the mem kernel option any effect from 
that point of view?

[PATCH] ramoops appears geared to not support ARM

[Russell King - ARM Linux]

On Sat, Oct 29, 2011 at 02:42:42PM +0200, Marco Stornelli wrote:
> Ok, I understand, but other question: isn't there any way to reserve  
> normal memory? Or at least, hasn't the mem kernel option any effect from  
> that point of view?

mem= can be used to redefine the available memory to the kernel, but
then you have to have some way to define a region of the memory you've
excluded to the kernel to use for ramoops.

A platform can also use the memblock stuff to extract some memory
dynamically from the information passed from the firmware - by using
memblock_alloc + memblock_remove + memblock_free.  The memblock_remove
call will take the memory out of the available memory to the kernel,
and thus will prevent it being mapped.

This must be done via the ->reserve callback in the ARM board/SoC
record (it can't be done later because the memory will have already
been mapped.)