All of lore.kernel.org
 help / color / mirror / Atom feed
From: marco.stornelli@gmail.com (Marco Stornelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ramoops appears geared to not support ARM
Date: Sat, 29 Oct 2011 13:04:30 +0200	[thread overview]
Message-ID: <4EABDDBE.5080407@gmail.com> (raw)
In-Reply-To: <20111029093458.GX19187@n2100.arm.linux.org.uk>



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

WARNING: multiple messages have this Message-ID (diff)
From: Marco Stornelli <marco.stornelli@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org, msb@chromium.org,
	linux-kernel@vger.kernel.org, sergiu@chromium.org,
	Bryan Freed <bfreed@chromium.org>,
	akpm@linux-foundation.org, seiji.aguchi@hds.com
Subject: Re: [PATCH] ramoops appears geared to not support ARM
Date: Sat, 29 Oct 2011 13:04:30 +0200	[thread overview]
Message-ID: <4EABDDBE.5080407@gmail.com> (raw)
In-Reply-To: <20111029093458.GX19187@n2100.arm.linux.org.uk>



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

  reply	other threads:[~2011-10-29 11:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-28 23:21 [PATCH] ramoops appears geared to not support ARM Bryan Freed
2011-10-28 23:21 ` [PATCH] ramoops: Add support for ARM systems Bryan Freed
2011-10-29  8:39 ` [PATCH] ramoops appears geared to not support ARM Marco Stornelli
2011-10-29  8:39   ` Marco Stornelli
2011-10-29  9:34   ` Russell King - ARM Linux
2011-10-29  9:34     ` Russell King - ARM Linux
2011-10-29 11:04     ` Marco Stornelli [this message]
2011-10-29 11:04       ` Marco Stornelli
2011-10-29 11:55       ` Russell King - ARM Linux
2011-10-29 11:55         ` Russell King - ARM Linux
2011-10-29 12:42         ` Marco Stornelli
2011-10-29 12:42           ` Marco Stornelli
2011-10-29 12:53           ` Russell King - ARM Linux
2011-10-29 12:53             ` Russell King - ARM Linux
2011-10-29 14:22 ` Marco Stornelli
     [not found]   ` <CAEYUcX1PUgniJLqYXKM5pf_9T06OPFg4q0ZUCFc8Deu1J_R9-A@mail.gmail.com>
2011-10-30 11:33     ` Marco Stornelli
2011-10-31  6:03       ` Bryan Freed
2011-10-31  8:57         ` Marco Stornelli
2011-10-31 23:03           ` Bryan Freed
2011-11-01  8:52             ` Marco Stornelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EABDDBE.5080407@gmail.com \
    --to=marco.stornelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.