Hi Drasko
> Just for the curiosity, n patch 1 :
> + /* mips32_pracc_fastdata_xfer requires uint32_t in host endianness, */
> + /* but byte array represents target endianness */
>
> Where does this comment comes from ? Pure experience ? Can you back it up ?
"mips32_pr
Merged.
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-de
On Tue, May 31, 2011 at 7:33 PM, Øyvind Harboe wrote:
> Any objections?
>
> I haven't looked over it, but I see there has been some discussion on
> this topic.
On a quick look it seems to be OK for me. I do not know about these
callbacks, I did not use them. Andreas would know better.
Stefan can
Hi Stefan,
Just for the curiosity, n patch 1 :
+ /* mips32_pracc_fastdata_xfer requires uint32_t in host endianness, */
+ /* but byte array represents target endianness */
Where does this comment comes from ? Pure experience ? Can you back it up ?
Otherwise, look
Any objections?
I haven't looked over it, but I see there has been some discussion on
this topic.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debug
> Perhaps some cleanup of ancient history is called for?
0002-...(hopefully) fixes the error in mips_ejtag_fastdata_scan.
0001-...endiannes fixes (it was already sent yesterday)
0001-mips-fix-some-more-endian-madness.patch
Description: 0001-mips-fix-some-more-endian-madness.patch
0002
Perhaps some cleanup of ancient history is called for?
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
__
Any recommendation where to put the "mips_le_to_h_u32" callback function?
mips_ejtag.h or binarybuffer.h ?
Why arm_le_to_h_u32 is defined in arm_jtag.h?
A function in helper/binarybuffer.h called "buf_le_to_h_u32" could be used by
both targets.
BR,
Stefan
_
> 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
Merged.
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-de
> The impact is that the code will behave the *same* on big and small
> endian hosts.
Attached patch fixes some more big endian HOST issues.
0001-mips-fix-swapping-if-running-on-big-endian-host.patch
Description: 0001-mips-fix-swapping-if-running-on-big-endian-host.patch
__
On Sat, May 28, 2011 at 2:31 PM, Drasko DRASKOVIC
wrote:
> On Sat, May 28, 2011 at 2:27 PM, Øyvind Harboe
> wrote:
>> Endian host bugfix merged.
>
> What's the impact ? Will mdw now inverse bytes for BE targets ?
> I checked quickly last night on my BE target, mdw was showing good
> order of byt
On Sat, May 28, 2011 at 2:27 PM, Øyvind Harboe wrote:
> Endian host bugfix merged.
What's the impact ? Will mdw now inverse bytes for BE targets ?
I checked quickly last night on my BE target, mdw was showing good
order of bytes - exactly what I wrote in the memory...
BR,
Drasko
Endian host bugfix merged.
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
__
On Fri, May 27, 2011 at 2:26 PM, Mahr, Stefan wrote:
> As said before, please try to set target to little and big endian. You will
> see that nothing happens (for mdw command). If against my expectations you
> see a difference, please describe your test setup.
Exactly, I'll try to do this ASAP. Y
On Fri, May 27, 2011 at 1:27 PM, Mahr, Stefan wrote:
> Please don't mix the two issues. My patch fixes an endianness problem when
> OpenOCD is build for running on a big endian host. For little endian host
> everything works as usual.
What two issues ? I never mentioned LE targets. I am talking
>> I removed swapping in mips_m4k, because for commands like mdw the swapping
>> was already done in target.c. If a target was selected as big endian,
>> swapping was done twice. So setting endianness had no effect. I did not
>> realized that dump_image works different.
> What do you concern under
On Fri, May 27, 2011 at 1:27 PM, Mahr, Stefan wrote:
> My patch fixes an endianness problem when OpenOCD is build for running on
> a big endian host. For little endian host everything works as usual.
Ack.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-343
argets too.
BR,
Stefan
-Ursprüngliche Nachricht-
Von: Drasko DRASKOVIC [mailto:drasko.drasko...@gmail.com]
Gesendet: Freitag, 27. Mai 2011 12:58
An: Øyvind Harboe
Cc: Mahr, Stefan; openocd-development@lists.berlios.de
Betreff: Re: [Openocd-development] [PATCH] mips target
On Thu, May 26, 20
On Thu, May 26, 2011 at 2:06 PM, Mahr, Stefan wrote:
>>> Btw.: There is still an endianness issue with mips target. Drasko adds
>>> endianness swapping (that I removed two years ago)
>> Why did you remove it ?
>
> I removed swapping in mips_m4k, because for commands like mdw the swapping
> was a
On Thu, May 26, 2011 at 2:15 PM, Øyvind Harboe wrote:
> This patch fixes an obvious bug.
It's not so obvious to me. I'll have to take a closer look.
> Unless I hear objections, I will merge.
I can check on Monday or Tuesday. I am very suspicious because I spent
several weeks integrating the ch
This patch fixes an obvious bug.
Unless I hear objections, I will merge.
That said, there may be other code that is building upon this broken behavior
that needs to get fixed afterwards.
If I see fixes for those followup bugs in short order, I'd be inclined to wait
until we have a sequence of pa
>> Btw.: There is still an endianness issue with mips target. Drasko adds
>> endianness swapping (that I removed two years ago)
> Why did you remove it ?
I removed swapping in mips_m4k, because for commands like mdw the swapping was
already done in target.c. If a target was selected as big endia
Looking at this patch, it's clearly wrong to cast a pointer to a host 32 bit
integer to a pointer to a sequence of bytes to shift out.
I don't know about the rest of the issues offhand, but I see Drask was
going to have a look at it.
--
Øyvind Harboe
Can Zylin Consulting help on your project
On Wed, May 25, 2011 at 4:28 PM, Mahr, Stefan wrote:
> Hi,
>
> attached patch fixes the endianess so mips/ejtag can be used on a big endian
> host.
>
>
> Btw.: There is still an endianness issue with mips target. Drasko adds
> endianness swapping (that I removed two years ago)
Why did you remov
Hi,
attached patch fixes the endianess so mips/ejtag can be used on a big endian
host.
Btw.: There is still an endianness issue with mips target. Drasko adds
endianness swapping (that I removed two years ago) to mips_m4k.c (commit
b1256894598296b54a1827e7ac797ad1c60a0b18). But some swapping i
39 matches
Mail list logo
