SparkFun Forums

[gadgetmind]

Hi folks,

I'm planning to use a Wiggler and openOCD to let me "unbrick" a board that contains a Sigma Designs EM8511 and a brace of Samsung K8D1716UTC

Problem 1 is accessing the EM8511's JTAG pins, Problem 2 is generating an openOCD config file for a chip where I don't have a datasheet (but I do have Linux source and can glean much from this), but let's move straight to Problem 3.

The Samsung flash is CFI compliant but
Address 13H
Primary OEM Command Set
0002H

I guess that means it only understands AMD/Fujitu commands and so openOCD won't work with it as-is?

How easy will it be for me to modify openOCD to support this?

(And now the cheeky question!)
Any alternative cheap/free software that I should consider?

Thanks

Ian

[Dominic]

I've received an unfinished patch that would add support for the AMD command set, but haven't had time to look at it yet, nor do I have a AMD compatible device to test with.

If you'd like to work on this, I can send you what I've got, so you have something to start with. The changes shouldn't be too difficult, but maybe reading of several datasheets would be necessary, to figure out differences between implementations of the AMD command set.

Regards,

Dominic

[gadgetmind]

OK, sounds good. But let's hold off for a while as doubts are now being cast on whether the board I'm attacking actually exposes the processor's JTAG.

Ian

[gadgetmind]

I've found seven pads right next to the processor that are labelled "D" - D for debug. Let's hope so!

Can I use OpenOCD to do *very* low level clocking of signals on TCLK and TMS while I monitor with a scope to find TDO? Or should I try and find/write some software that hits my wiggler at this level?

Thanks

Ian

[Dominic]

You could use the OpenOCD for that. On startup, it pulses TCK 7 times with TMS held high (making sure the tap is in Test-Logic-Reset), and then validates the integrity of the JTAG scan chain. It initiates an instruction register scan of n bits, where n is the size of all instruction registers in the chain plus 2, and verifies the data scanned out.

The sequence of TMS during the TCK cycles (->L->H) looks like this:
HHHHHHH -> to TLR
HHLHHLL -> to SI
LLLLLHL -> to PI (scanning TDI/TDO during LLLLLH)
HHHHHHH -> to TLR

On a chain with a single ARM device, the scanned data looks like this:
<2 bit prologue><4 bit IR register>
<b11><b1111>
the expected data looks like this:
<b11><b0001>

Regards,

Dominic

[gadgetmind]

Many thanks for that info. I guess I just need to now get openOCD to keep doing that as I go through all 7x6 combinations of TCLK and TMS while monitoring the remaining 5 pins with a scope for TDO!

After that, finding TDI should be childs play!

Ian

[garlicman]

Hi Dominic,

Can you send me that "unfinished" patch so I can take a look at it? I just happen to work on such a project right now with a SPANSION based flash chip (command set 2).

Thanks!

PS. I have r82 at the moment. Do I need to grab the latest version?

[Dominic]

You should always work with the latest sources. Unfortunately, the code I've got is already a bit dated, it is based against revision 62.

I've uploaded it to the project site at Berlios:
http://developer.berlios.de/patch/?func ... up_id=4148

You'll have to check out the sources from SVN with -r62:
svn co svn://svn.berlios.de/openocd/ -r62
then apply the patch, and port it to the current code (HEAD), or directly apply it to HEAD, fixing merge-conflicts manually.

Regards,

Dominic

[garlicman]

Hi Dominic,

Just wondering how fast in your experience with the Intel flash can you program the data to the flash? I did some tweaking on the source code for the command set 2 and it works alright. Just that it took about 39 min to write 39k of data! That is just ... slow ...

Was wondering if this is normal over JTAG.
For my project, I might have to write a small monitor and load it with openocd for flash writing, if this cannot be solved.

Thanks

[Dominic]

Hi,

the CFI code for Intel compatible flashes uses two different approaches:

The slow and painful way uses target->write_memory for every bus access. Especially with USB JTAG interfaces, this is deadly for performance.

The fast way downloads a small handler to target RAM that writes a buffer from RAM to the flash. RAM downloads are already quite fast (35kb/s w/ FT2232), and can be further accelerated by enabling the DCC support (120kb/s w/ FT2232).

The fast method requires a valid "working_area" to be specified, and DCC support requires a reasonably high processor clock, i.e. not the 32kHz slow-clock an AT91 micro uses out of reset.

Depending on your target and its current frequency, the 39 minutes might be "fine", but usually even the slow method does better than that.

Regards,

Dominic

[garlicman]

For anyone following this progress,

I have tested out the patch given by Dominic and it went well for my AM29LV033C chip. Due to the differences in command sets, not every single function layed out in the source files are implemented (i.e. probe, erase checks are left out). Will look into these issues closer a bit later.

Here's a summary of what I did for those of you who are interested in applying the patch.


----------------------------------------------
- I applied the patch manually, meaning a lot of copy-and-paste. The patch file itself was not clean, a lot of debugging code (i.e. the PROGRESS() function) which you wont be needing. Ignore them!
- I ended up modifying the cfi.c and cfi.h files ONLY. So just manually copy the addition codes you found in the patch for these 2 files and paste them into your code base.
- For the following functions, you'll also need to add additional codes to call the cfi_atmel_xxx() functions in the switch statement. This will become "case 2:".

cfi_erase
cfi_protect
cfi_write_word
cfi_write
cfi_probe
cfi_protect_check
cfi_info

- Just for a quick hack, I only tweak the commands sent to the flashrom in these cfi_atmel_xxx() functions. I did not try to make the code fit nicely into OpenOCD and to incorporate all range of flashroms (i.e. there are big differences in programming sequence even among command set 2 flashroms). This will be a huge effort in my opinion.

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

So for those of you who needs a quick solution to your AMD/Spansion/Fujitsu flash programming, just do the above and have fun!

[albert_kurucz]

I did apply the above patches manually just like you.
Later I have noticed, on my Atmel external CFI chip (AT49BV160C) the ID shows 3 (so it goes to the Intel mode programming).

After some tweaks I was finally able to erase the chip.
First I unlocked/erased and wrote the last page only (to be safe).
It all worked good!

Then complete unlock and complete erase.
Still good!

But then writing failed.
Since I have blank external flash chip on the target, OpenOCD does not even connect. I am locked out completely.

The chip is LH75410.
config:
"
#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey A"
ft2232_layout usbjtag
ft2232_vid_pid 0x0403 0xcff8
jtag_speed 5

reset_config trst_and_srst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
jtag_nsrst_delay 333
jtag_ntrst_delay 333

#target configuration
daemon_startup reset

#target arm7tdmi little <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

working_area 0 0x60000000 0x40000 nobackup

#flash configuration
flash bank cfi 1073741824 2097152 2 2 0
"

advice?

[garlicman]

While I was trying to enable the 'working area' for faster native openocd flash writing, I was quite puzzled when openocd tells me that there's no such command (via telnet). Looked through the source code and am pretty sure it is there. Am I missing something here?

[Dominic]

The command is called "working_area" - maybe you missed the underscore?

Regards,

Dominic

[x86processor]

Hi,

I have revision 62 checked out and have applied this patch manually:

http://developer.berlios.de/patch/download.php?id=1352

as stated. But, I don't see a progress.h file. Where is this file? Does it have a #define for the progress() print?

Thanks,

x86