2010-04-20 16:51:44     BF52x JTAG gnICE+, can't detect flash

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

2010-04-20 16:51:44     BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88669   

 

Just bringing up a board with a BF52x and single NAND chip.  I have a gnICE+ connected to the JTAG port on the board, and am using the UrJTAG 0.8 #1120 build of bfin-jtag.

 

Fairly new to JTAG, so please be patient

 

I'm trying to use JTAG to flash the NAND with the initial uClinux image, as that would be faster than using the serial port (USB will likely not be on the board).

 

This is an example session of what I'm seeing.  I have tried both with "initbus bf526_ezkit" and "initbus bf52x", same result.

 

Type "help COMMAND" for details about a particular command.

jtag> cable gnICE pid=F001

Connected to libftdi driver.

jtag> detect

IR length: 5

Chain length: 1

Device Id: 00010010011111100100000011001011 (0x00000000127E40CB)

  Manufacturer: Analog Devices

  Part(0):         BF526

  Stepping:     1

  Filename:     /opt/uClinux/bfin-uclinux/bin/../share/urjtag/analog/bf527/bf527

jtag> initbus bf526_ezkit

jtag> print

No. Manufacturer              Part                 Stepping Instruction          Register                      

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

   0 Analog Devices            BF526                1        BYPASS               BR                            

 

Active bus:

*0: Blackfin BF526 EZ-KIT board bus driver via BSR (JTAG part No. 0)

reading external memory not supported

Error in bus area discovery at 0x00000000

jtag> writemem 0x200000 0x40000 ~/uImage.pad                        

reading external memory not supported

Error: Bus width detection failed

 

Also, what does the "reading external memory not supported" mean?

 

From all the reading/surfing I've done in google and the forums, I can't see what I'm doing wrong.  It could be a hardware problem, but I'm not sure.

 

Can somebody please point me in the right direction to understand how to troubleshoot this?

 

Cheers!

RP

QuoteReplyEditDelete

 

 

2010-04-20 17:00:16     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88671   

 

urjtag supports parallel flash only.   NAND is not parallel flash and thus you will have to use u-boot to program it.

QuoteReplyEditDelete

 

 

2010-04-20 20:27:18     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88678   

 

Thanks, Mike.

 

Question:  With a 522 (no USB) + NAND only, what's the best method for mass production to install the uClinux image?

 

RP

QuoteReplyEditDelete

 

 

2010-04-20 20:51:40     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88679   

 

Mike,

 

Another question:  Would it be possible to use JTAG/gnICE to transfer the image to SDRAM?

 

RP

QuoteReplyEditDelete

 

 

2010-04-20 22:06:36     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88680   

 

most people get the parts pre-flashed before it's even on the board, or they flash the parts directly

 

QuoteReplyEditDelete

 

 

2010-04-20 22:07:47     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88681   

 

please read the documentation:

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

QuoteReplyEditDelete

 

 

2010-04-20 22:42:44     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88686   

 

Thanks, Mike.  I did look at that link.

 

Let me take a step back and ask if this process is unreasonable:

 

    Boot into u-boot and pause boot at bfin> prompt

    Connect via JTAG and load uClinux into SDRAM

    Go back to u-boot and use u-boot to falsh NAND

 

So, in essence I've switched the serial transfer of the image to JTAG, but otherwise the programming process is the same.

 

When I read that wiki entry earlier, here are some things that made me think I couldn't do this, or that document wasn't on the right track:

 

    In my scenario above, I didn't see why I needed to run special code (which made me think I was looking in the wrong place)

    I guess I need to figure out how to convert the image (uImage.pad) to an elf file, right?

 

Apologies if I'm in left field, just trying to get started.

 

RP

QuoteReplyEditDelete

 

 

2010-04-20 22:47:28     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88687   

 

you've been talking about a system that doesnt even have u-boot in NAND yet.  *something* needs to initialize external memory and such.  the processor doesnt boot up with these things running.  thus you need to use the document i mentioned to bootstrap the part and get u-boot running in memory.

 

as for transferring arbitrary other files to external memory once running u-boot, that'll be the same net result as using u-boot's loady.  sometimes i use that to quickly copy a kernel to external memory.

 

turning a uImage into an ELF makes no sense.  the whole point of the uImage is that it's a reduced file that u-boot can boot.  please read the documentation:

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

QuoteReplyEditDelete

 

 

2010-04-20 23:17:04     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88688   

 

Mike,

 

Sorry I wasn't more clear.  As I said, I am new to this process, so thanks for your patience.  I was trying to just express the technical issue w/o enough information:

 

"... you've been talking about a system that doesnt even have u-boot in NAND yet.  ..."

 

