[U-Boot-Users] (no subject)

[U-Boot-Users] (no subject)

[Gerald Jackson]

I made the change that Marc suggested and still no luck. If both dimms
are in use the system hangs and if only the second Dimm slot is in use I
get:

U-Boot 1.1.4 (Sep 30 2006 - 10:08:43)

CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  ERROR: Cannot determine a common read delay.
### ERROR ### Please RESET the board ###
 

Any Ideals?

 Gerald

-----Original Message-----
From: Gerald Jackson 
Sent: Saturday, September 30, 2006 10:13 AM
To: Marc.Howard at KLA-Tencor.com; sr at denx.de;
u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] (no subject)


Here is the error I get if I use the second DIMMS

U-Boot 1.1.4 (Jul 18 2006 - 07:36:20)

CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  ERROR: Cannot determine a common read delay.
### ERROR ### Please RESET the board ###

Gerald
 
 
-----Original Message-----
From: Gerald Jackson 
Sent: Friday, September 29, 2006 6:16 PM
To: Marc.Howard at KLA-Tencor.com; sr at denx.de;
u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] (no subject)

Marc,

After you make that change you can use both dimms slot on the ocotea
board?

What error did you receive before the modification?

if I use only the second dimm slot with 256M it errors. if I use the
first dimm slot it is ok and if I use both dimms slot it error as well.


I am using 1.1.4.

Gerald

-----Original Message-----
From: "Howard, Marc"<Marc.Howard@KLA-Tencor.com>
Sent: 9/28/06 5:06:26 PM
To: "Stefan Roese"<sr@denx.de>,
"u-boot-users at lists.sourceforge.net"<u-boot-users@lists.sourceforge.net>
Subject: Re: [U-Boot-Users] (no subject)

Stefan,

Actually > 256MB won't work correctly.  There is a problem in
board/amcc/ocotea/init.S:

tlbtab:
    tlbtab_start
    tlbentry( 0xf0000000, SZ_256M, 0xf0000000, 1,
AC_R|AC_W|AC_X|SA_G|SA_I)
    tlbentry( CFG_PERIPHERAL_BASE, SZ_256M, 0x40000000, 1,
AC_R|AC_W|SA_G|SA_I)
    tlbentry( CFG_ISRAM_BASE, SZ_4K, 0x80000000, 0, AC_R|AC_W|AC_X )
    tlbentry( CFG_ISRAM_BASE + 0x1000, SZ_4K, 0x80001000, 0,
AC_R|AC_W|AC_X )
    tlbentry( CFG_SDRAM_BASE, SZ_256M, 0x00000000, 0,
AC_R|AC_W|AC_X|SA_G|SA_I )
    tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x00000000, 0,
AC_R|AC_W|AC_X|SA_G|SA_I )
    tlbentry( CFG_PCI_BASE, SZ_256M, 0x00000000, 2, AC_R|AC_W|SA_G|SA_I
)
    tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3,
AC_R|AC_W|SA_G|SA_I )
    tlbtab_en

The line:
 
tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x00000000, 0,
AC_R|AC_W|AC_X|SA_G|SA_I )

...should be...

tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x10000000, 0,
AC_R|AC_W|AC_X|SA_G|SA_I )
                                                ^
------------------------------------------------^

The way it currently stands virtual addresses 256-512MB are mapped into
the same region as the 1st 256MB of SDRAM.

Marc Howard


> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Stefan Roese
> Sent: Thursday, September 28, 2006 5:48 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] (no subject)
> 
> Hi Gerald,
> 
> On Thursday 28 September 2006 04:03, Gerald Jackson wrote:
> > Does anyone know why u-boot 1.1.4 fails if you use two dimms in the
> > Ocotea Amcc board?
> >
> > I have try two 256 dimm, two 512 dimm, and one 256 dimm in 
> the second
> > slot ( nothing in the first slot) it all fails.
> >
> > Is this a know problem with the Ocotea board?
> 
> No. IIRC, we have tested Ocotea with different DIMM modules. 
> Which U-Boot 
> version are you using? What DIMM modules are you using? And 
> what combination 
> _is_ working?
> 
> A quick look at the TLB setup shows me, that a maximum of 
> 512MBytes could be 
> working. For more at least the TLB setup has to be changed.
> 
> Best regards,
> Stefan
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys -- and 
> earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] (no subject)

