>>>>> 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_scan with 4 times uint8.
>>  buf_get_u32 converts byte array to host endian uint32
>
> How ? It does not convert anything. It just takes the data and puts it
> into array, in the order that it comes.

No, you do *arithmetical* operations on host, so it is ensured that result is 
always in host endianness.

buf_get_u32:
                return (((uint32_t)buffer[3]) << 24) |
                        (((uint32_t)buffer[2]) << 16) |
                        (((uint32_t)buffer[1]) << 8) |
                        (((uint32_t)buffer[0]) << 0);



>>>> The endianness of MIPS EJTAG tap seems to have always the same endianness,
>>>> no matter of MIPS CPU memory endianness.
>>> What makes you think so ?
>>
>> Because openocd works in all combinations of BE and LE host and target. (If 
>> you
>> revert commit 2482244b0788c007dd789c21a4416379c229ea5c.) So yes, it's just a 
>> guess.
>
> Which might mean that all commands are sent to EJTAG in appropriate
> target format in which CPU expects them (be it BE or LE, depends in
> which mode it runs).

I can't find code that swaps target endianness in mips32_pracc.c or mips_ejtag.c


>> Could this be the explanation:
>>
>> http://downloads.buffalo.nas-central.org/LS2_MIPSel/DevelopmentTools/JTAG/MD00047-2B-EJTAG-SPC-03.10.pdf
>> Page 97:
>> Byte 0 refers to bits 7:0, byte 1 refers to bits 15:8, byte 2 refers to bits 
>> 23:16, and byte 3 refers to bits
>> 31:24, independent of endianess.
>>
> This is _always_ the case in _all_ architectures. But, as you see,
> this Byte0 is put to lower addresses for LE and to higher for BE. This
> is always the case.

"Byte 0 refers to bits 7:0, byte 1 refers to bits 15:8, byte 2 refers to bits 
23:16, and byte 3 refers to bits
31:24, independent of endianess."

My guess is, if you read out a 32bit value, target endianness doesn't matter. 
If a 8bit value is read out, you get byte0 for address 0 in LE mode and byte3 
at address 0 in BE mode.


BR,
Stefan

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to