Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof
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.rip...@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
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
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
Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof
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.rip...@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- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 1/2] memsize: Make get_ram_size RAM proof
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.rip...@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
