mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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

  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