From: Sascha Hauer <s.hauer@pengutronix.de>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof
Date: Mon, 4 Mar 2013 09:02:32 +0100 [thread overview]
Message-ID: <20130304080232.GM25672@pengutronix.de> (raw)
In-Reply-To: <1361897742-3454-2-git-send-email-maxime.ripard@free-electrons.com>
On Tue, Feb 26, 2013 at 05:55:41PM +0100, Maxime Ripard wrote:
> get_ram_size cannot be used when running from RAM at the moment, even
> though it backs up the memory cells it modifies, since it can also
> modify the get_ram_size function itself.
>
> Avoid testing the memory area where barebox is loaded at to prevent this
> problem. If the memory supposed to host barebox is not working, we'll
> have plenty of other problems anyway.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> common/memsize.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/common/memsize.c b/common/memsize.c
> index d149e41..1d00984 100644
> --- a/common/memsize.c
> +++ b/common/memsize.c
> @@ -19,6 +19,9 @@
>
> #include <common.h>
> #include <config.h>
> +
> +#include <asm-generic/sections.h>
> +
> #if defined (__PPC__) && !defined (__SANDBOX__)
> /*
> * At least on G2 PowerPC cores, sequential accesses to non-existent
> @@ -45,6 +48,15 @@ long get_ram_size(volatile long *base, long maxsize)
>
> for (cnt = (maxsize / sizeof (long)) >> 1; cnt > 0; cnt >>= 1) {
> addr = base + cnt; /* pointer arith! */
> +
> + /*
> + * If we run get_ram_size from RAM, avoid poking into
> + * the Barebox code, and if the RAM at these address
> + * doesn't work, we will have trouble anyway...
> + */
> + if (addr > (long*)_text && addr < (long*)__bss_stop)
> + continue;
Unfortunately I had to drop this one. It breaks compilation on some
architectures which do not have _text and __bss_stop (namely blackfin
and another one I forgot about).
Anyway, I realized that we now can start the MMU during early startup,
so when you call this function from your board code your SDRAM might
already be cached. I assume get_ram_size won't work reliably in this
case anymore.
Since you only use it to detect whether you have 128MiB or 256Mib, could
you code a stripped down version of this function especially for your
board? Could you even adjust the SDRAM controller registers to the size
you really have? I have no idea if the SDRAM controller can cope with
that, but it might be worth giving it a try. I have a patch in the
queue moving the i.MX28 over to dynamically detecting the SDRAM size
via controller readback, so this then would simply detect the correct
size.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2013-03-04 8:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-26 16:55 [PATCHv2 0/2] cfa10036: Retrieve RAM size at runtime Maxime Ripard
2013-02-26 16:55 ` [PATCH 1/2] memsize: Make get_ram_size RAM proof Maxime Ripard
2013-03-04 8:02 ` Sascha Hauer [this message]
2013-03-07 13:52 ` Maxime Ripard
2013-03-07 14:10 ` Juergen Beisert
2013-03-07 14:26 ` Maxime Ripard
2013-02-26 16:55 ` [PATCH 2/2] cfa10036: Retrieve the RAM size at runtime Maxime Ripard
2013-02-27 8:03 ` [PATCHv2 0/2] cfa10036: Retrieve " Sascha Hauer
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=20130304080232.GM25672@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=maxime.ripard@free-electrons.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox