public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot-Users] mpc5200 relocation problem
@ 2005-01-07 10:32 Giorgio Delmondo
  2005-01-07 10:51 ` Jón Benediktsson
  2005-01-07 12:03 ` Bertrand BAUDET
  0 siblings, 2 replies; 3+ messages in thread
From: Giorgio Delmondo @ 2005-01-07 10:32 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot-Users] mpc5200 relocation problem
  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
  1 sibling, 0 replies; 3+ messages in thread
From: Jón Benediktsson @ 2005-01-07 10:51 UTC (permalink / raw)
  To: u-boot

u-boot-users-admin at lists.sourceforge.net wrote on 07.01.2005 10:32:42:

> 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
> 

Are you using one or two CS signals for your SDRAM ?

If you are using two CS signals, then perhaps you are seeing the effect of
MPC5200 errata ID 342, which says:
"There is problem when executing code from CS0 that writes data to CS1 of 
the SDRRAM,
and vice versa. As a result, exception 700 will be forced."

We had designed an MPC5200 board that used CS0 and CS1 for SDRAM.
Having read this we changed our board design to use just CS0 for SDRAM.
I was having a problem with getting u-boot to work with the upper half of 
the memory
space, but I never really found out the exact cause.  We simply decided 
that
we could not use two CS because of this errata.  After we changed to using 
just CS0,
we have experience no problems with this.

Regards,
Jon Benediktsson
Marel hf.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot-Users] mpc5200 relocation problem
  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
  1 sibling, 0 replies; 3+ messages in thread
From: Bertrand BAUDET @ 2005-01-07 12:03 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-01-07 12:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox