nag :-)
BR,
Stefan
-Ursprüngliche Nachricht-
Von: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] Im Auftrag von Mahr,
Stefan
Gesendet: Donnerstag, 11. August 2011 00:42
An: Drasko DRASKOVIC
Cc: Openocd-Dev
Betreff: Re: [Openocd
Hi Drasko
> Solution is more common, but the commit history is not clearer. You
> are fixing several bugs in one patch...
Serveral? Just one and a half :-)
However, I stripped the alignment fix to a seperate patch file. Please find the
three new patches attached.
> Besides, I have an impressi
Andreas Fritiofson wrote:
>> +void target_buffer_get_u32_array(struct target *target, const uint8_t
>> *buffer, uint32_t count, uint32_t *dstbuf);
>> +void target_buffer_get_u16_array(struct target *target, const uint8_t
>> *buffer, uint32_t count, uint16_t *dstbuf);
>> +void target_buffer_set_u3
Hi Drasko.
> Drasko DRASKOVIC (1):
> mips32 : Fixed memory byte access
Your patch fixes the broken byte access, but not the big endian host issue.
Since both problems are tied together, I would prefer a more common solution.
Attached patch hopefully fixes both issues. It should also fix al
>>> Yes, if BE target shifts out an 32 bit value from address 0, it will
>>> begin with bit0:7, that is byte address 0x03 at targets memory.
>>
>> And host will do the same. When it shifts out 32-bit value , it will
>> put contents of it's address 0x3 to output buffer[0] and send this
>> first.
> I
> When you start shifting out LSB (bit) from the BE host, will you start
> shifting out contents of address 0x3, or the address 0x0 ? In my
> opinion, it will be content of the addr 0x3 that will be shifted out
> first (as it holds bits 0:7 for on the BE host).
Yes, if BE target shifts out an 32 b
Øyvind Harboe wrote:
> Really OpenOCD could have stored the bits as a series of
> words larger than bytes in the host representation to be more
> efficient.
This would probably be a source of much more confusion :-)
___
Openocd-development mailing list
Sorry, little mistake:
wrong:
>> LE host: result = (uint32_t)buffer[0]; // result = 0x78563412 (memory
>> 0x12 0x34 0x56 0x78)
>> BE host: result = (uint32_t)buffer[0]; // result = 0x12345678 (memory
>> 0x12 0x34 0x56 0x78)
corrected:
LE host: result = *(uint32_t*)&buffer[0];//
>> buf_get_u32:
>> return (((uint32_t)buffer[3]) << 24) |
>> (((uint32_t)buffer[2]) << 16) |
>> (((uint32_t)buffer[1]) << 8) |
>> (((uint32_t)buffer[0]) << 0);
>>
>
> I do not get this function at all... What I see
> How do they convert then, when they do not know from which endianes to
> convert from ?
Conversion is done from byte array of jtag chain.
>>> How ?
>>
>> buf_get_u32 does conversion from uint8* array
>>
>> example:
>> mips_ejtag_get_impcode (mips_ejtag.c)
>>
>> field.in_value i
>>> How do they convert then, when they do not know from which endianes to
>>> convert from ?
>>
>> Conversion is done from byte array of jtag chain.
> How ?
buf_get_u32 does conversion from uint8* array
example:
mips_ejtag_get_impcode (mips_ejtag.c)
field.in_value is filled by jtag_add_dr_sca
> How do they convert then, when they do not know from which endianes to
> convert from ?
Conversion is done from byte array of jtag chain. The endianness of MIPS EJTAG
tap seems to have always the same endianness, no matter of MIPS CPU memory
endianness.
__
> Is this swap to host endianess done by buf_get_u32() in
> mips_ejtag_drscan_32() after the queue has been executed ?
Yes, buf_get_u32() and buf_set_u32() make sure uint32 is in host endianness.
___
Openocd-development mailing list
Openocd-development@
>> - buf_set_u32 and buf_get_u32 make sure that data is in host endianness
> Why ? Don't we want the data to be in target endianess ?
>> You need swapping when reading and comparing debug registers or send code to
>> MIPS CPU.
> Can you give the example of some of these comparisons in the source
> Where are those functions defined and how do they know what the target
> endianness is?
They doesn't know the target endianness, but host endianness.
> It sounds a little strange to do the swapping at this low level.
You need swapping when reading and comparing debug registers or send code t
> Problem is not in the mips32_pracc.c, thought, but when you come back
> to mips_m4k_read_memory(), in which buf is uint8_t*.
That's why the solution could be to add swapping to _mem16, _mem32 etc. and
alway return uint8*.
___
Openocd-development mail
> are you sure about this ?
>
> It seems to me that buffer[i] is directly filled by target, and I see
> no reason that it is in the host endianess...
Hi Drasko,
Yes I'm sure. I tested it on my big endian host platform.
I do not understand the code completely, but I think it's caused by the mips
>> Probably the best way would be to remove endianness swapping from
>> mips_m4k_read_memory
>> and put it to mips32_pracc/dma_read_mem32/16. Same for write.
>>
>> pro: mips32_pracc_read_mem32, ... will return a byte array in target
>> endianness, so no cast necessary.
>> con: Add swapping to at
If alignment is not guaranteed, casting from uint32 to void would cause
problems too, wouldn't it?
>>> Why?
>>
>> Sorry for confusion. I meant the casting within "mips32_pracc_read_mem". This
>> is also a cast from void* to uint32_t*. If there will be an alignment error,
>> it will
>> o
>> If alignment is not guaranteed, casting from uint32 to void would cause
>> problems too, wouldn't it?
> Why?
Sorry for confusion. I meant the casting within "mips32_pracc_read_mem". This
is also a cast from void* to uint32_t*. If there will be an alignment error, it
will occur here too.
___
Øyvind Harboe wrote:
> It is not obvious at all from the context that there is an alignment
> guarantee.
If alignment is not guaranteed, casting from uint32 to void would cause
problems too, wouldn't it?
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/target/mips3
> Trust the compiler
NO !
:-)
$ gcc -O3 -S test.c
$ cat test.s
.file "test.c"
.text
.p2align 4,,15
.globl uint32_read_unaligned
.type uint32_read_unaligned, @function
uint32_read_unaligned:
>>> "mips32_pracc_read_mem" casts uint32 to void, so we need to cast it
>>> back to uint32. I found no suitable macro in actual sources.
>>
>> Hmm then I think we ought to define one to get this put to
>> bed once and for all...
>
> static inline uint32_t uint32_read_unaligned(const void *dat
o we need to cast it back to
uint32. I found no suitable macro in actual sources.
-Ursprüngliche Nachricht-
Von: Øyvind Harboe [mailto:oyvind.har...@zylin.com]
Gesendet: Mittwoch, 6. Juli 2011 15:02
An: Mahr, Stefan
Cc: openocd-development@lists.berlios.de
Betreff: Re:
Hi Øyvind,
Did you see problems with host endianness or why did you commit this patch:
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=2482244b0788c007dd789c21a4416379c229ea5c
This patch brokes endianness on big endian host.
"mips32_pracc_read_mem" and "mips32_prac
> Ref. your "todo:" shouldn't that be sorted out before we merge it?
>
> How does this affect the arm target?
The actual code in HEAD tries to load arm code to mips target. Bad idea. :-)
My patch checks for mips target and branches if needed. All other targets
are not affected.
This is the reas
Hi,
Attached patch adds support for writing flash memory from a memory block.
(Only 16bit buswidth, only spansion compatible.)
Best Regards,
Stefan
0002-mips-add-nor-flash-write-from-memory-block.patch
Description: 0002-mips-add-nor-flash-write-from-memory-block.patch
_
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
> 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
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;
}
+
> 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
> 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
>>> 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
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
> 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
__
>> 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
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
det: Donnerstag, 26. Mai 2011 12:12
An: Mahr, Stefan
Cc: openocd-development@lists.berlios.de
Betreff: Re: [PATCH] mips target
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.
>
>
>
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
Hi,
attached patch adds support for Spansion AM29LV040B that I found on an
Mindspeed evalboard.
BR,
Stefan
0001-add-support-for-spansion-flash-on-mindspeed-c300-eva.patch
Description: 0001-add-support-for-spansion-flash-on-mindspeed-c300-eva.patch
_
Hi,
the attached patch removes the endianness swapping in mips_m4k.c
Swapping is already done in target.c
grx
Stefan
mips_m4k_endianness.patch
Description: mips_m4k_endianness.patch
___
Openocd-development mailing list
Openocd-development@lists.berli
43 matches
Mail list logo
