From: "Alexander Shiyan" <shc_work@mail.ru>
To: "Sascha Hauer" <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org,
"Maxime Ripard" <maxime.ripard@free-electrons.com>
Subject: Re[2]: [PATCH] Add warning above get_ram_size
Date: Sat, 16 Feb 2013 12:45:02 +0400 [thread overview]
Message-ID: <1361004302.346818455@f242.mail.ru> (raw)
In-Reply-To: <20130214191321.GY1906@pengutronix.de>
...
> > >>> --- 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?
>
> See include/asm-generic/sections.h. You have to avoid modifying
> everything between _text and __bss_stop. I haven't looked how exactly
> get_dram_size works. Normally this function would have to test every
> location at a power of 2, that would be:
>
> 1 2 4 ... 64MiB 128MiB
>
> It seems you have to make sure that your binary does not cross a power
> of 2 boundary, then you should be safe.
Let's put "get_ram_size" function in a separate section inside .text. Then we
can at least make runtime warning about placing this section inside our
tested region.
---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2013-02-16 8:45 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
2013-02-14 19:13 ` Sascha Hauer
2013-02-16 8:45 ` Alexander Shiyan [this message]
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=1361004302.346818455@f242.mail.ru \
--to=shc_work@mail.ru \
--cc=barebox@lists.infradead.org \
--cc=maxime.ripard@free-electrons.com \
--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.