2009-05-25 08:43:41     128M RAM

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

2009-05-25 08:43:41     128M RAM

Mike Sinkovsky (RUSSIAN FEDERATION)

Message: 74540   

 

I'm porting latest u-boot to our custom board (BF531, 128M RAM, 4G NAND flash, and u-boot from separate small SPI flash), and found sone bugs.

 

First, it was not booting. After two days debugging, i noticed that in LDR file was three sections at FFA08000 - first initializing, second jump to SDRAM, and third - from file cpu/blackfin/reset.c. Third owerwrites second, and this jump did not work. I solwed this in u-boot.lds.S:

 

  l1_code : ORIGIN = L1_INST_SRAM + 12, LENGTH = L1_INST_SRAM_SIZE - 12

 

When debugging this, I enable CONFIG_DEBUG_EARLY_SERIAL, and cpu/blackfin/initcode.c does not compile - iline finction serial_putc calls itself, and compiler said "sorry, unimplemented". So commented this call.

 

Next, in drivers/mtd/nand/nand_plat.c: our board does not have NAND_READY pin, and macro

 

#define dev_ready NULL

  nand->dev_ready = dev_ready;

 

 

after preprocessing -

  nand->NULL = NULL;

 

 

I commented out this, too.

 

 

 

And now, there is yet another bug, that i can't fix myself - with SDRAM size 128Mbyte, when enable ICACHE or DCACHE - board hangs. If reduce to 64 Mbytes - all works ok.

QuoteReplyEditDelete

 

 

2009-05-25 22:26:24     Re: 128M RAM

Mike Frysinger (UNITED STATES)

Message: 74555   

 

there should be no jump block on purpose -- it's a waste.  the initcode already updates EVT1 to point to the right place.  sounds like your port is out of date and not adding -J to LDR_FLAGS.

 

if it's saying "sorry, unimplemented", that sounds like you're enabling debug code or lower optimization levels or something.  you'd have to provide real details like the actual compiler output.

 

ive fixed the nand_plat error, thanks

 

our BF537-STAMP uses 128 megs with icache/dcache just fine ... where exactly does it hang ?  did you use the right memory settings or did you copy them from somewhere ?

QuoteReplyEditDelete

 

 

2009-05-26 01:51:22     Re: 128M RAM

Mike Sinkovsky (RUSSIAN FEDERATION)

Message: 74561   

 

>> there should be no jump block on purpose -- it's a waste.  the initcode already updates EVT1 to point to the right place.   sounds like your port is out of date and not adding -J to LDR_FLAGS.

 

Yes, I forgot line#define CONFIG_BFIN_BOOTROM_USES_EVT1

 

With this, all compiles and works without jump and +12

 

>> if it's saying "sorry, unimplemented", that sounds like you're enabling debug code or lower optimization levels or  something.  you'd have to provide real details like the actual compiler output.

 

bfin-uclinux-gcc -g -Os -ffixed-P5 -fomit-frame-pointer -mno-fdpic -ffunction-sections -fdata-sections -mcpu=bf531-0.5 -D__KERNEL__ -I/home/msink/trikom/u-boot/u-boot-2009.03/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/2009SVN/bfin-uclinux/bin/../lib/gcc/bfin-uclinux/4.1.2/include -pipe -DCONFIG_BLACKFIN -Wall -Wstrict-prototypes -fno-stack-protector -fno-function-sections -fno-data-sections -c -o initcode.o initcode.c

initcode.c: In function ‘initcode’:

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

initcode.c:90: sorry, unimplemented: inlining failed in call to ‘serial_putc’: recursive inlining

initcode.c:95: sorry, unimplemented: called from here

make[1]: *** [initcode.o] Ошибка 1

make[1]: Leaving directory `/home/msink/trikom/u-boot/u-boot-2009.03/cpu/blackfin'

make: *** [cpu/blackfin/libblackfin.a] Ошибка 2

 

 

> our BF537-STAMP uses 128 megs with icache/dcache just fine ... where exactly does it hang ?  did you use the right memory settings or did you copy them from somewhere ?

 

in bf537-stamp.h:

 

#define CONFIG_MEM_ADD_WDTH 10

#define CONFIG_MEM_SIZE 64

 

 

I can't see there 128Mbyte.

 

I compile with this:

 

#define CONFIG_MEM_ADD_WDTH 11

#define CONFIG_MEM_SIZE 128

#define CONFIG_ICACHE_OFF

#define CONFIG_DCACHE_OFF

 

 

Then it works just fine. But after command icache on it hangs immediately, not returning to command promt.

QuoteReplyEditDelete

 

 

2009-05-26 02:58:57     Re: 128M RAM

Mike Frysinger (UNITED STATES)

Message: 74564   

 

i looked at the logic around CONFIG_BFIN_BOOTROM_USES_EVT1 and it has a bug for BF531/BF532 ... you shouldnt need to define it manually.  ive fixed this in trunk.

 

i dont see those warnings at all ... post your board's config header

 

i'm not talking about those memory settings ... what are you using for your memory timings ?

QuoteReplyEditDelete

 

 

2009-05-26 03:23:20     Re: 128M RAM

Mike Sinkovsky (RUSSIAN FEDERATION)

Message: 74567   

 

>> i dont see those warnings at all ... post your board's config header

 

You can see this for example in blackstamp board in trunk, if uncomment line 17 in blackstamp.h and compile.

 

I attached my header

 

>> i'm not talking about those memory settings ... what are you using for your memory timings ?

 

#define SDRAM_CL CL_3 /* CAS latency = 3 cycles */

#define SDRAM_tRP TRP_2 /* tRP = 2 cycles */

#define SDRAM_tRP_num 2

#define SDRAM_tRAS TRAS_6 /* tRAS = 6 cycles */

#define SDRAM_tRAS_num 6

#define SDRAM_tRCD TRCD_2 /* tRCD = 2 cycles */

#define SDRAM_tWR TWR_2 /* tWR = 2 cycles */

#define SDRAM_Tref 64 /* Refresh period in milliseconds */

#define SDRAM_NRA 8192 /* Number of row addresses in SDRAM */

 

#define CONFIG_EBIU_SDRRC_VAL ((((CONFIG_SCLK_HZ / 1000) * SDRAM_Tref) / SDRAM_NRA) - (SDRAM_tRAS_num + SDRAM_tRP_num))

#define CONFIG_EBIU_SDGCTL_VAL (SCTLE | SDRAM_CL | SDRAM_tRAS | SDRAM_tRP | SDRAM_tRCD | SDRAM_tWR | PSS)

 

 

But can it be that, board works without caching (and mtest does not find any error), but hang immediately after enabling cache?

 

trikom-1u-kcp4.h

QuoteReplyEditDelete

 

 

2009-05-26 03:32:30     Re: 128M RAM

Mike Frysinger (UNITED STATES)

Message: 74572   

 

looks like gcc-4.1 sucks and cant handle the recursive inlining ... gcc-4.3 works fine.  guess i'll have to add a workaround for it for the time being.

 

the only thing CONFIG_{D,I}CACHE_OFF does is control the default cache state.  you should be able to run "dcache on" at runtime to turn it on and see if that works.

 

at any rate, dont use that algorithm.  do what the documentation says:

http://docs.blackfin.uclinux.org/doku.php?id=bfin:sdram

QuoteReplyEditDelete

Attachments

    Outcomes