[PATCHv2 0/2] cfa10036: Retrieve RAM size at runtime

[PATCHv2 0/2] cfa10036: Retrieve RAM size at runtime

[Maxime Ripard]

Hi,

This patch series makes the cfa10036 retrieve its ram size at runtime.
Since the get_ram_size function was not safe to use when running from RAM,
we had to introduce a first patch that makes the execution of this function
from RAM safe.

Thanks,
Maxime

Maxime Ripard (2):
  memsize: Make get_ram_size RAM proof
  cfa10036: Retrieve the RAM size at runtime

 arch/arm/boards/crystalfontz-cfa10036/cfa10036.c |    3 ++-
 common/memsize.c                                 |   21 +++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)

-- 
1.7.10.4


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

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

[Maxime Ripard]

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;
+
 		sync ();
 		save[i++] = *addr;
 		sync ();
@@ -65,6 +77,9 @@ long get_ram_size(volatile long *base, long maxsize)
 		*addr = save[i];
 		for (cnt = 1; cnt < maxsize / sizeof(long); cnt <<= 1) {
 			addr  = base + cnt;
+			if (addr > (long*)_text && addr < (long*)__bss_stop)
+				continue;
+
 			sync ();
 			*addr = save[--i];
 		}
@@ -73,6 +88,9 @@ long get_ram_size(volatile long *base, long maxsize)
 
 	for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
 		addr = base + cnt;	/* pointer arith! */
+		if (addr > (long*)_text && addr < (long*)__bss_stop)
+			continue;
+
 		val = *addr;
 		*addr = save[--i];
 		if (val != ~cnt) {
@@ -81,6 +99,9 @@ long get_ram_size(volatile long *base, long maxsize)
 			 */
 			for (cnt <<= 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
 				addr  = base + cnt;
+				if (addr > (long*)_text && addr < (long*)__bss_stop)
+					continue;
+
 				*addr = save[--i];
 			}
 			return (size);
-- 
1.7.10.4


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

[PATCH 2/2] cfa10036: Retrieve the RAM size at runtime

[Maxime Ripard]

The cfa-10036 comes in two flavours, with either 128MB or 256MB of RAM
on it.

Since it's not stored anywhere, we need to runtime detect it, thanks to
the get_ram_size function.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boards/crystalfontz-cfa10036/cfa10036.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boards/crystalfontz-cfa10036/cfa10036.c b/arch/arm/boards/crystalfontz-cfa10036/cfa10036.c
index 1bc20cf..a112bf1 100644
--- a/arch/arm/boards/crystalfontz-cfa10036/cfa10036.c
+++ b/arch/arm/boards/crystalfontz-cfa10036/cfa10036.c
@@ -92,7 +92,8 @@ static struct i2c_gpio_platform_data i2c_gpio_pdata = {
 
 static int cfa10036_mem_init(void)
 {
-	arm_add_mem_device("ram0", IMX_MEMORY_BASE, 128 * 1024 * 1024);
+	arm_add_mem_device("ram0", IMX_MEMORY_BASE,
+			   get_ram_size((volatile long int *)IMX_MEMORY_BASE, SZ_256M));
 
 	return 0;
 }
-- 
1.7.10.4


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

Re: [PATCHv2 0/2] cfa10036: Retrieve RAM size at runtime

[Sascha Hauer]

On Tue, Feb 26, 2013 at 05:55:40PM +0100, Maxime Ripard wrote:
> Hi,
> 
> This patch series makes the cfa10036 retrieve its ram size at runtime.
> Since the get_ram_size function was not safe to use when running from RAM,
> we had to introduce a first patch that makes the execution of this function
> from RAM safe.

Applied, thanks

Sascha

> 
> Thanks,
> Maxime
> 
> Maxime Ripard (2):
>   memsize: Make get_ram_size RAM proof
>   cfa10036: Retrieve the RAM size at runtime
> 
>  arch/arm/boards/crystalfontz-cfa10036/cfa10036.c |    3 ++-
>  common/memsize.c                                 |   21 +++++++++++++++++++++
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
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

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

[Sascha Hauer]

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

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

[Maxime Ripard]

Hi Sascha,

Le 04/03/2013 09:02, Sascha Hauer a écrit :
> 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.

I agree that this patch you're mentionning would be the best solution.

However, the imx28 SDRAM controller doesn't seem to be able to be
reconfigured, so once it has been configured once, you're screwed.

So our first stage bootloader enables all the 256MB of RAM, and then we
have to test it, like this patch did.

If you're fine with having a stripped down get_ram_size function only
for the cfa10036, I'll do that, but I'm open to suggestions if you have
other ideas.

Thanks,
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

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

[Juergen Beisert]

Hi Maxime,

Maxime Ripard wrote:
> > [....]
> >
> > 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.
>
> I agree that this patch you're mentionning would be the best solution.
>
> However, the imx28 SDRAM controller doesn't seem to be able to be
> reconfigured, so once it has been configured once, you're screwed.

You have to do this test in the bootlets instead. As they run from the 
internal SRAM, you can do whatever you want with the SDRAM controller.

jbe

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

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

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

[Maxime Ripard]

Hi Juergen,

Le 07/03/2013 15:10, Juergen Beisert a écrit :
> Maxime Ripard wrote:
>>> [....]
>>>
>>> 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.
>>
>> I agree that this patch you're mentionning would be the best solution.
>>
>> However, the imx28 SDRAM controller doesn't seem to be able to be
>> reconfigured, so once it has been configured once, you're screwed.
> 
> You have to do this test in the bootlets instead. As they run from the 
> internal SRAM, you can do whatever you want with the SDRAM controller.

Yes, I know, but I haven't found a way to reconfigure the SDRAM
controller to use a smaller memory size once it has been started (any
attempts to do so failed miserably), and it doesn't seem to have any way
to reset it either, but maybe I'm missing something.

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