[Stefan Roese]

Hi Gerald,

On Sunday 01 October 2006 05:04, Gerald Jackson wrote:
> I made the change that Marc suggested and still no luck. If both dimms
> are in use the system hangs

Hangs where? Also upon SDRAM initialization?

> and if only the second Dimm slot is in use I 
> get:
>
> U-Boot 1.1.4 (Sep 30 2006 - 10:08:43)
>
> CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
> MHz)
>        I2C boot EEPROM enabled
>        Internal PCI arbiter enabled
>        32 kB I-Cache 32 kB D-Cache
> Board: Ocotea - AMCC PPC440GX Evaluation Board
> I2C:   ready
> DRAM:  ERROR: Cannot determine a common read delay.
> ### ERROR ### Please RESET the board ###
>
> Any Ideals?

Ideals? Not really. But I have an idea! ;-)

How did you get the Board? Directly from AMCC? Did it never work at all?

Your PLB frequency seems strange to me (160MHz). Please try to configure your 
Ocotea to use a different setup, for example 533MHz CPU and 133MHz PLB. Here 
is the output from our Ocotea:

U-Boot 1.1.4-g887e2ec9-dirty (Sep  7 2006 - 11:55:16)

CPU:   AMCC PowerPC 440GX Rev. F at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
       I2C boot EEPROM enabled
       Bootstrap Option F - Boot ROM Location I2C (Addr 0x54)
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  256 MB
FLASH:  5 MB
PCI:   Bus Dev VenId DevId Class Int
        00  01  8086  107c  0200  00
In:    serial
Out:   serial
Err:   serial
Net:   ppc_4xx_eth0, ppc_4xx_eth1, ppc_4xx_eth2, ppc_4xx_eth3

Type "run flash_nfs" to mount root filesystem over NFS

Hit any key to stop autoboot:  0
=>   

Best regards,
Stefan

[U-Boot-Users] (no subject)

[Gerald Jackson]

Stefan,

Yes the board works and Pibs works with both Dimms slot in use.
The board came from AMCC and it is the latest board with the 800MHz
440GX chip on it.

The system hangs upon SDRAM initialization, but only with both dimms
slots used.

I didn't even know this problem exist until another company that is
writing a device driver for me told me that the second DIMMS slot
doesn't work on there board. Sure enough it doesn't work on mines
either.

Gerald

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Sunday, October 01, 2006 5:23 AM
To: u-boot-users at lists.sourceforge.net
Cc: Gerald Jackson; Marc.Howard at kla-tencor.com
Subject: Re: [U-Boot-Users] (no subject)

Hi Gerald,

On Sunday 01 October 2006 05:04, Gerald Jackson wrote:
> I made the change that Marc suggested and still no luck. If both dimms
> are in use the system hangs

Hangs where? Also upon SDRAM initialization?

> and if only the second Dimm slot is in use I 
> get:
>
> U-Boot 1.1.4 (Sep 30 2006 - 10:08:43)
>
> CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
> MHz)
>        I2C boot EEPROM enabled
>        Internal PCI arbiter enabled
>        32 kB I-Cache 32 kB D-Cache
> Board: Ocotea - AMCC PPC440GX Evaluation Board
> I2C:   ready
> DRAM:  ERROR: Cannot determine a common read delay.
> ### ERROR ### Please RESET the board ###
>
> Any Ideals?

Ideals? Not really. But I have an idea! ;-)

How did you get the Board? Directly from AMCC? Did it never work at all?

Your PLB frequency seems strange to me (160MHz). Please try to configure
your 
Ocotea to use a different setup, for example 533MHz CPU and 133MHz PLB.
Here 
is the output from our Ocotea:

U-Boot 1.1.4-g887e2ec9-dirty (Sep  7 2006 - 11:55:16)

CPU:   AMCC PowerPC 440GX Rev. F at 533.333 MHz (PLB=133, OPB=66, EBC=66
MHz)
       I2C boot EEPROM enabled
       Bootstrap Option F - Boot ROM Location I2C (Addr 0x54)
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  256 MB
FLASH:  5 MB
PCI:   Bus Dev VenId DevId Class Int
        00  01  8086  107c  0200  00
In:    serial
Out:   serial
Err:   serial
Net:   ppc_4xx_eth0, ppc_4xx_eth1, ppc_4xx_eth2, ppc_4xx_eth3

Type "run flash_nfs" to mount root filesystem over NFS

Hit any key to stop autoboot:  0
=>   

Best regards,
Stefan

[U-Boot-Users] (no subject)

[Gerald Jackson]

Stefan,

I look more into using both dimms issue and I see two interesting
things.

1. With two dimms it never get pass line 1478 - 1500 in spd_sdram.c.  It
loops once then hangs.

2. If I disable this part (ie break) I get the ERROR: Cannot determine a
common read delay. If I comment out the hang()  It returns but it only
calculated 768MB of memory.

Any sugguests?

Gerald

 
 

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Sunday, October 01, 2006 5:23 AM
To: u-boot-users at lists.sourceforge.net
Cc: Gerald Jackson; Marc.Howard at kla-tencor.com
Subject: Re: [U-Boot-Users] (no subject)

Hi Gerald,

On Sunday 01 October 2006 05:04, Gerald Jackson wrote:
> I made the change that Marc suggested and still no luck. If both dimms
> are in use the system hangs

Hangs where? Also upon SDRAM initialization?

> and if only the second Dimm slot is in use I 
> get:
>
> U-Boot 1.1.4 (Sep 30 2006 - 10:08:43)
>
> CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
> MHz)
>        I2C boot EEPROM enabled
>        Internal PCI arbiter enabled
>        32 kB I-Cache 32 kB D-Cache
> Board: Ocotea - AMCC PPC440GX Evaluation Board
> I2C:   ready
> DRAM:  ERROR: Cannot determine a common read delay.
> ### ERROR ### Please RESET the board ###
>
> Any Ideals?

Ideals? Not really. But I have an idea! ;-)

How did you get the Board? Directly from AMCC? Did it never work at all?

Your PLB frequency seems strange to me (160MHz). Please try to configure
your 
Ocotea to use a different setup, for example 533MHz CPU and 133MHz PLB.
Here 
is the output from our Ocotea:

U-Boot 1.1.4-g887e2ec9-dirty (Sep  7 2006 - 11:55:16)

CPU:   AMCC PowerPC 440GX Rev. F at 533.333 MHz (PLB=133, OPB=66, EBC=66
MHz)
       I2C boot EEPROM enabled
       Bootstrap Option F - Boot ROM Location I2C (Addr 0x54)
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  256 MB
FLASH:  5 MB
PCI:   Bus Dev VenId DevId Class Int
        00  01  8086  107c  0200  00
In:    serial
Out:   serial
Err:   serial
Net:   ppc_4xx_eth0, ppc_4xx_eth1, ppc_4xx_eth2, ppc_4xx_eth3

Type "run flash_nfs" to mount root filesystem over NFS

Hit any key to stop autoboot:  0
=>   

Best regards,
Stefan

[U-Boot-Users] (no subject)

[Stefan Roese]

Hi Gerald,

On Sunday 01 October 2006 19:15, Gerald Jackson wrote:
> I look more into using both dimms issue and I see two interesting
> things.
>
> 1. With two dimms it never get pass line 1478 - 1500 in spd_sdram.c.  It
> loops once then hangs.
>
> 2. If I disable this part (ie break) I get the ERROR: Cannot determine a
> common read delay. If I comment out the hang()  It returns but it only
> calculated 768MB of memory.

Only 768MB? Does this mean you are using more than 512MB? As I mentioned 
earlier, this can't work right now. The TLB setup is for a max. of 512MB.

Please try the attached init.S file. It fixes the issue mentioned by Marc 
Howard _and_ adds TLB entries for a max. of 1GB of DDR. It will be checked 
into the official git tree in a few days.

Please let me know if this changes anything.

Best regards,
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: init.S
Type: text/x-objcsrc
Size: 3481 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061001/69752937/attachment.bin 

[U-Boot-Users] (no subject)

[Gerald Jackson]

Stefan,

Thank you for the init.S file.  But the problem still persists.

Here is what I get:
U-Boot 1.1.4 (Oct  1 2006 - 02:58:55)

CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  DIMM slot 0: populated
DIMM slot 1: populated
DIMM slot 0: DDR SDRAM detected
DIMM slot 1: DDR SDRAM detected
DIMM 0 voltage level supported.
Finish program_cfg0
Finish program_cfg1
Finish program_rtr
tr0: 410b401a
Finish program_tr0
Finish program_bxcr Total_Size 805306368     <----  Here is part of the
problem this should return  about a 1Gig of memory but it only returns
805Megs.   

If I try only one dimm and move it to either slot it shows the correct
amount but with two dimms the calculation is wrong.

It seems like I am miss about two (or one) banks from the Dimm which I
assume equals 256M.

I am still working on what is causing the wrong amount.

Gerald


 
 
 

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Sunday, October 01, 2006 2:00 PM
To: u-boot-users@lists.sourceforge.net
Cc: Gerald Jackson
Subject: Re: [U-Boot-Users] (no subject)

Hi Gerald,

On Sunday 01 October 2006 19:15, Gerald Jackson wrote:
> I look more into using both dimms issue and I see two interesting
> things.
>
> 1. With two dimms it never get pass line 1478 - 1500 in spd_sdram.c.
It
> loops once then hangs.
>
> 2. If I disable this part (ie break) I get the ERROR: Cannot determine
a
> common read delay. If I comment out the hang()  It returns but it only
> calculated 768MB of memory.

Only 768MB? Does this mean you are using more than 512MB? As I mentioned

earlier, this can't work right now. The TLB setup is for a max. of
512MB.

Please try the attached init.S file. It fixes the issue mentioned by
Marc 
Howard _and_ adds TLB entries for a max. of 1GB of DDR. It will be
checked 
into the official git tree in a few days.

Please let me know if this changes anything.

Best regards,
Stefan

[U-Boot-Users] Ocotea board patch

[Gerald Jackson]

There is an error in  the spd_sdram.c file in a loop statement that is wrong if you are using two Dimms.
 
It missing initializing a part of the second dimm.  So if you have a 1gig of memory it will show up as 768Megs.
 
I have correct this but need to know on the procedure for sending a patch?
 
 1730                         /*
   1731                          * enable the bank
   1732                          */
   1733                         cr |= SDRAM_BXCR_SDBE;
   1734
   1735                         for (i = 0; i < num_banks; i++) {
   1736                          if (dimm_num == 1)
   1737                          {
   1738                                 bank_parms[ctrl_bank_num[dimm_num]+i+1].        bank_size_bytes =       (4 * 1024 * 1024) * bank_size_id;
   1739                                 bank_parms[ctrl_bank_num[dimm_num]+i+1].        cr = cr;
   1740                          }
   1741                          else
   1742                          {
   1743                                 bank_parms[ctrl_bank_num[dimm_num]+i].ba        nk_size_bytes = (4 * 1024 * 1024) * bank_size_id;
   1744                                 bank_parms[ctrl_bank_num[dimm_num]+i].cr         = cr;
   1745                          }

 
Without the patch it initializing like this:
0 = 256M
1 = 256M
1= 256M
2= 256M
 
Total 768M
 
With the patch:
0= 256M
1=256M
2=256M
3=256M
 
Total 1024M
 
 
Gerald
________________________________

From: u-boot-users-bounces@lists.sourceforge.net on behalf of Gerald Jackson
Sent: Sun 10/1/2006 3:17 PM
To: Stefan Roese; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] (no subject)



Stefan,

Thank you for the init.S file.  But the problem still persists.

Here is what I get:
U-Boot 1.1.4 (Oct  1 2006 - 02:58:55)

CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  DIMM slot 0: populated
DIMM slot 1: populated
DIMM slot 0: DDR SDRAM detected
DIMM slot 1: DDR SDRAM detected
DIMM 0 voltage level supported.
Finish program_cfg0
Finish program_cfg1
Finish program_rtr
tr0: 410b401a
Finish program_tr0
Finish program_bxcr Total_Size 805306368     <----  Here is part of the
problem this should return  about a 1Gig of memory but it only returns
805Megs.  

If I try only one dimm and move it to either slot it shows the correct
amount but with two dimms the calculation is wrong.

It seems like I am miss about two (or one) banks from the Dimm which I
assume equals 256M.

I am still working on what is causing the wrong amount.

Gerald






-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de]
Sent: Sunday, October 01, 2006 2:00 PM
To: u-boot-users@lists.sourceforge.net
Cc: Gerald Jackson
Subject: Re: [U-Boot-Users] (no subject)

Hi Gerald,

On Sunday 01 October 2006 19:15, Gerald Jackson wrote:
> I look more into using both dimms issue and I see two interesting
> things.
>
> 1. With two dimms it never get pass line 1478 - 1500 in spd_sdram.c.
It
> loops once then hangs.
>
> 2. If I disable this part (ie break) I get the ERROR: Cannot determine
a
> common read delay. If I comment out the hang()  It returns but it only
> calculated 768MB of memory.

Only 768MB? Does this mean you are using more than 512MB? As I mentioned

earlier, this can't work right now. The TLB setup is for a max. of
512MB.

Please try the attached init.S file. It fixes the issue mentioned by
Marc
Howard _and_ adds TLB entries for a max. of 1GB of DDR. It will be
checked
into the official git tree in a few days.

Please let me know if this changes anything.

Best regards,
Stefan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061006/bbbc310c/attachment.htm 

[U-Boot-Users] Ocotea board patch

[Wolfgang Denk]

In message <A7C98E37A5710946908EEC7C796A74426E8E@mainserver.reaonix.com> you wrote:
> 
> I have correct this but need to know on the procedure for sending a
> patch?

See the README, section about "Submitting Patches".

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Remember that Beethoven wrote his first symphony in C ...

[U-Boot-Users] Ocotea board patch

[Stefan Roese]

Hi Gerald,

On Friday 06 October 2006 18:01, Gerald Jackson wrote:
> There is an error in  the spd_sdram.c file in a loop statement that is
> wrong if you are using two Dimms.
>
> It missing initializing a part of the second dimm.  So if you have a 1gig
> of memory it will show up as 768Megs.
>
> I have correct this but need to know on the procedure for sending a patch?

It's hard to see what you really changed, so please take a look at the README 
under "Submitting Patches:" and send a proper patch.

Thanks.

Best regards,
Stefan

[U-Boot-Users] Ocotea board patch

[Gerald Jackson]

There is an error in the spd_sdram.c in cpu/ppc4xx/, file in a loop
statement that is wrong if you are using two Dimms.

 

It missing initializing a part of the second dimm.  So if you have a
1gig of memory it will show up as 768Megs.

 

Without the patch it initializing like this:

0 = 256M

1 = 256M

1= 256M

2= 256M

 

Total 768M

 

With the patch:

0= 256M

1=256M

2=256M

3=256M

 

Total 1024M

 

 

Gerald

________________________________

From: u-boot-users-bounces@lists.sourceforge.net on behalf of Gerald
Jackson
Sent: Sun 10/1/2006 3:17 PM
To: Stefan Roese; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] (no subject)

Stefan,

Thank you for the init.S file.  But the problem still persists.

Here is what I get:
U-Boot 1.1.4 (Oct  1 2006 - 02:58:55)

CPU:   AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40
MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C:   ready
DRAM:  DIMM slot 0: populated
DIMM slot 1: populated
DIMM slot 0: DDR SDRAM detected
DIMM slot 1: DDR SDRAM detected
DIMM 0 voltage level supported.
Finish program_cfg0
Finish program_cfg1
Finish program_rtr
tr0: 410b401a
Finish program_tr0
Finish program_bxcr Total_Size 805306368     <----  Here is part of the
problem this should return  about a 1Gig of memory but it only returns
805Megs.  

If I try only one dimm and move it to either slot it shows the correct
amount but with two dimms the calculation is wrong.

It seems like I am miss about two (or one) banks from the Dimm which I
assume equals 256M.

I am still working on what is causing the wrong amount.

Gerald






-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de]
Sent: Sunday, October 01, 2006 2:00 PM
To: u-boot-users@lists.sourceforge.net
Cc: Gerald Jackson
Subject: Re: [U-Boot-Users] (no subject)

Hi Gerald,

On Sunday 01 October 2006 19:15, Gerald Jackson wrote:
> I look more into using both dimms issue and I see two interesting
> things.
>
> 1. With two dimms it never get pass line 1478 - 1500 in spd_sdram.c.
It
> loops once then hangs.
>
> 2. If I disable this part (ie break) I get the ERROR: Cannot determine
a
> common read delay. If I comment out the hang()  It returns but it only
> calculated 768MB of memory.

Only 768MB? Does this mean you are using more than 512MB? As I mentioned

earlier, this can't work right now. The TLB setup is for a max. of
512MB.

Please try the attached init.S file. It fixes the issue mentioned by
Marc
Howard _and_ adds TLB entries for a max. of 1GB of DDR. It will be
checked
into the official git tree in a few days.

Please let me know if this changes anything.

Best regards,
Stefan

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061010/b7cf924d/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spd_sdram.patch
Type: application/octet-stream
Size: 674 bytes
Desc: spd_sdram.patch
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061010/b7cf924d/attachment.obj 

[U-Boot-Users] Ocotea board patch

[Stefan Roese]

Hi Gerald,

On Wednesday 11 October 2006 03:31, Gerald Jackson wrote:
> There is an error in the spd_sdram.c in cpu/ppc4xx/, file in a loop
> statement that is wrong if you are using two Dimms.
>
> It missing initializing a part of the second dimm.  So if you have a
> 1gig of memory it will show up as 768Megs.

<snip>

> --- spd_sdram.OLD	2006-10-10 09:07:34.000000000 -0400
> +++ spd_sdram.c	2006-10-10 09:15:08.000000000 -0400
> @@ -1733,9 +1733,16 @@ unsigned long program_bxcr(unsigned long
>  			cr |= SDRAM_BXCR_SDBE;
>
>  			for (i = 0; i < num_banks; i++) {
> -				bank_parms[ctrl_bank_num[dimm_num]+i].bank_size_bytes =
> +				if(dimm_num == 1){
> +					bank_parms[ctrl_bank_num[dimm_num]+i+1].bank_size_bytes =
>  					(4 * 1024 * 1024) * bank_size_id;
> +				bank_parms[ctrl_bank_num[dimm_num]+i+1].cr = cr;
> +				{
> +				else
> +				{

Hmmm??? "{ else {"??? You mean "} else {", right?

> +					bank_parms[ctrl_bank_num[dimm_num]+i].bank_size_bytes = (4 * 1024 * 1024) * bank_size_id;
> 				bank_parms[ctrl_bank_num[dimm_num]+i].cr = cr; 
> +				}
>  			}
>  		}
>  	}

Your patch seems broken to me. Did you create it by hand? Please try again.

And please also take make sure that you don't violate the conding style.

Thanks.

Best regards,
Stefan

[U-Boot-Users] Ethernet not work on Linux 2.6.17 w/ at91rm9200 patched

[nm]

Hi *,

I have problem w/ at91rm9200 board, Intel LXT971A PHY
Ethernet on U-Boot work well, I'm using tftp to get uImage and initrd to 
SDRAM,
tftp 20000000 /tftpboot/img/uImage
tftp 20400000 /tftpboot/img/uRamdisk.2809.5
setenv bootargs root=/dev/ram

U-Boot> printenv
bootdelay=3
baudrate=115200
ethaddr=DE:AD:BE:EF:01:01
ipaddr=192.168.0.111
serverip=192.168.0.223
netmask=255.255.255.0
stdin=serial
stdout=serial
stderr=serial
bootargs=root=/dev/ram init=/bin/sh

I use linux kernel 2.6.17 w/  this patch 
http://maxim.org.za/AT91RM9200/2.6/2.6.17-sam9261-3.patch.gz
But when i got a shell on linux, i try to ping some host on LAN ... 
nothing happend
# mount -t proc proc /proc
# ifconfig eth0 192.168.0.111
eth0: Link now 100-FullDuplex
# ping 192.168.0.223
PING 192.168.0.223 (192.168.0.223): 56 data bytes

# cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     
Device
192.168.0.223    0x1         0x0         00:00:00:00:00:00     *        eth0

On my host computer:
(#:/home/tmp/kernelsrc/linux-2.6.17)- arp -a
? (192.168.0.111) at <incomplete> on eth0

Some one told me about Linux get_mac_address problem, but i see that 
Linux got MAC( on dmesg)
eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (de:ad:be:ef:01:01)
eth0: Intel LXT971A PHY

So, what am i wrong ?

Thanks,
nm.

p/s: I attached my dmesg, linux dot config file in this email.

dmesg :
Uncompressing 
Linux...................................................................................Linux 
version 2.6.17 (root at nm-lapdeb) (gcc version 4.0.0 (DENX ELDK 4.0 
4.0.0)) #8 Mon Oct 2 23:35:056CPU: ARM920Tid(wb) [41129200] revision 0 
(ARMv4T)
Machine: Atmel AT91RM9200-DK
Memory policy: ECC disabled, Data cache writeback
Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists
Kernel command line: root=/dev/ram init=/bin/sh
AT91: 128 gpio irqs in 4 banks
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 28412KB available (2077K code, 459K data, 100K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
checking if image is initramfs...it isn't (no cpio magic); looks like an 
initrd
Freeing initrd memory: 1365K
NET: Registered protocol family 16
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NET: Registered protocol family 2
IP route cache hash table entries: 256 (order: -2, 1024 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 1024 bind 512)
TCP reno registered
NetWinder Floating Point Emulator V0.97 (double precision)
Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
at91_spi: Baud rate set to 5990400
AT91 SPI driver loaded
AT91 Watchdog Timer enabled (5 seconds, nowayout)
at91_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL
at91_usart.1: ttyS1 at MMIO 0xfffc4000 (irq = 7) is a AT91_SERIAL
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
LXT970: Registered new driver
LXT971: Registered new driver
eth0: Link now 100-FullDuplex
eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (de:ad:be:ef:01:01)
eth0: Intel LXT971A PHY
netconsole: not configured, aborting
physmap flash device: 200000 at 10000000
at91_dataflash: AT45DB321B detected [spi0] (4325376 bytes)
Creating 3 MTD partitions on "AT45DB321B.spi0":
0x00000000-0x00042000 : "bootloader"
0x00042000-0x0014a000 : "kernel"
0x0014a000-0x00420000 : "filesystem"
at91_cf: irqs det #64, io #0
usbmon: debugfs is not available
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 23, io mem 0x00300000
usb usb1: Product: AT91 OHCI
usb usb1: Manufacturer: Linux 2.6.17 ohci_hcd
usb usb1: SerialNumber: at91
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 1-1: new full speed USB device using at91_ohci and address 2
usb 1-1: Product: DataTraveler 2.0
usb 1-1: Manufacturer: Kingston
usb 1-1: configuration #1 chosen from 1 choice
usb 1-2: new low speed USB device using at91_ohci and address 3
usb 1-2: device descriptor read/64, error -110
usb 1-2: device descriptor read/64, error -110
usb 1-2: new low speed USB device using at91_ohci and address 4
usb 1-2: device descriptor read/64, error -110
usb 1-2: device descriptor read/64, error -110
usb 1-2: new low speed USB device using at91_ohci and address 5
usb 1-2: device not accepting address 5, error -110
usb 1-2: new low speed USB device using at91_ohci and address 6
usb 1-2: device not accepting address 6, error -110
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver libusual
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
udc: at91_udc version 3 May 2006
mice: PS/2 mouse device common for all mice
at91_rtc at91_rtc: rtc intf: sysfs
at91_rtc at91_rtc: rtc intf: proc
at91_rtc at91_rtc: rtc intf: dev (253:0)
at91_rtc at91_rtc: rtc core: registered at91_rtc as rtc0
AT91 Real Time Clock driver.
i2c /dev entries driver
at91_i2c at91_i2c: AT91 i2c bus driver.
MMC: 4 wire bus mode not supported by this driver - using 1 wire
NET: Registered protocol family 26
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 100K


BusyBox v(null) ((null)) Built-in shell (msh)
Enter 'help' for a list of built-in commands.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config
Url: http://lists.denx.de/pipermail/u-boot/attachments/20061003/9c294a62/attachment.txt 

[U-Boot-Users] Ethernet not work on Linux 2.6.17 w/ at91rm9200 patched

[Wolfgang Denk]

In message <4521BDED.8010700@gmail.com> you wrote:
>
> But when i got a shell on linux, i try to ping some host on LAN ... 
> nothing happend
...
> So, what am i wrong ?

Wrong mailing list.

This is not an U-Boot related issue, so your posting is off topic
here.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To be sure of hitting the target, shoot first and, whatever you  hit,
call it the target.