From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Juergen Beisert <jbe@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 1/2] memsize: Make get_ram_size RAM proof
Date: Thu, 07 Mar 2013 15:26:53 +0100 [thread overview]
Message-ID: <5138A3AD.30403@free-electrons.com> (raw)
In-Reply-To: <201303071510.39114.jbe@pengutronix.de>
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
next prev parent reply other threads:[~2013-03-07 14:26 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
2013-03-07 14:26 ` Maxime Ripard [this message]
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=5138A3AD.30403@free-electrons.com \
--to=maxime.ripard@free-electrons.com \
--cc=barebox@lists.infradead.org \
--cc=jbe@pengutronix.de \
/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