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?
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.
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?
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:
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!
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?
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.
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.
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!
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?
