2010-01-14 12:44:08     BF518-0.1 UART mode

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

2010-01-14 12:44:08     BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84582   

 

Has anyone been able to get the new revision of BF518 v0.1 to boot using the LDRs created for UART mode?

 

The u-boot package I'm working with is u-boot-2008.10-2009R1_RC3.  I have an EZBRD with a BF518 v0.0 chip on it.  It didn't boot with the 2009R1.1_RC2 distribution of the toolchain, but it did boot and work properly with the nightly snapshot from January 10th, 2010.

 

We created a custom board with 16MB or SDRAM (8Mbit x 16).  We had to request BF518 samples from the factory.  The factory sent us v0.1 parts.  The SDRAM settings are all based on the spreadsheet you can download from this website.  The part we're using is MT48LC8M16LFB4-75M:G TR, and we're using the following settings:

 

#define CONFIG_MEM_ADD_WDTH    9    // column addressing width

#define CONFIG_MEM_SIZE        16    // memory total in MB

#define CONFIG_EBIU_SDRRC_VAL    0x04DC    // 400mhz, 80mhz

#define CONFIG_EBIU_SDGCTL_VAL    (SCTLE | CL_3 | PASR_ALL | TRAS_4 | TRP_2 | TRCD_2 | TWR_2 | PSS)

 

 

#define CONFIG_EBIU_AMGCTL_VAL    (AMCKEN | AMBEN_ALL)

#define CONFIG_EBIU_AMBCTL0_VAL    (B1WAT_15 | B1RAT_15 | B1HT_3 | B1RDYPOL | B0WAT_15 | B0RAT_15 | B0HT_3 | B0RDYPOL)

#define CONFIG_EBIU_AMBCTL1_VAL    (B3WAT_15 | B3RAT_15 | B3HT_3 | B3RDYPOL | B2WAT_15 | B2RAT_15 | B2HT_3 | B2RDYPOL)

 

 

The hardware all looks to be operating properly.  The processor just never boots up.  It's acting just like the development board was before we got the proper toolchain.  I haven't tried the latest nightly build of u-boot due to the porting that would be required, so I thought I would ask here first before diving in head first.

 

For the record, all combinations that I have tried do compile successfully, and they all seem to download via the UART properly, though the 0.1 version of the chip finishes its download much quicker than the 0.0 version.  I don't know if that's an improvement in the chip, or a symtom of my problem.

 

Thanks for any help you can give me.

QuoteReplyEditDelete

 

 

2010-01-14 19:22:56     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84591   

 

I did some more research.  On a transfer that is working properly, the SDRAM data and address lines bounce around happily as the UART data is streamed across the line.  On a transfer that fails, the SDRAM data and address lines never move.  This leads me to believe that one of two things are happening during a failure.  Either the initialization code is not being put in the proper place, or the initialization code is not being created properly.

 

I tested this theory on the development board (BF518F-EZBRD) by uploading an LDR that was built for a different processor.  During this upload, the SDRAM data and address lines were also quiet, and then of course, it failed to boot up.

 

So my questions now are where in the code should I be looking to debug the bf518-0.1 initialization code, and where does it get determined as to what location it will be placed into internal RAM?

QuoteReplyEditDelete

 

 

2010-01-14 22:08:36     Re: BF518-0.1 UART mode

Sonic Zhang (CHINA)

Message: 84592   

 

You should use the same release of toolchain, uboot and kernel other than 2009R1.1_RC2 toolchain with 2009R1_RC3 uboot.

QuoteReplyEditDelete

 

 

2010-01-14 23:27:27     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 84593   

 

ive tested the 2009R1 and 2009R1.1 release on a bf518f-ezbrd with 0.0 and 0.1 silicon.  both work fine.

 

do you have JTAG ?  you should set a hardware breakpoint on the start of L1 to make sure at least the initcode is being loaded and executed.  you can use the the -p option with ldr-utils to manually control when the next block is sent over the UART.

 

if not, you might want to try the steps here related to early serial debugging:

http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:debugging

QuoteReplyEditDelete

 

 

2010-01-15 13:23:22     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84656   

 

I switched back to the 2009R1.1_RC2 toolchain and got u-boot working on the BF518F-EZBRD after I ran a "make mrproper" and then recompiled.  Unfortunately, I still couldn't get my custom board to boot using the same method.

 

I'm using the DEBUG_EARLY_SERIAL define, but I'm not seeing anything on the port.  Initial communication is successful, so I do know that the UART is connected properly:

 

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

Opening /dev/ttyS3 ... OK!

Configuring terminal I/O ... OK!

Trying to send autobaud ... OK!

Trying to read autobaud ... OK!

Checking autobaud ... OK!

Autobaud result: 115200bps 29.491mhz (header:0xBF DLL:0x10 DLH:0x00 fin:0x00)

Sending blocks of DXE 1 ... OK!         

 

 

Unfortunately, I don't have JTAG, so I'm out of luck there.

 

I'm going to remove the USB-to-UART chip (CP2102) I have on the custom board and bypass it by connecting the lines up directly to a serial port...hoping that might help.

QuoteReplyEditDelete

 

 

2010-01-15 14:33:15     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 84658   

 

you should have seen output after the very first block was loaded (ldr-utils creates a thread to monitor output from the board).  if that didnt work, the init block might be really screwed up, or the Blackfin OTP settings are broken.

 

you've defined CONFIG_UART_CONSOLE to the right value (0) ?

QuoteReplyEditDelete

 

 

2010-01-15 15:57:48     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84659   

 

Yes, CONFIG_UART_CONSOLE is set to 0.

 

I'll take a closer look at the circuitry involved with powering the OTP on my custom board and compare it with the EZBRD...perhaps I missed something or got something wrong.

QuoteReplyEditDelete

 

 

2010-01-15 19:37:32     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84660   

 

I removed the USB-to-UART chip off of the custom board, and the initialization code now runs using a normal RS232 interface.  With CONFIG_DEBUG_EARLY_SERIAL turned on, I now see the "ABCD..., etc." on the custom board, however the system does fail to boot.  Can you take a look at my SDRAM settings and tell me if I'm doing something incorrectly for the device?  Or is there a way to tell where the code stops?  What function should I be debugging?  Thanks.

QuoteReplyEditDelete

 

 

2010-01-15 19:43:20     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 84661   

 

if you only see the ABCD... list and it ends with a '>\n', then it means the initcode did what it was told -- it has programmed all of the clocks and such.

 

if you get no info after that point, and you dont have JTAG, about all you know is that the bootrom loaded the rest of the blocks given to it and then jumped to external memory.  the first instructions in external memory should have also written some things to the UART.  if that didnt happen, the most likely candidate is bad SDRAM timings.

 

this page might help in checking things:

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

QuoteReplyEditDelete

 

 

2010-01-19 15:52:02     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84771   

 

During programming, I've checked and none of the control lines for the SDRAM are being toggled at all (nor the address or data lines).  That led me to believe that the SDRAM controller was not enabled, so I checked in code (using some if statements filled with different while(1)'s printing stuff to the ASCII port) after the SDRAM registers are set up and EBE in SDBCTL along with SCTLE in SDGCTL are both set as they should be for the external controller to operational.

 

Do you have any suggestions for what other registers I should be looking at to diagnose this problem?

QuoteReplyEditDelete

 

 

2010-01-19 15:56:58     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 84772   

 

i'd suggest you modify the initcode.c so that at the end, it goes into an infinite loop that does:

- write some bytes to a known memory location (like address 0)

- write a char to the uart

 

then test loading just the first block onto a known working board and make sure you see things toggle, then try again on a non-working board.  if things are still failing, you most likely have a hardware issue and you'll get better responses here:

http://ez.analog.com/

 

we tend to focus on the software stack while that website tends to focus on low level hardware

QuoteReplyEditDelete

 

 

2010-01-19 18:06:13     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84777   

 

I wrote some code that sent values out to the SDRAM from 0x0000 to 0xF000, read it back, and then sent out a 'P' or 'F' as each value was returned passed or failed, respectively.  This all worked properly, and I see the control lines toggling as expected on my custom board.  When I remove that code, the SDRAM again falls silent.

 

After the end of initcode(), what should be happening?  What section of code should be running, and what might be causing this to not happen?  What makes the code actually start executing from address 0x0000?  I'm not seeing where that occurs...

 

It seems like the bootloader is ignoring are the UART data after initcode starts running.

QuoteReplyEditDelete

 

 

2010-01-19 18:08:18     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84779   

 

> It seems like the bootloader is ignoring are the UART data after initcode starts running.

 

Sorry, meant to say "all the UART data".

QuoteReplyEditDelete

 

 

2010-01-19 18:15:40     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 84780   

 

please be careful with terms as you're covering multiple pieces.  technically the Blackfin on-chip bootrom can be considered a bootloader, but when you use the term "bootloader" to also refer to u-boot, things get confusing.  so when talking about booting over the UART, it is the "bootrom" that is processing the LDR over the UART and copying things to the right place (i.e. external memory -- SDRAM).

 

once the LDR has finished loading, then u-boot (the "bootloader") takes over and starts executing from external memory.

 

once the initcode finishes, the processor should have all of its clocks fully/properly programmed (SCLK/CLK/SDRAM).  the only thing left to do is copy and jump to u-boot.

 

it's hard to say where things are getting stuck because you dont have JTAG.  i dont know how you're loading over the UART, but if you start transmitting the 2nd LDR block before the initcode is done processing, the bootrom will get out of sync and panic (because you overflowed the UART).  you might want to check the HWAIT signal you've specified as well as increase the pause (default is 1 second, see the -D option) as well as decrease the baud to 57600.

QuoteReplyEditDelete

 

 

2010-01-20 15:15:49     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84865   

 

I found some consistency finally.  If I use a CONFIG_MEM_SIZE of 64, the SDRAM control signals toggle and the development board boots normally.  If I use a CONFIG_MEM_SIZE of 32 or 16, the SDRAM control signals never toggle and the development board fails to boot.

 

On my custom board, the same thing holds true.  If I set a CONFIG_MEM_SIZE of 64, the SDRAM control signals toggle, but in this case, it fails to boot because I only have 16MB of RAM on-board.  With any other CONFIG_SIZE_MEM setting, the SDRAM control signals never toggle.

 

Have you seen this before?  Does the controller require a 64MB part to operate properly?  I was under the impression that memory down to the size of 16MB was okay.

 

On a side note, changing CONFIG_MEM_ADD_WDTH to 8, 9, or 10 affected proper operation but didn't stop the control signals from toggling.

 

Also when I tried to set CONFIG_EBIU_SDBCTL_VAL in the config header (instead of using CONFIG_MEM_ADD_WDTH and CONFIG_MEM_SIZE), I get multiple errors like the following:

 

start.S: 187: Error: reloc 582 not supported by object file format

 

The error may be expected, but I thought I'd mention it.  Thank you very much for all the help you've given me so far.  I know it must be very difficult to try and diagnose this from afar.

QuoteReplyEditDelete

 

 

2010-01-22 06:17:48     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 84992   

 

while we havent tested the BF51x specifically, there should be no hard requirement like the datasheet says -- 16meg should work fine.  but the only BF51x hardware i have are the BF518-EZBRDs and they obviously are all 64megs.

 

to be clear, when you talk about "sdram lines toggling", you're referring to your initcode doing a read/write loop of sdram right ?  it'd be best if we could keep the discussion wholly limited to loading the first LDR block (initcode) and basically ignore u-boot (since the initcode is basically a small standalone bootstrap app).

 

setting the EBIU_SDBCTL directly does not mean you can skimp on defining the other values.  you either define _all_ u-boot things yourself, or you need to define the base mem add_wdth/size helpers so everything else can be defined automatically.  the start.S error is not a bug in the build system.

QuoteReplyEditDelete

 

 

2010-01-22 14:02:57     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 84995   

 

When I talk about "sdram lines toggling", I'm referring to when the PC is downloading the LDR file to the SDRAM (after the initcode block...around 30% and on).

 

No matter what setting I do, the initcode always runs and will toggle the sdram lines with my custom code.  I can see all the text coming out using the early uart configuration.  I'm passed that issue.  The problem I'm having now involves loading the rest of the code starting at 0x0.  That is where my previous statements come into play.  CONFIG_MEM_SIZE of 64 is the only setting (and 128 works too now that I just tested it) that causes the LDR to be loaded into the SDRAM...anything less than that, and there is no communication with the SDRAM during the download of the LDR file.  This is consistent whether using our custom board or the BF518F-EZBRD (and its standard configuartion file).

 

I haven't yet found anything obviously different between using 64 or 16, but I'm still looking through the code.

QuoteReplyEditDelete

 

 

2010-01-22 17:09:49     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 84999   

 

i think we've taken it about as far as we can.  buy an ICE.  they're easily less than $100.

QuoteReplyEditDelete

 

 

2010-02-09 14:10:32     Re: BF518-0.1 UART mode

Doug Brainard (UNITED STATES)

Message: 85857   

 

Turns out we needed to manually delete the u-boot.lds file because it was not updated during builds or removed during "make mrproper".  The LDR was trying to locate u-boot out of our address range (it said we had 64MB but we really only had the 16MB).

 

Now that we got past that issue, we've been making steady progress...booting from SPI flash now and everything looks good.  Thank you for all your help.

 

Doug

QuoteReplyEditDelete

 

 

2010-02-09 15:23:18     Re: BF518-0.1 UART mode

Mike Frysinger (UNITED STATES)

Message: 85859   

 

thanks, i'll double check the latest code to make sure that gets removed

QuoteReplyEditDelete

Attachments

    Outcomes