* [PATCHv2 0/2] cfa10036: Retrieve RAM size at runtime
@ 2013-02-26 16:55 Maxime Ripard
2013-02-26 16:55 ` [PATCH 1/2] memsize: Make get_ram_size RAM proof Maxime Ripard
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Maxime Ripard @ 2013-02-26 16:55 UTC (permalink / raw)
To: barebox
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
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH 1/2] memsize: Make get_ram_size RAM proof 2013-02-26 16:55 [PATCHv2 0/2] cfa10036: Retrieve RAM size at runtime Maxime Ripard @ 2013-02-26 16:55 ` Maxime Ripard 2013-03-04 8:02 ` Sascha Hauer 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 2 siblings, 1 reply; 8+ messages in thread From: Maxime Ripard @ 2013-02-26 16:55 UTC (permalink / raw) To: barebox 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof 2013-02-26 16:55 ` [PATCH 1/2] memsize: Make get_ram_size RAM proof Maxime Ripard @ 2013-03-04 8:02 ` Sascha Hauer 2013-03-07 13:52 ` Maxime Ripard 0 siblings, 1 reply; 8+ messages in thread From: Sascha Hauer @ 2013-03-04 8:02 UTC (permalink / raw) To: Maxime Ripard; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof 2013-03-04 8:02 ` Sascha Hauer @ 2013-03-07 13:52 ` Maxime Ripard 2013-03-07 14:10 ` Juergen Beisert 0 siblings, 1 reply; 8+ messages in thread From: Maxime Ripard @ 2013-03-07 13:52 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof 2013-03-07 13:52 ` Maxime Ripard @ 2013-03-07 14:10 ` Juergen Beisert 2013-03-07 14:26 ` Maxime Ripard 0 siblings, 1 reply; 8+ messages in thread From: Juergen Beisert @ 2013-03-07 14:10 UTC (permalink / raw) To: barebox; +Cc: Maxime Ripard 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof 2013-03-07 14:10 ` Juergen Beisert @ 2013-03-07 14:26 ` Maxime Ripard 0 siblings, 0 replies; 8+ messages in thread From: Maxime Ripard @ 2013-03-07 14:26 UTC (permalink / raw) To: Juergen Beisert; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] cfa10036: Retrieve the RAM size at runtime 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-02-26 16:55 ` Maxime Ripard 2013-02-27 8:03 ` [PATCHv2 0/2] cfa10036: Retrieve " Sascha Hauer 2 siblings, 0 replies; 8+ messages in thread From: Maxime Ripard @ 2013-02-26 16:55 UTC (permalink / raw) To: barebox 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCHv2 0/2] cfa10036: Retrieve RAM size at runtime 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-02-26 16:55 ` [PATCH 2/2] cfa10036: Retrieve the RAM size at runtime Maxime Ripard @ 2013-02-27 8:03 ` Sascha Hauer 2 siblings, 0 replies; 8+ messages in thread From: Sascha Hauer @ 2013-02-27 8:03 UTC (permalink / raw) To: Maxime Ripard; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-03-07 14:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox