public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Bertrand BAUDET <bbaudet@lacie.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] mpc5200 relocation problem
Date: Fri, 7 Jan 2005 12:03:38 +0000	[thread overview]
Message-ID: <200501071203.38268.bbaudet@lacie.com> (raw)
In-Reply-To: <7cc0170405010702323cf9f0bf@mail.gmail.com>

I don't know if it's related, but I had an issue with the u-boot-1.1.1 when 
using 32MB SDRAM with a MPC5200.

In the initdram function in icecube.c, the sdram_start is properly set to 0
after detection 32MB for CS0. 
But when trying to detect mem with CS1, and if there is no mem, the 
sdram_start is set to 1 and then improperly set the high_bit to 1 in the 
MPC5XXX_SDRAM_CTRL register.

        /* find RAM size using SDRAM CS1 only */
        sdram_start(0);
        test1 = get_ram_size((ulong *)(CFG_SDRAM_BASE + dramsize), 
0x80000000);
        sdram_start(1);
        test2 = get_ram_size((ulong *)(CFG_SDRAM_BASE + dramsize), 
0x80000000);
        if (test1 > test2) {
                sdram_start(0);
                dramsize2 = test1;
        } else {
                dramsize2 = test2;
        }

if no mem, test1==test2 and then sdram_start(1) is kept set.
Or the previous test for CS0, which properly detected 32MB,
set up sdram_start(0) correctly.

I haven't had time to figure a clean fix, so I did a dirty hack:

       // FIXME
        if( dramsize==(32*1024*1024) ) {
                sdram_start(0);
        } else if( dramsize==(64*1024*1024) ) {
                sdram_start(1);
        }
printf("SDRAM_CTRL=0x%x\n",*(vu_long *)MPC5XXX_SDRAM_CTRL);


Bertrand


Le Vendredi 07 Janvier 2005 10:32, Giorgio Delmondo a ?crit?:
> Hi,
> I designed an MPC5200 with 256MB RAM (4 x 512Mb chips; MT48LC32M16A2,
> 8x16bitx4banks). When I force U-boot to just use the first 128 MB,
> everything  is ok (I force the return value from the routine exploring
> the RAM size).
> If I try to use the full 256 MB it crashes in the relocation phase
> (not always at the same point). I'm quite sure the RAM is working, as
> a test RAM program, residing in the low RAM and testing the full
> memory from 0x08000000 to 0x0fffffff, always gives result ok (it's
> started from U-boot running in low memory).
> I'm using u-boot 1.1.1
>
> Any suggestion?
>
> Many thanks
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

      parent reply	other threads:[~2005-01-07 12:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-07 10:32 [U-Boot-Users] mpc5200 relocation problem Giorgio Delmondo
2005-01-07 10:51 ` Jón Benediktsson
2005-01-07 12:03 ` Bertrand BAUDET [this message]

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=200501071203.38268.bbaudet@lacie.com \
    --to=bbaudet@lacie.com \
    --cc=u-boot@lists.denx.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