mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Juergen Beisert <jbe@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof
Date: Thu, 7 Mar 2013 15:10:38 +0100	[thread overview]
Message-ID: <201303071510.39114.jbe@pengutronix.de> (raw)
In-Reply-To: <51389BAF.9040802@free-electrons.com>

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

  reply	other threads:[~2013-03-07 14:12 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
2013-03-07 13:52     ` Maxime Ripard
2013-03-07 14:10       ` Juergen Beisert [this message]
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=201303071510.39114.jbe@pengutronix.de \
    --to=jbe@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