Correct me if I am wrong, but would not this code :
int mips_ejtag_fastdata_scan(struct mips_ejtag *ejtag_info, int
write_t, uint32_t *data)
{
struct jtag_tap *tap;
+ uint8_t r[4];
+
tap = ejtag_info->tap;
assert(tap != NULL);
@@ -357,10 +367,16 @@ int mips_ejtag_fastdata_scan(struct mips_ejtag
*ejtag_info, int write_t, uint32_
}
else
{
- fields[1].in_value = (uint8_t *) data;
+ fields[1].in_value = r;
}
jtag_add_dr_scan(tap, 2, fields, TAP_IDLE);
+
+ if (!write_t)
+ {
+ *data = buf_get_u32(fields[1].in_value, 0, 32);
+ }
+
keep_alive();
return ERROR_OK;
lead to the NULL pointer dereference in the time of jtag data scan
execution (r is a automatic variable, local to the
mips_ejtag_fastdata_scan() function) ?
BR,
Drasko
On Mon, May 30, 2011 at 4:34 PM, Mahr, Stefan <[email protected]> wrote:
> The target endian issue still worries me. How the target memory is
> represented in host memory? Is it in physical byte order? When
> using a uint8 array, buf[0] is same value on target and host memory,
> isn't it?
>
> If so,
> mips32_pracc_read_u32
> mips32_pracc_read_mem32
> mips32_pracc_read_mem16
> etc.
> return wrong byte order on little endian hosts.
>
> Attached you will find a patch as discussion base. I tested all four
> combinations with BE and LE Host against BE and LE target.
> Commands tested: mdb, mdh, mdw, mwb, mwh, mww, dump_image and load_image
>
> fast_load does not work for me. But it also did not work before, so I is
> maybe a different issue.
>
> Since I have no access to EJTAG DMA capable devices, I could not test it.
>
>
> BR,
> Stefan
>
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
