Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof

[Sascha Hauer <s.hauer@pengutronix.de>]

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