We do have U-Boot installed.  We have to load about 50-60 boards, and were trying to find a faster method than serial to load the uClinux image.

 

"...as for transferring arbitrary other files to external memory once running u-boot, that'll be the same net result as using u-boot's loady.  sometimes i use that to quickly copy a kernel to external memory...."

 

That's exactly what we are trying to do, transfer quickly so U-Boot can program.

 

"...turning a uImage into an ELF makes no sense.  the whole point of the uImage is that it's a reduced file that u-boot can boot.  please read the documentation:

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

 

The only reason I mentioned ELF was that was what most of the references were on gdbproxy.  One of the tools I tried (insight, I think) only loaded elf, so I was thinking that was what I had to use.

 

I think what I'm missing is the technical method for transfering my image to the SDRAM in the target.  I got gdbproxy up and going, but couldn't find the commands from either gdb or insight to transfer the image.  I looked through all the urjtag commands.  As you can see in my initial post, my first attempt was to use the writemem command, which seemed like what I wanted.  However, that gives the: "reading external memory not supported, Error: Bus width detection failed".

 

Thanks!

RP

QuoteReplyEditDelete

 

 

2010-04-20 23:22:08     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88689   

 

gdb doesnt care about the file format.  simply run gdbproxy, connect to it with gdb, and use the "restore" command.

 

QuoteReplyEditDelete

 

 

2010-04-21 18:01:36     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88740   

 

Hi Mike,

 

I'm getting closer, but still missing something (boy, I'm hoping this isn't a stooping noob question).

 

I feel this process should work, so can you advise what I'm missing?

 

