2010-06-17 08:01:20     u-boot loading problem: u-boot.ldr blocks not written to SDRAM

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

2010-06-17 08:01:20     u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Martin Blomberg (SWEDEN)

Message: 90373   

 

Hi,

 

we have a problem loading u-boot on our custom bf526 board, using UART0 and a FTDI USB to serial converter cable (level shifter on board). When running bfin-uclinux-ldr autobaud completes ok, and then the u-boot.ldr image seem to be transferred (looking at the scope), however nothing happens when we connect with kermit afterwards.

 

With LdrViewer we can see how the u-boot.ldr is built up, ie. block 0 - block 9, and with ADZS-HPUSB-ICE and VisualDSP++ we can verify that block 1 part of the u-boot.ldr image is actually written into Instruction Bank A SRAM (FFA00000 addresses). However, with all blocks that targets SDRAM memory (03F60000 addresses), nothing seem to get written.

 

That lead us to believe that something wrong with the SDRAM, however we seem to be able to write to it from VisualDSP++, both after having transferred parts of the u-boot.ldr image, and with a simple test program in (modified ADI SDRAM example code).

 

The SDRAM memory is a 64 Mb MT48H32M16LF, which also is the case in our bf526-ezbrd, and we have verified the u-boot SDRAM configuration to work on that board using SCLK 30 MHz (16 MHz crystal x msel 15 / sclk_div 8 = 30 MHz).

 

Btw, we did at first have an issue with autobaud using our original 12 MHz crystal, the data returned by the blackfin on the sent '@' character was about 10% off in baudrate. But after changing to a 16 Mhz crystal, at least it works to autobaud and transfer the image.

 

Any ideas on why SDRAM is not written to?

 

PS. I guess we could try to load u-boot some other way, however LdrViewer does not support USB COM ports, VisualDSP++ does not support our flash (M25P128), and the open source JTAG tools does not seem to support  the ADZS-HPUSB-ICE.

 

Best Regards,

 

Martin Blomberg

QuoteReplyEditDelete

 

 

2010-06-17 08:42:11     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Robin Getz (UNITED STATES)

Message: 90375   

 

Martin:

 

What you need is a gnice:

 

https://docs.blackfin.uclinux.org/doku.php?id=hw:jtag:gnice-plus

 

OR - just use what you have.

 

Try a slower baud rate - we have seen issues with some USB <-> serial converters drop chars over 57600 baud. (we have heard of some which only work at 9600 baud).

 

re-compile U-Boot with CONFIG_DEBUG_EARLY_SERIAL defined to 1 - and the baud rate set to whatever you have the USB <-> serial set to, and when download with bfin-uclinux-ldr remember to set the baud rate with "-b 57600" This should shoot out some char as things are working.. Look in cpu/blackfin/start.S for serial_early_puts() calls.

 

-Robin

QuoteReplyEditDelete

 

 

2010-06-18 10:15:20     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Martin Blomberg (SWEDEN)

Message: 90422   

 

Robin, thanks for your quick reply.

 

Setting SCLK to 60 MHz and changing the SDRAM configuration accordingly for some reason solved the problem with blackfin not writing u-boot.ldr parts to SDRAM during UART0 boot.

 

Transfers on all baudrates up to 115200 also seem to work fine, the u-boot.ldr blocks all get written correctly to blackfin Instruction Bank A SRAM and SDRAM, as viewed in VisualDSP++.

 

And we do get some response now from the board, however the output is somewhat cryptic. And it is not the same from one time to another.

 

Example output:

 

mblomberg@SVVARRDPROJ01:~/svn/external/u-boot/modified/u-boot$ bfin-uclinux-ldr -l -b 57600 u-boot.ldr /dev/ttyUSB0 && kermit -l /dev/ttyUSB0 -b 57600 -C connect

 

Loading LDR u-boot.ldr ... OK!

Opening /dev/ttyUSB0 ... OK!

Configuring terminal I/O ... OK!

Trying to send autobaud ... OK!

Trying to read autobaud ... OK!

Checking autobaud ... OK!

Autobaud result: 57600bps 23.961mhz (header:0xBF DLL:0x1A DLH:0x00 fin:0x00)

Sending blocks of DXE 1 ... [10/10] (100%)[board said: -թU��]

[board said: ������]

[board said: �ʝ  �]

[board said:   0��%]

[board said:  ��4U�]

[board said:  ��e�]

[board said: WԪK� ]

[board said: " ��$ ]

[board said: ��F� ]

[board said: $D� ��]

[board said: ��$7��]

[board said: %�% �]

[board said: ZD��-]

[board said: �)���:]

[board said: (1

               0

                ]

[board said: ��r$]

[board said: � � h]

[board said: �6�Ҡ]

[board said:  1

               -��]

[board said:  F1     ]

[board said: ��$ ��F]

[board said: �   �]

[board said: %&���I]

[board said:

              1Ҡ]

[board said: ͑%j]

[board said: ��� F�]

[board said: $ �    ��]

[board said: �    � ]

[board said: �\ :h)]

[board said: �� 3��]

[board said: -��   ]

[board said:

             ��5� ]

