All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] Add warning above get_ram_size
Date: Thu, 14 Feb 2013 14:59:48 +0100	[thread overview]
Message-ID: <511CEDD4.3020108@free-electrons.com> (raw)
In-Reply-To: <20130214113503.GN1906@pengutronix.de>

Hi Sascha,

Le 14/02/2013 12:35, Sascha Hauer a écrit :
> On Thu, Feb 14, 2013 at 10:40:38AM +0100, Maxime Ripard wrote:
>> Hi Sascha,
>>
>> Le 13/02/2013 18:16, Sascha Hauer a écrit :
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>> ---
>>>  common/memsize.c |    3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/common/memsize.c b/common/memsize.c
>>> index d149e41..ef6381b 100644
>>> --- a/common/memsize.c
>>> +++ b/common/memsize.c
>>> @@ -33,6 +33,9 @@
>>>   * Check memory range for valid RAM. A simple memory test determines
>>>   * the actually available RAM size between addresses `base' and
>>>   * `base + maxsize'.
>>> + *
>>> + * This function modifies the RAM. Do not use it if you're running from
>>> + * the RAM you are going to detect!
>>>   */
>>
>> Actually, I don't see how it modifies the RAM, at least permanently. The
>> values it erase are backed up, and there's no concurrency at barebox
>> level, so we are sure that the value saved will still be the one that
>> would need to be backed up at the end of the function, right?
> 
> Yes, it restores the values, but how do you make sure the function does
> not modify the instructions you are currently executing? You need bad
> luck to hit this, but sooner or later this will happen.

Ah, yes, this would be nasty indeed. Is there a way to know the end
address of barebox into RAM ? or the address it has been loaded to and
the size of its binary, so that we can just check the part that doesn't
hold barebox?

Maxime

-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2013-02-14 14:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-13 16:50 [PATCH] cfa10036: Retrieve the RAM size at runtime Maxime Ripard
2013-02-13 17:09 ` Jean-Christophe PLAGNIOL-VILLARD
2013-02-14  9:42   ` Maxime Ripard
2013-02-13 17:16 ` [PATCH] Add warning above get_ram_size Sascha Hauer
2013-02-14  9:40   ` Maxime Ripard
2013-02-14 11:35     ` Sascha Hauer
2013-02-14 13:59       ` Maxime Ripard [this message]
2013-02-14 19:13         ` Sascha Hauer
2013-02-16  8:45           ` Re[2]: " Alexander Shiyan
2013-02-16 15:53             ` Jean-Christophe PLAGNIOL-VILLARD

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=511CEDD4.3020108@free-electrons.com \
    --to=maxime.ripard@free-electrons.com \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    /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.