Our process over serial is:

 

    Power up system

    u-boot: "<enter>"   (get bfin> prompt)

    u-boot: "nand erase 0x40000 0x7fC0000"

    u-boot: "loadb 0x50000"                (note: i was given these offsets, they don't make sense to me yet)

    (transfer the file via kermit)

    u-boot: "nand write 0x50000 0x40000 0x600000"               (ditto)

 

What I'm trying to do is replace step #5 with sending over JTAG.  Here are the step I'm doing:

 

    Power up system

    u-boot: "<enter>"   (get bfin> prompt)

    u-boot: "nand erase 0x40000 0x7fC0000"

    sudo /opt/uClinux/bfin-uclinux/bin/bfin-gdbproxy bfin --connect="cable gnICE pid=F001"

    /opt/uClinux/bfin-uclinux/bin/bfin-uclinux-gdb

    gdb: target remote :2000

    gdb: restore uImage.pad binary 0x50000                  (note: i was given these offsets, they don't make sense to me yet)

    gdb: continue

    u-boot: "nand write 0x50000 0x40000 0x600000"               (ditto)

 

Sort-of Working:

 

$ /opt/uClinux/bfin-uclinux/bin/bfin-uclinux-gdb

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=bfin-uclinux".

(gdb) target remote :2000

Remote debugging using :2000

0x01f98f28 in ?? ()

(gdb) c

Continuing.

 

So, if I connect via JTAG but don't load the file, it seems to not bother u-boot.  However:

Not Working:

 

$ /opt/uClinux/bfin-uclinux/bin/bfin-uclinux-gdb

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=bfin-uclinux".

(gdb) target remote :2000

Remote debugging using :2000

0x01f98f28 in ?? ()

(gdb) restore uImage.pad binary 0 0x50000 0x5000000

Restoring binary file uImage.pad into memory (0x50000 to 0x500000)

(gdb) c

Continuing.

 

Program received signal SIGTRAP, Trace/breakpoint trap.

0xef426a2c in ?? ()

(gdb)

 

NOTE:  uImage.pad is uImage.gz.initramfs padded to an even megabyte boundry.

 

Am I using the restore command correctly?  In left field?

 

Thanks!

RP

QuoteReplyEditDelete

 

 

2010-04-21 22:53:28     Re: BF52x JTAG gnICE+, can't detect flash

Sonic Zhang (CHINA)

Message: 88742   

 

I think you made a mistake. Please try

 

restore uImage.pad binary 0x50000

QuoteReplyEditDelete

 

 

2010-04-22 07:45:36     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88764   

 

Thanks, Sonic, but have tried that as well.

 

After some more debugging, here's what seems to be happening:  After the restore command, the entire memory is filled with '60 00 00 00' words (starting at address 0, not address 0x50000).  I did a :

 

dump memory raw.dat 0 0x60000

 

before and after the command and then ran hexdiff.  Before, I can see normal code.  After, I see the above word above filling memory.

QuoteReplyEditDelete

 

 

2010-04-22 10:16:42     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88767   

 

does 'mtest' in u-boot work ?  what if you load only a few bytes ?

 

i tested loading via gdbproxy on my board and was able to restore a few meg file fine with something like:

restore foo binary 0

 

then checked it with u-boot's 'crc 0 ....'

QuoteReplyEditDelete

 

 

2010-04-22 10:17:35     Re: BF52x JTAG gnICE+, can't detect flash

Robin Getz (UNITED STATES)

Message: 88768   

 

Reggy:

 

Always check the mainline docs:

 

http://sourceware.org/gdb/current/onlinedocs/gdb/Dump_002fRestore-Files.html#Dump_002fRestore-Files

 

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

 

restore filename [binary] bias start end

 

    Restore the contents of file filename into memory. The restore command can automatically recognize any known bfd file format, except for raw binary. To restore a raw binary file you must specify the optional keyword binary after the filename.

 

    If bias is non-zero, its value will be added to the addresses contained in the file. Binary files always start at address zero, so they will be restored at address bias. Other bfd files have a built-in location; they will be restored at offset bias from that location.

 

    If start and/or end are non-zero, then only data between file offset start and file offset end will be restored. These offsets are relative to the addresses in the file, before the bias argument is applied.

 

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

 

    So, your command "restore uImage.pad binary 0 0x50000 0x5000000" is going to store things at memory location 0, and the start/end are the offsets of the file "uImage.pad". If that's not what you want - starting at 320k (or if your file is too short - 80Meg?) - I'm not sure what the expected behaviour is.

 

    -Robin

QuoteReplyEditDelete

 

 

2010-04-22 10:57:17     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88772   

 

OK, after much pain an agony, I've found some more key information:

 

    It *appears* that the restore command BIAS parameter is used as a hex value regardless of if your prefix

    If I do a "restore uImage.pad binary 0x50000 0 100", 100 bytes get written to 0x327684

    If I do a "restore uImage.pad binary 50000 0 100", 100 bytes get written where I want them to go

    If I do a "restore uImage.pad binary 50000", the memory is filled with '60 00 00 00'.  (note: Image size is 0x500000)

    If I do a "restore uImage.pad binary 50000 0 0x500000", the memory is filled with '60 00 00 00'.

 

Any thoughts?

QuoteReplyEditDelete

 

 

2010-04-22 14:07:44     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88782   

 

Addition:  Attached is the stderr when running gdbproxy in --debug mode.  The two commands issued to this were:

 

(gdb) target remote :2000

Remote debugging using :2000

0xef000000 in ?? ()

(gdb) restore uImage.pad binary 50000

Restoring binary file uImage.pad into memory (0xc350 to 0x50c350)

 

stderr.log

QuoteReplyEditDelete

 

 

2010-04-22 14:52:51     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88783   

 

if the processor is at 0xef000000, then it reset and external memory isnt going to work.  you must first let u-boot boot up so that it initializes external memory for you.

QuoteReplyEditDelete

 

 

2010-04-22 15:01:00     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88784   

 

sorry, but i cant reproduce that behavior.  the numbers are interpreted as decimal if you dont use a leading 0x, and hex if you use a leading 0x

 

really though i dont know why you're bothering with the START/END arguments in the first place.  you want to load the entire file into memory, so just specify the address you want to load it:

restore uImage.pad binary 0x1000

 

that will load the whole uImage.pad into memory at address 0x1000

QuoteReplyEditDelete

 

 

2010-04-22 15:03:38     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88785   

 

also, in one of your examples, you used way too many zeros:

(gdb) restore uImage.pad binary 0 0x50000 0x5000000

 

so to keep things simple, i'd simply load to address 0 ... using too many zeros wont screw things up then

QuoteReplyEditDelete

 

 

2010-04-22 17:45:21     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88786   

 

Mike,

 

Is there a limit to the size that restore can send?  If I try and chunk the kernel into smaller pieces, it *appears* to operate better (still don't have it working fully yet).

QuoteReplyEditDelete

 

 

2010-04-22 18:08:43     Re: BF52x JTAG gnICE+, can't detect flash

Mike Frysinger (UNITED STATES)

Message: 88787   

 

there should be no limitation on the jtag/gdb side.  obviously you cant write to memory that doesnt exist, or isnt initialized, or on top of u-boot itself.

QuoteReplyEditDelete

 

 

2010-04-23 09:50:31     Re: BF52x JTAG gnICE+, can't detect flash

Reggy Perrin (UNITED STATES)

Message: 88818   

 

Mike,

 

I now have this working.  Some things I had to do (not sure why):

 

    I have to chunk the restore in 64K blocks.  Any size greater that 64K locks up uboot.  Could be the version we are using, or something strange in our setup

    One big thing I didn't understand was how the parameters of the restore command work.  Turns out, BIAS is added to START automatically.  I was adding those together

 

Thanks for your help!

Attachments

Outcomes