[board said: �ي5(]

[board said: ͳ����]

[board said: :�03�]

[board said: ��0�]

[board said: �ɣ?��]

[board said: �c4h�0]

[board said: ]

[board said: ���0]

[board said: b���]

[board said:  F�$ �]

[board said:  ��]

OK!

You may want to run minicom or kermit now

Quick tip: run 'ldr <ldr> <tty> && minicom'

Connecting to /dev/ttyUSB0, speed 57600

Escape character: Ctrl-\ (ASCII 28, FS): enabled

Type the escape character followed by C to get back,

or followed by ? to see other options.

----------------------------------------------------

 

Still no contact with the board afterwards.

 

I thought the early debug outputs should get printed in a nice way, but for some reason they don't.

 

Any ideas why?

 

Sorry, I also forgot to mention what versions of u-boot and toolchain we use (should be latest release):

 

u-boot 2009R1.1-RC1

toolchain 2009r1.1_rc2 (with patch from thread 37514 as we run Ubuntu 9.10 and use FTDI stuff)

 

/Martin

QuoteReplyEditDelete

 

 

2010-06-18 11:15:37     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Mike Frysinger (UNITED STATES)

Message: 90425   

 

when you say "no contact afterwards", is it because you expect u-boot to show something ?  it wont until you type something into the console.

QuoteReplyEditDelete

 

 

2010-06-19 01:43:31     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Martin Blomberg (SWEDEN)

Message: 90434   

 

Hi,

 

what i meant was no response when typing in the kermit session after having transferred ldr. I would expect the prompt to appear then.

 

I guess the above output from the board just after transfer does not really say anything, or?

 

I looked into the u-boot code, and there seems to be debug outputs like 'A', 'B', 'C' etc. so my guess was that you could get an indication how long u-boot had executed based on the output somehow.

 

/Martin

QuoteReplyEditDelete

 

 

2010-06-19 13:16:58     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Mike Frysinger (UNITED STATES)

Message: 90464   

 

the single letter output only comes up when loading the first block (and that is the only block that loads into L1).  after that, you get full sentences as to what is going on, but things are executing out of SDRAM.

 

you've never really said how you selected the SDRAM timings which you programmed into u-boot.  the wiki page helps with that:

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

QuoteReplyEditDelete

 

 

2010-06-22 08:41:51     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Martin Blomberg (SWEDEN)

Message: 90533   

 

Hi,

 

we used the ADI spreadsheet referred to in the SDRAM wiki page, together with the SDRAM data sheet. Btw, this is our second custom blackfin board. The first one was a bf527 board, and used the same (but smaller) SDRAM. Our settings worked fine on that board, and they also do on our bf526 ezbrd as mentioned above.

 

Anyhow, instead of basing our board configuration on our "old" bf527 board, we today tried to utilize the bf526 ezbrd config as much as possible. And now we seem to get somewhere. At least we get ABCDEF output from the board during .ldr loading, see below.

 

mblomberg@SVVARRDPROJ01:~/svn/external/u-boot/modified/u-boot$ bfin-uclinux-ldr -l -b 57600 u-boot.ldr /dev/ttyUSB0 &\

& kermit -l /dev/ttyUSB0 -b 57600 -C connect

Loading LDR u-boot.ldr ... OK!

Removing stale lock '//var/lock/LCK..ttyUSB0'

Opening /dev/ttyUSB0 ... OK!

Configuring terminal I/O ... OK!

Trying to send autobaud ... OK!

Trying to read autobaud ... OK!

Checking autobaud ... OK!

Autobaud result: 57600bps 36.864mhz (header:0xBF DLL:0x28 DLH:0x00 fin:0x00)

Sending blocks of DXE 1 ... [2/10] (20%)[board said: AB]

[board said: CDEF�]

OK!

You may want to run minicom or kermit now

Quick tip: run 'ldr <ldr> <tty> && minicom'

Connecting to /dev/ttyUSB0, speed 57600

Escape character: Ctrl-\ (ASCII 28, FS): enabled

Type the escape character followed by C to get back,

or followed by ? to see other options.

----------------------------------------------------

 

I guess we are on track now, as we can troubleshoot this further by enabling more debug output.

 

Thanks a lot for your help!

/Martin

QuoteReplyEditDelete

 

 

2010-06-23 01:54:12     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Mike Frysinger (UNITED STATES)

Message: 90551   

 

so it looks like you're crapping out when reprogramming the VR/PLL.  i would double check your VR_CTL settings then.  the default ones u-boot sets up might not be appropriate for you which means you should define CONFIG_VR_CTL_VAL yourself.

 

when you break in with JTAG, where is the PC ?  you could load the bootrom symbols in VDSP to get a better idea.  although, if the VR/PLL is crapping out, you might not be able to access it with JTAG at all.

QuoteReplyEditDelete

 

 

2010-06-23 09:42:51     Re: u-boot loading problem: u-boot.ldr blocks not written to SDRAM

Martin Blomberg (SWEDEN)

Message: 90562   

 

You're quite right, we cannot access the board with JTAG after trying to reprogram VR/PLL.

 

However, we noticed today that our external VR only delivers 1.0V core voltage, which according to the datasheet is too low. So we guess this may be the reason for the problem with VR/PLL reprogramming.

 

We will try to replace it with a VR delivering 1.3V asap.

 

/Martin

Attachments

    Outcomes