mips: load fast data transfer handler code with mips32_pracc_write_mem()

Currently the code is loaded calling mips32_pracc_write_mem_generic().
Cache synchronization is not performed.
If configured as write back cache there is no chance to execute the
handler. If configured as write through cache and the cache
lines written to are not cache resident (I-side cache miss) may work.
The patch makes possible to execute the handler in a cached active
memory segment (mainly from KSEG0), but nothing else. The data
is still loaded without performing cache synchronization, code loaded
may not be executable.
Performance may not be faster. At start, for example, the code resides in
main memory, not in cache, and the core must transfer code from
memory. We can really modify the code to force a wait for the first
transfer like we do with start and end addresses, making sure the code
is cache resident for the rest of the queued transfers.
This can also may happen if we execute code (greater than the I cache size)
and the handler code is evicted from the cache.
Code tested on ar7241.

Change-Id: Iffdb4dae108b872fef0e7bacc5ea99649cdc1630
Signed-off-by: Salvador Arroyo <sarroyofdez@yahoo.es>
Reviewed-on: http://openocd.zylin.com/1564
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>

src/target/mips32_pracc.c

@@ -986,7 +986,7 @@ int mips32_pracc_fastdata_xfer(struct mips_ejtag *ejtag_info, struct working_are
 
 	/* write program into RAM */
 	if (write_t != ejtag_info->fast_access_save) {
-		mips32_pracc_write_mem_generic(ejtag_info, source->address, 4, ARRAY_SIZE(handler_code), handler_code);
+		mips32_pracc_write_mem(ejtag_info, source->address, 4, ARRAY_SIZE(handler_code), handler_code);
 		/* save previous operation to speed to any consecutive read/writes */
 		ejtag_info->fast_access_save = write_t;
 	}