> I bet that they have been deliberatly avoided in these functions
> because of performance penalities...
So it should go like this?
--- a/src/target/mips_ejtag.c
+++ b/src/target/mips_ejtag.c
@@ -339,10 +339,15 @@ int mips_ejtag_init(struct mips_ejtag *ejtag_info)
return ERROR_OK;
}
+
On Mon, May 30, 2011 at 11:32 PM, Mahr, Stefan wrote:
> Yes, you are absolutely right. I overlooked to add jtag_execute_queue().
Problematic with jtag_execute_queue() (as per my understanding) is
that it adds execution delay and should be delayed as much as possible
(i.e. you keep adding things y
> 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) ?
Correction, not NULL pointer, but some trash value pointer from the
no longer valid stack.
>>>
>>> No, buf_get_u3
On Mon, May 30, 2011 at 7:10 PM, Drasko DRASKOVIC
wrote:
> On Mon, May 30, 2011 at 5:47 PM, Mahr, Stefan
> wrote:
>
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) ?
>>> Corr
On Mon, May 30, 2011 at 5:47 PM, Mahr, Stefan wrote:
>>> 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) ?
>> Correction, not NULL pointer, but some trash value pointer from the
>> n
> I did not saw changes to the mips_m4k_write_memory() and
> mips_m4k_read_memory() (where my byte-flip code lives) in the patches
> you presented. Maybe I did not follow carefully...
I talk about the patch I sent a couple of minutes ago.
>> I am not very happy with my crappy patch code, but if
On Mon, May 30, 2011 at 5:34 PM, Drasko DRASKOVIC
> 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) ?
Correction, not NULL pointer, but some trash value pointer from the no
longer valid s
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_fa
On Mon, May 30, 2011 at 5:13 PM, Mahr, Stefan wrote:
>>> fast_load does not work for me. But it also did not work before, so I is
>>> maybe a different issue.
>> Did you tried it with my patches applied, or before ? Because these
>> patches fix fastdata transfer.
>
> I work with HEAD of git reposi
>>> fast_load does not work for me. But it also did not work before, so I is
>>> maybe a different issue.
>> Did you tried it with my patches applied, or before ? Because these
>> patches fix fastdata transfer.
> I work with HEAD of git repository.
Sorry, typo in work area configuration. Now fast
>> fast_load does not work for me. But it also did not work before, so I is
>> maybe a different issue.
> Did you tried it with my patches applied, or before ? Because these
> patches fix fastdata transfer.
I work with HEAD of git repository.
> If you inversed byte order before it comes to the c
On Mon, May 30, 2011 at 4:34 PM, Mahr, Stefan wrote:
> 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.
AFAIK, fastscan don't have to do much with EJTAG DMA. You should
On Mon, May 30, 2011 at 4:34 PM, Mahr, Stefan wrote:
> fast_load does not work for me. But it also did not work before, so I is
> maybe a different issue.
Did you tried it with my patches applied, or before ? Because these
patches fix fastdata transfer.
If you inversed byte order before it comes
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
Hi, I have made a try to add stm32f2xx and st3220e_eval support in the
scripts, but being my first attempt I expect that there might be
something that could do in a better way. Could anyone have a look and
consider if it can be added?
//Magnus
diff --git a/tcl/board/stm3220e_eval.cfg b/tcl/
Hello Sebastien,
Please stay to your convention and use "open" to open functionality
and "init" to init functionality - this is very good idea and used in
transport layer (select, then init), but there is "select" instead of
"open", so maybe we should change all names to "open"..?
Using "init_sub
Hello,
The end goal it's to have a safe state of the used JTAG adapter at the
end of the executable file.
With this patch => Fix: Correctly exit function: ft2232_init when an
error occurred
I wish correct the status at the end of ft2232_init function when an
error occured.
At this moment, in
17 matches
Mail list logo
