BTW,
Stefan and all others,
thank you very much for this long discussion and for the effort on
explaining things. I think it was very useful.
BR,
Drasko
On Tue, Aug 9, 2011 at 11:20 PM, Drasko DRASKOVIC
wrote:
> On Mon, Jul 11, 2011 at 1:50 PM, Mahr, Stefan
> wrote:
> Yes, if BE target shi
On Mon, Jul 11, 2011 at 1:50 PM, Mahr, Stefan wrote:
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
>>> 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
On Mon, Jul 11, 2011 at 1:43 PM, Drasko DRASKOVIC
wrote:
>> 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 addres
On Mon, Jul 11, 2011 at 1:41 PM, Mahr, Stefan wrote:
>> 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
> 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
On Mon, Jul 11, 2011 at 1:30 PM, Øyvind Harboe wrote:
> On Mon, Jul 11, 2011 at 1:10 PM, Drasko DRASKOVIC
> wrote:
>> On Mon, Jul 11, 2011 at 12:52 PM, Øyvind Harboe
>> wrote:
>>> On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC
>>> wrote:
On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe
Ø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
On Mon, Jul 11, 2011 at 1:10 PM, Drasko DRASKOVIC
wrote:
> On Mon, Jul 11, 2011 at 12:52 PM, Øyvind Harboe
> wrote:
>> On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC
>> wrote:
>>> On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe
>>> wrote:
I think there is a fundamental misunderstandi
On Mon, Jul 11, 2011 at 12:52 PM, Øyvind Harboe wrote:
> On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC
> wrote:
>> On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe
>> wrote:
>>> I think there is a fundamental misunderstanding about JTAG
>>> and OpenOCD.
>>>
>>> Let me try to clarify:
>>>
>>
On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC
wrote:
> On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe
> wrote:
>> I think there is a fundamental misunderstanding about JTAG
>> and OpenOCD.
>>
>> Let me try to clarify:
>>
>> JTAG clocks in and out bits, not bytes, so the concept of
>> "big/
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];//
On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe wrote:
> I think there is a fundamental misunderstanding about JTAG
> and OpenOCD.
>
> Let me try to clarify:
>
> JTAG clocks in and out bits, not bytes, so the concept of
> "big/small-endian" does not enter the picture at the JTAG level.
Sat that w
On Mon, Jul 11, 2011 at 12:31 PM, Øyvind Harboe wrote:
> On Mon, Jul 11, 2011 at 12:17 PM, Drasko DRASKOVIC
> wrote:
>> On Mon, Jul 11, 2011 at 7:31 AM, Øyvind Harboe
>> wrote:
>>> Now a sequence of 8 bit words happens to be identical to
>>> little endian representation
>> In what way ? 8 bits
On Mon, Jul 11, 2011 at 12:17 PM, Drasko DRASKOVIC
wrote:
> On Mon, Jul 11, 2011 at 7:31 AM, Øyvind Harboe
> wrote:
>> Now a sequence of 8 bit words happens to be identical to
>> little endian representation
> In what way ? 8 bits is 8 bits - one byte, bits 7:0. I do not see BE
> or LE represent
On Mon, Jul 11, 2011 at 7:31 AM, Øyvind Harboe wrote:
> Now a sequence of 8 bit words happens to be identical to
> little endian representation
In what way ? 8 bits is 8 bits - one byte, bits 7:0. I do not see BE
or LE representation here...
BR,
Drasko
I think there is a fundamental misunderstanding about JTAG
and OpenOCD.
Let me try to clarify:
JTAG clocks in and out bits, not bytes, so the concept of
"big/small-endian" does not enter the picture at the JTAG level.
OpenOCD stores the bits clocked in/out as a series of words
which happen to be
On Mon, Jul 11, 2011 at 11:10 AM, Mahr, Stefan wrote:
>>> buf_get_u32:
>>> return (((uint32_t)buffer[3]) << 24) |
>>> (((uint32_t)buffer[2]) << 16) |
>>> (((uint32_t)buffer[1]) << 8) |
>>> (((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
> > 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
On Sat, Jul 9, 2011 at 10:44 AM, Mahr, Stefan wrote:
>> 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:
>
> 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
On Fri, Jul 8, 2011 at 6:30 PM, Mahr, Stefan wrote:
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_imp
>>> 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
On Fri, Jul 8, 2011 at 4:30 PM, Mahr, Stefan wrote:
>> 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 ?
> The endianness of MIPS EJTAG tap seems to have always the same endianness, no
> matter of
> 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.
__
On Fri, Jul 8, 2011 at 4:23 PM, Mahr, Stefan wrote:
>> 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.
OK, we are slowely nailing it... Just let m
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
>> 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.
How do they convert then, when they do not know from which endianes to
convert from ?
> 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@
On Fri, Jul 8, 2011 at 4:10 PM, Mahr, Stefan wrote:
>>> - 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 g
>> - 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
On Fri, Jul 8, 2011 at 3:08 PM, Andreas Fritiofson
wrote:
>
>
> On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC
> wrote:
>>
>> On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
>> wrote:
>> > I looked briefly at the memory read functions in mips32_dmaacc.c and
>> > mips32_pracc.c and it looks
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
>> 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 sw
On Fri, Jul 8, 2011 at 1:54 PM, Mahr, Stefan wrote:
>> 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*.
I agree with
On Fri, Jul 8, 2011 at 1:38 PM, Mahr, Stefan wrote:
>> 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 un
On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC wrote:
> On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
> wrote:
> > I looked briefly at the memory read functions in mips32_dmaacc.c and
> > mips32_pracc.c and it looks like the type usage is a bit confused. The
> > difference between the *_r
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
> > 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.
>
>
You can't convert between target and host endianness if you don't know both.
I'm ge
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
> > 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 sw
> 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
On Fri, Jul 8, 2011 at 1:38 PM, Mahr, Stefan wrote:
> > 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 no
> 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
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
wrote:
> I looked briefly at the memory read functions in mips32_dmaacc.c and
> mips32_pracc.c and it looks like the type usage is a bit confused. The
> difference between the *_read_mem{32,16,8} functions should only be what
> kind of access is m
On Fri, Jul 8, 2011 at 1:20 PM, Andreas Fritiofson
wrote:
>
>
> On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC
> wrote:
>>
>> I am just wandering, would :
>> t32 = *(uint32_t*)((void *)&buffer[i]);
>> quite the compiler ;)
>
> Yes probably, but it would still crash on an architecture that doesn
On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC wrote:
> I am just wandering, would :
> t32 = *(uint32_t*)((void *)&buffer[i]);
> quite the compiler ;)
>
Yes probably, but it would still crash on an architecture that doesn't
support unaligned accesses.
/Andreas
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe wrote:
> What puzzles me is that there is no warning on x86, even if I the
> -Wcast-align option
> is there
>
>
> -Wcast-align
>Warn whenever a pointer is cast such that the required alignment
> of the target is increased. For example, wa
I am just wandering, would :
t32 = *(uint32_t*)((void *)&buffer[i]);
quite the compiler ;)
BR,
Drasko
On Fri, Jul 8, 2011 at 1:14 PM, Drasko DRASKOVIC
wrote:
> On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe wrote:
>>> that casts void* buf to uint32_t*.
>>
>> Actually buffer is uint8_t *. The def
On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe wrote:
>> that casts void* buf to uint32_t*.
>
> Actually buffer is uint8_t *. The definition of target->type->read_memory is
> bad in that it uses uint8_t * instead of void *. Which is kinda the
> root of this mess.
Well, this propagate through all t
> that casts void* buf to uint32_t*.
Actually buffer is uint8_t *. The definition of target->type->read_memory is
bad in that it uses uint8_t * instead of void *. Which is kinda the
root of this mess.
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / Int
On Wed, Jul 6, 2011 at 2:42 PM, Mahr, Stefan wrote:
> "mips32_pracc_read_mem" and "mips32_pracc_write_mem" return values
> (buffer[i]) are already in host endianness, so le_to_h_u32 fails on big
> endian hosts. I already mentioned this in previous discussions.
Hi Stefan,
are you sure about this
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe wrote:
> What puzzles me is that there is no warning on x86, even if I the
> -Wcast-align option
> is there
This kind of explains why I never saw it...
BR,
Drasko
___
Openocd-development mailing list
O
On Fri, Jul 8, 2011 at 12:42 PM, Øyvind Harboe wrote:
>> I still can not reproduce a problem - it buidls just fine. No warnings
>> whatsoever.
>
>
> libtool: compile: nios2-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I.
> -I/home/oyvind/workspace/zy1000/build/../openocd/src/target -I../..
> -I/home
What puzzles me is that there is no warning on x86, even if I the
-Wcast-align option
is there
-Wcast-align
Warn whenever a pointer is cast such that the required alignment
of the target is increased. For example, warn if a char * is cast to
an int * on machines where integers can onl
> I still can not reproduce a problem - it buidls just fine. No warnings
> whatsoever.
libtool: compile: nios2-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I.
-I/home/oyvind/workspace/zy1000/build/../openocd/src/target -I../..
-I/home/oyvind/workspace/zy1000/build/../openocd/src -I../../src
-DPKGDA
On Fri, Jul 8, 2011 at 12:35 PM, Øyvind Harboe wrote:
> On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC
> wrote:
>> On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe
>> wrote:
There is no particular need to cast this into uint8_t* and this can be
kept as a void*. Would that suppress th
On Fri, Jul 8, 2011 at 12:10 PM, Øyvind Harboe wrote:
>> OK, I am starting to get this... Thanks Øyvind.
>>
>> But looking from to the code, I see no explicit casting uint8_t* to
>> uint32_t in mips_pracc code. Where did you exactly run into compiler
>> warning ?
>
> git revert 2482244b0788c007dd
On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe wrote:
>> There is no particular need to cast this into uint8_t* and this can be
>> kept as a void*. Would that suppress the warnings ?
>
> It does look like this code is using uint8_t * in lieu of void *...
Why ? It is just an address of 1-byte plac
On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC
wrote:
> On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe
> wrote:
>>> There is no particular need to cast this into uint8_t* and this can be
>>> kept as a void*. Would that suppress the warnings ?
>>
>> It does look like this code is using uint8_t
> There is no particular need to cast this into uint8_t* and this can be
> kept as a void*. Would that suppress the warnings ?
It does look like this code is using uint8_t * in lieu of void *...
I think it would suppress the warnings, yes.
--
Øyvind Harboe - Can Zylin Consulting help on your p
On Thu, Jul 7, 2011 at 11:52 AM, Øyvind Harboe wrote:
> 011/7/7 Mahr, Stefan :
>> Ø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
> OK, I am starting to get this... Thanks Øyvind.
>
> But looking from to the code, I see no explicit casting uint8_t* to
> uint32_t in mips_pracc code. Where did you exactly run into compiler
> warning ?
git revert 2482244b0788c007dd789c2
--
Øyvind Harboe - Can Zylin Consulting help on your p
On Fri, Jul 8, 2011 at 11:47 AM, Øyvind Harboe wrote:
> On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC
> wrote:
>> On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe
>> wrote:
>>> Note that this problem has cropped up many places over the OpenOCD
>>> code. I'd like to get rid of it once and for
On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC
wrote:
> On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe
> wrote:
>> Note that this problem has cropped up many places over the OpenOCD
>> code. I'd like to get rid of it once and for all
>>
>> I absolutely intend to fix it for MIPS, but I'd l
On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe wrote:
> Note that this problem has cropped up many places over the OpenOCD
> code. I'd like to get rid of it once and for all
>
> I absolutely intend to fix it for MIPS, but I'd like a good long term
> solution.
>
> With jtag queue callbacks, a
On Thu, Jul 7, 2011 at 10:41 PM, Mahr, Stefan wrote:
> 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
On Thu, Jul 7, 2011 at 11:04 PM, Michael Schwingen
wrote:
> Am 07/07/2011 10:41 PM, schrieb Mahr, Stefan:
>> 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_mem3
On Thu, Jul 7, 2011 at 12:59 AM, Andreas Fritiofson
wrote:
> No, casting a pointer-to-any-type to a pointer-to-void and back will never
> cause alignment issues. The question is who makes the guarantee that the
> function is only ever called with uint32-aligned generic pointers. If it
> just happe
On Wed, Jul 6, 2011 at 6:35 PM, Mahr, Stefan wrote:
>> Did you see this by testing or by inspection?
>
> Both :)
>
>
>> Do we even have the right macros here?
>>
>> It would be something like unaligned uint32_t access macros, which will have
>> to
>> exist in host endian versions.
>
> "mips32_pr
> There is no problem to get it work, but I'm not sure if this is
> really the best way. I try to prepare a patch within the next
> days, so you and others can comment.
I have particular reason to be especially grateful for your efforts here... ;-)
Thanks!
--
Øyvind Harboe - Can Zylin Consulti
>> 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
Am 07/07/2011 10:41 PM, schrieb Mahr, Stefan:
> 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 cas
On Thu, Jul 7, 2011 at 10:41 PM, Mahr, Stefan wrote:
> 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
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
On Thu, Jul 7, 2011 at 4:52 PM, Mahr, Stefan wrote:
>>> 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 the
>> 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.
___
Note that this problem has cropped up many places over the OpenOCD
code. I'd like to get rid of it once and for all
I absolutely intend to fix it for MIPS, but I'd like a good long term solution.
With jtag queue callbacks, a user data pointer to the callback is cast to
a void pointer, then ca
011/7/7 Mahr, Stefan :
> Ø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?
Why?
> http://openocd.git.sourceforge.net/git/gitweb.cgi?p=
Ø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
I should have said uint8_t * to uint32_t *. The problem is that that
there is a lot of distance between where the conversion to uint8_t *
happens and where the cast back to uint32_t * happens.
It is not obvious at all from the context that there is an alignment
guarantee.
Hence the simplest solut
On Wed, Jul 6, 2011 at 11:35 PM, Øyvind Harboe wrote:
> On Wed, Jul 6, 2011 at 11:28 PM, Mahr, Stefan
> wrote:
> "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 t
> 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:
On Wed, Jul 6, 2011 at 11:28 PM, Mahr, Stefan wrote:
"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...
>>
>> s
>>> "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
>> "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 *data)
{
uint3
On Wed, Jul 6, 2011 at 6:35 PM, Mahr, Stefan wrote:
>
> > Did you see this by testing or by inspection?
>
> Both :)
>
>
> > Do we even have the right macros here?
> >
> > It would be something like unaligned uint32_t access macros, which will
> > have to
> > exist in host endian versions.
>
> "m
> Did you see this by testing or by inspection?
Both :)
> Do we even have the right macros here?
>
> It would be something like unaligned uint32_t access macros, which will have
> to
> exist in host endian versions.
"mips32_pracc_read_mem" casts uint32 to void, so we need to cast it back to
> "mips32_pracc_read_mem" and "mips32_pracc_write_mem" return
> values (buffer[i]) are already in host endianness, so le_to_h_u32 fails on
> big endian hosts. I already
> mentioned this in previous discussions.
Ouch. Did you see this by testing or by inspection?
The problem is that I mis-interpr
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
88 matches
Mail list logo
