2009-09-30 14:03:31     Curious problem with SDRAM on custom bf532 board

Document created by Aaronwu Employee on Sep 24, 2013
Version 1Show Document
  • View in full screen mode

2009-09-30 14:03:31     Curious problem with SDRAM on custom bf532 board

Fred Dubois (CANADA)

Message: 80723   

 

Hello!

 

I'm continuing J-F Duval's work on a custom BF532 board inspired from the BF533-STAMP. The main differences are that our board has 64MB of SDRAM (MT48LC32M16A2 - single 64MB chip instead of 4 chips), nothing connected to the asynchronous address range and a Atmel SPI flash chip (AT45DB321D with page size 512).

 

J-F was using an older version of u-boot so we decided to start from scratch with a newer version of u-boot. We are now at the same point that he was.

 

I'm using u-boot-2008.10-2009R1-rc3 and I downloaded blackfin-toolchain-09r1-10.i386.tar.bz2 and blackfin-toolchain-uclibc-full-09r1-10.i386.tar.bz2 for the toolchain.

 

We are running the core at 300MHz and the system clock at 100MHz. I would like to set it at 400MHz with SCLK at 80MHz, but we get junk on the serial port, seems the baud rate is all wrong... (I will make another post for that problem).

 

Booting from SPI Flash does not work (I will make another post for that problem).

 

To load u-boot to our board, we are using an ICEBear JTAG. I'm using the technique described here http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:debugging#jtag_loading to load u-boot to our board. This works very well.

 

We based our configs off of the bf533-stamp ones for the include/configs file and the board/bf532 files. I used the EBIU_AM* settings from the BF533-STAMP, I don't know if this can cause any problems, even though we aren't using anything with the asynchronous controller...

 

Several problems have arisen, wich is the reason for my posting.

 

Problem with SDRAM:

 

Writing and reading to the spi flash with sf command seems to work, as confirmed from the printfs written with #define DEBUG. The correct data is read from the flash. BUT, the problem is that the SDRAM does not store the correct data:

 

(Address 0x1000000 is where I dumped the u-boot.ldr with loady)

 

bfin> sf read 0x1500000 0 0x10000

bfin> md.b 1000000 0x80

01000000: 00 80 a0 ff cc 04 00 00 08 00 66 01 c0 05 50 01    ..........f...P.

01000010: 51 01 52 01 53 01 58 01 59 01 5a 01 5b 01 5c 01    Q.R.S.X.Y.Z.[.\.

01000020: 5d 01 5e 01 5f 01 54 01 55 01 56 01 57 01 60 01    ].^._.T.U.V.W.`.

01000030: 61 01 4a e1 c0 ff 62 01 63 01 0a e1 24 04 00 e8    a.J...b.c...$...

01000040: 00 00 08 60 48 e1 c0 ff 51 95 08 e1 0c 04 10 97    ...`H...Q.......

01000050: 18 60 00 97 30 00 00 00 00 00 24 00 40 00 01 49    .`..0.....$.@..I

01000060: 1c 1c 40 95 38 4a 00 97 30 00 00 00 00 00 24 00    ..@.8J..0.....$.

01000070: 40 00 b0 61 e2 6e 10 97 00 60 22 6c 10 97 30 00    @..a.n...`"l..0.

bfin> md.b 1500000 0x80

01500000: f6 80 fc ff f6 04 fc 00 f6 00 fc 01 f6 05 fc 01    ................

01500010: f6 01 fc 01 f6 01 fc 01 f6 01 fc 01 f6 01 fc 01    ................

01500020: f6 01 fc 01 f6 01 fc 01 f6 01 fc 01 f6 01 fc 01    ................

01500030: f6 01 fc e1 f6 ff fc 01 f6 01 fc e1 f6 04 fc e8    ................

01500040: f6 00 fc 60 f6 e1 fc ff f6 95 fc e1 f6 04 fc 97    ...`............

01500050: f6 60 fc 97 f6 00 fc 00 f6 00 fc 00 f6 00 fc 49    .`.............I

01500060: f6 1c fc 95 f6 4a fc 97 f6 00 fc 00 f6 00 fc 00    .....J..........

01500070: f6 00 fc 61 f6 6e fc 97 f6 60 fc 6c f6 97 fc 00    ...a.n...`.l....

 

Notice that at 0x1500000 there are f6 and fc columns, and these are not the right values. If I read less bytes from the SPI flash, I can get correct data:

 

bfin> sf read 0x1500000 0 0x100  

bfin> md.b 1500000 0x80      

01500000: 00 80 a0 ff cc 04 00 00 08 00 66 01 c0 05 50 01    ..........f...P.

01500010: 51 01 52 01 53 01 58 01 59 01 5a 01 5b 01 5c 01    Q.R.S.X.Y.Z.[.\.

01500020: 5d 01 5e 01 5f 01 54 01 55 01 56 01 57 01 60 01    ].^._.T.U.V.W.`.

01500030: 61 01 4a e1 c0 ff 62 01 63 01 0a e1 24 04 00 e8    a.J...b.c...$...

01500040: 00 00 08 60 48 e1 c0 ff 51 95 08 e1 0c 04 10 97    ...`H...Q.......

01500050: 18 60 00 97 30 00 00 00 00 00 24 00 40 00 01 49    .`..0.....$.@..I

01500060: 1c 1c 40 95 38 4a 00 97 30 00 00 00 00 00 24 00    ..@.8J..0.....$.

01500070: 40 00 b0 61 e2 6e 10 97 00 60 22 6c 10 97 30 00    @..a.n...`"l..0.

 

But if I use cmp.b, I lose some data(!):

 

bfin> cmp 0x1000000 0x1500000 0x100

word at 0x01000000 (0xffa08000) != word at 0x01500000 (0xfffc80f6)

Total of 0 words were the same

bfin> md.b 1500000 0x80          

01500000: f6 80 fc ff f6 04 fc 00 f6 00 fc 01 f6 05 fc 01    ................

01500010: f6 01 fc 01 f6 01 fc 01 f6 01 fc 01 f6 01 fc 01    ................

01500020: 5d 01 5e 01 5f 01 54 01 55 01 56 01 57 01 60 01    ].^._.T.U.V.W.`.

01500030: 61 01 4a e1 c0 ff 62 01 63 01 0a e1 24 04 00 e8    a.J...b.c...$...

01500040: 00 00 08 60 48 e1 c0 ff 51 95 08 e1 0c 04 10 97    ...`H...Q.......

01500050: 18 60 00 97 30 00 00 00 00 00 24 00 40 00 01 49    .`..0.....$.@..I

01500060: 1c 1c 40 95 38 4a 00 97 30 00 00 00 00 00 24 00    ..@.8J..0.....$.

01500070: 40 00 b0 61 e2 6e 10 97 00 60 22 6c 10 97 30 00    @..a.n...`"l..0.

 

We see the same bad pattern in the first 16 bytes...

 

 

Here is my bf532.h file from include/configs:

 

#ifndef __CONFIG_BF532_GIGA_H__

#define __CONFIG_BF532_GIGA_H__

 

#include <asm/blackfin-config-pre.h>

 

/*

* Processor Settings

*/

#define CONFIG_BFIN_CPU             bf532-0.5

#define CONFIG_BFIN_BOOT_MODE       BFIN_BOOT_SPI_MASTER

 

#define CONFIG_BAUDRATE        115200

/* #define CONFIG_BAUDRATE        115200 */

 

/*

* Clock Settings

*    CCLK = (CLKIN * VCO_MULT) / CCLK_DIV

*    SCLK = (CLKIN * VCO_MULT) / SCLK_DIV

*/

/* CONFIG_CLKIN_HZ is any value in Hz                    */

#define CONFIG_CLKIN_HZ            25000000

/* CLKIN_HALF controls the DF bit in PLL_CTL      0 = CLKIN        */

/*                                                1 = CLKIN / 2        */

#define CONFIG_CLKIN_HALF        0

/* PLL_BYPASS controls the BYPASS bit in PLL_CTL  0 = do not bypass    */

/*                                                1 = bypass PLL    */

#define CONFIG_PLL_BYPASS        0

/* VCO_MULT controls the MSEL (multiplier) bits in PLL_CTL        */

/* Values can range from 0-63 (where 0 means 64)            */

#define CONFIG_VCO_MULT            12

/* CCLK_DIV controls the core clock divider                */

/* Values can be 1, 2, 4, or 8 ONLY                    */

#define CONFIG_CCLK_DIV            1

/* SCLK_DIV controls the system clock divider                */

/* Values can range from 1-15                        */

#define CONFIG_SCLK_DIV            3 /* note: 1.2 boards can go faster */

 

#define CFG_NO_FLASH

 

/*

* Memory Settings

*/

#define CONFIG_MEM_ADD_WDTH    11

#define CONFIG_MEM_SIZE        64  

 

#define CONFIG_EBIU_SDRRC_VAL    0x305

/*#define CONFIG_EBIU_SDRRC_VAL    0x26A*/

#define CONFIG_EBIU_SDGCTL_VAL    0x8091119D

/*#define CONFIG_EBIU_SDGCTL_VAL    0x81F1115D*/

#define CONFIG_EBIU_SDBCTL_VAL  0x25

 

#define CONFIG_EBIU_AMGCTL_VAL    0xFF

#define CONFIG_EBIU_AMBCTL0_VAL    0xBBC3BBC3

#define CONFIG_EBIU_AMBCTL1_VAL    0x99B39983

 

#define CFG_MONITOR_LEN        (256 * 1024)    /* Reserve 256 kB for monitor */

#define CFG_MALLOC_LEN        (384 * 1024)    /* Reserve 384 kB for malloc() (video/spi are big) */

 

/*

* Network Settings

*/

#define CONFIG_HOSTNAME        bf532-giga

 

/*

* Flash Settings

*/

#define CFG_FLASH_BASE        0x0

#define CFG_MAX_FLASH_BANKS    1    /* max number of memory banks */

#define CFG_MAX_FLASH_SECT    64    /* max number of sectors on one chip */

#define FLASH_TOT_SECT CFG_MAX_FLASH_SECT

 

#define CONFIG_BFIN_SPI

/* #define CONFIG_SF_DEFAULT_HZ    30000000 */

#define CONFIG_SF_DEFAULT_HZ    1000000

#define CONFIG_SF_DEFAULT_MODE SPI_MODE_3

#define CONFIG_SPI_FLASH

#define CONFIG_SPI_FLASH_ATMEL

 

/* settings to store uboot environment in spi flash */

/* #define CONFIG_ENV_SPI_MAX_HZ   30000000 */

#define CONFIG_ENV_SPI_MAX_HZ   1000000

#define CONFIG_ENV_IS_IN_SPI_FLASH

#define CONFIG_ENV_OFFSET    0x0

#define CONFIG_ENV_SIZE        0x1000

#define CONFIG_ENV_SECT_SIZE    0x1000

#define CONFIG_ENV_SPI_CS 2

 

#define    ENV_IS_EMBEDDED_CUSTOM

 

/*

* Misc Settings

*/

#define CONFIG_RTC_BFIN

#define CONFIG_UART_CONSOLE    0

 

#define CONFIG_DEBUG_DUMP 1

#define CONFIG_DEBUG_DUMP_SYMS 1

#define CONFIG_PANIC_HANG    1

#define CONFIG_DEBUG_EARLY_SERIAL 1

#define DEBUG

/* #define DEBUG_ENV */

 

#define CONFIG_CMD_SF

#define CONFIG_BFIN_CMD

#define    CONFIG_CMD_BDI

#define    CONFIG_CMD_ENV

#define    CONFIG_CMD_RUN

#define    CONFIG_CMD_CACHE

#define    CONFIG_CMD_SF

#define CONFIG_CMD_CPLBINFO

#define CONFIG_CMD_REGINFO

#define    CONFIG_CMD_LOADB

#define    CONFIG_CMD_MEMORY

#undef CONFIG_CMD_FLASH

#undef CONFIG_CMD_IMLS

 

#define CFG_LONGHELP        1

#define CONFIG_CMDLINE_EDITING    1

#define CONFIG_AUTO_COMPLETE    1

 

#include <asm/blackfin-config-post.h>

 

 

I used the excel file to set my SDRAM settings although there are some settings I am not sure about...

 

What can be causing this?

 

Thanks!

 

Fred

QuoteReplyEditDelete

 

 

2009-09-30 14:33:37     Re: Curious problem with SDRAM on custom bf532 board

Mike Frysinger (UNITED STATES)

Message: 80724   

 

does "mtest" pass ?

 

what settings are you not sure of ?  all of the inputs should be taken straight from the sdram datasheet.

 

the EBIU settings for the async banks shouldnt matter at all to the settings for the SDRAM.

 

if you use sf to read into L1 data memory, does it work ?

QuoteReplyEditDelete

 

 

2009-09-30 20:08:46     Re: Curious problem with SDRAM on custom bf532 board

Fred Dubois (CANADA)

Message: 80731   

 

Hello Mike, thanks for responding. I left mtest running, after an hour it was still writing patterns without any problems.

 

For the RAM settings that I'm not sure about, it's the following:

 

CDDBG,

 

TCSR,

 

EMREN,

 

FBBRW,

 

EBUFE,

 

PASR.

 

We didn't find anything in the datasheet about them. We put all those bits at 0.

 

I tried writing in the data bank A SRAM/Cache at address 0xFF80 4000 with sf read, but the blackfin crashed :

 

bfin> sf read 0xFF804000 0x0 0x1000                       

                   

                                                                              

                                                                              

                                                                              

Ack! Something bad happened to the Blackfin!                                  

                                                                              

SEQUENCER STATUS:                                                             

SEQSTAT: 00002023  IPEND: 8008  SYSCFG: 0032                                 

  HWERRCAUSE: 0x0: undef                                                      

  EXCAUSE   : 0x23: dcplb prot violation                                      

  physical IVG15 asserted : <0x03fc0b74> { _evt_default + 0x0 }               

RETE: <0x03fc0000> { _start + 0x0 }                                          

RETN: <0x933b9fe5> { ___umulsi3_highpart + 0x8f3eed21 }                      

RETX: <0x03fcb242> { loop0 + 0x3d7e }                                        

RETS: <0x03fcb216> { loop0 + 0x3d52 }                                        

RETI: <0x03fc01f4> { _start + 0x1f4 }                                        

DCPLB_FAULT_ADDR: <0xff804000> { ___umulsi3_highpart + 0xfb838d3c }           

ICPLB_FAULT_ADDR: <0x03fcb242> { loop0 + 0x3d7e }                             

                                                                              

PROCESSOR STATE:                                                              

R0 : 00000000    R1 : 00008000    R2 : 00000000    R3 : 03f5fb18             

R4 : 03f610d8    R5 : 00000005    R6 : 00000002    R7 : 00000fff             

P0 : 03fcfb54    P1 : 00000000    P2 : ffc00510    P3 : 00000000             

P4 : ff804000    P5 : 03f5ff80    FP : 03f610d8    SP : 03f5f9c0             

LB0: 03fcb2ac    LT0: 03fcb2a0    LC0: 00000000                              

LB1: 03fc75ea    LT1: 03fc75dc    LC1: 00000000                              

B0 : d4877fc4    L0 : 00000000    M0 : c7772c40    I0 : 000084ea             

B1 : f7bb295c    L1 : 00000000    M1 : fd970567    I1 : 03fd3328             

B2 : 8185967c    L2 : 00000000    M2 : be2dbcfe    I2 : 1dc2a8ca             

B3 : b5465751    L3 : 00000000    M3 : 399d3516    I3 : a90b19bb             

A0.w: 00000000   A0.x: 00000000   A1.w: 00000000   A1.x: 00000000             

USP : c0ad0a43  ASTAT: 00001005                                               

                                                                              

Hardware Trace:                                                               

   0 Target : <0x03fc115c> { _bfin_panic + 0x0 }                              

     Source : <0x03fc12d8> { _trap_c + 0x140 }                                

   1 Target : <0x03fc12cc> { _trap_c + 0x134 }                                

     Source : <0x03fc11b4> { _trap_c + 0x1c }                                 

   2 Target : <0x03fc1198> { _trap_c + 0x0 }                                  

     Source : <0x03fc0b1a> { _trap + 0x56 }                                   

   3 Target : <0x03fc0ac4> { _trap + 0x0 }                                    

     Source : <0x03fcb240> { loop0 + 0x3d7c }                                 

   4 Target : <0x03fcb22e> { loop0 + 0x3d6a }                                 

     Source : <0x03fcb224> { loop0 + 0x3d60 }                                 

   5 Target : <0x03fcb216> { loop0 + 0x3d52 }                                 

     Source : <0x03fc4d44> { _ctrlc + 0x3c }                                  

   6 Target : <0x03fc4d3e> { _ctrlc + 0x36 }                                  

     Source : <0x03fc4d26> { _ctrlc + 0x1e }                                  

   7 Target : <0x03fc4d24> { _ctrlc + 0x1c }                                  

     Source : <0x03fc0a4a> { _serial_tstc + 0xe }                             

   8 Target : <0x03fc0a3c> { _serial_tstc + 0x0 }                             

     Source : <0x03fc4a6c> { _ftstc + 0x14 }                                  

   9 Target : <0x03fc4a58> { _ftstc + 0x0 }                                   

     Source : <0x03fc4cf0> { _tstc + 0x8 }                                    

  10 Target : <0x03fc4ce8> { _tstc + 0x0 }                                    

     Source : <0x03fc4d20> { _ctrlc + 0x18 }                                  

  11 Target : <0x03fc4d08> { _ctrlc + 0x0 }                                   

     Source : <0x03fcb212> { loop0 + 0x3d4e }                                 

  12 Target : <0x03fcb212> { loop0 + 0x3d4e }                                 

     Source : <0x03fcb222> { loop0 + 0x3d5e }                                 

  13 Target : <0x03fcb216> { loop0 + 0x3d52 }                                 

     Source : <0x03fc4d44> { _ctrlc + 0x3c }                                  

  14 Target : <0x03fc4d3e> { _ctrlc + 0x36 }                                  

     Source : <0x03fc4d26> { _ctrlc + 0x1e }                                  

  15 Target : <0x03fc4d24> { _ctrlc + 0x1c }                                  

     Source : <0x03fc0a4a> { _serial_tstc + 0xe }                             

                                                                              

### ERROR ### Please RESET the board ###

 

Also, we found that if we do a sf read with a length of 0x800 and below, (as in sf read 0x2000000 0x0 0x800) it works, but reading with a length 0x801 and above doesn't (I get the behavior described in my last post, 1 out of every 2 bytes is wrong).

 

Thanks,

 

Fred

QuoteReplyEditDelete

 

 

2009-10-01 00:54:15     Re: Curious problem with SDRAM on custom bf532 board

Mike Frysinger (UNITED STATES)

Message: 80736   

 

you cant write to sram cache as data cache is enabled by default.  you have to use a dedicated sram bank.

 

if you use the spread sheet to calculate the register settings, there should be no need for you to mess with any specific bit.

QuoteReplyEditDelete

Attachments

    Outcomes