On Tue, Sep 24, 2013 at 11:12 PM, Franck Jullien
<[email protected]>wrote:
> Hi,
>
> I'm working on the OpenRISC port. After some discussions with Andreas, and
> after reading some old discussion [1], I have some doubt about the
> endianess strategy I should adopt.
>
> As I understand it, the JTAG interface sends datas LSB first to the
> target. That means if the target wait for a 32 bits word (let's say
> 0x11223344) it has to be added to the scan field in little endian order.
> Then, while shifted out, bits will be send from the LSB to the MSB (first
> bit target sees -> 0010 0010 1100 1100 0100 0100 1000 1000 <- last bit).
>
Yes, this is correct. However, you mustn't confuse the "endianness" of JTAG
with the byte order of either the target or the host. JTAG only deals with
bits, it has no bytes and no other larger units. So "endianness" is not
really defined for JTAG. But the spec (or common practice?) says that *if*
the bits are to be interpreted as larger units, the least significant bit
of that unit should be the first one out on the wire. And in OpenOCD, the
sequence of JTAG bits are represented as a sequence of bytes, with the
first bit being the least significant bit in the byte with the smallest
address ("little-endian", even on a big-endian machine). But this is just
an arbitrary (but convenient) convention and has no meaning or relevance
above the layer dealing with the jtag_add_dr_scan() family of functions.
So JTAG basically gives you the ability to transfer words of arbitrary size
between target layer in OpenOCD and one or more registers inside the TAP.
That's it. How the debug unit behind the TAP maps the bits of the JTAG
words into bytes and the bytes into byte lanes when the debug unit accesses
memory, that is another matter entirely. The target's memory access
functions inside OpenOCD has to be aware of this mapping, so it can feed
the JTAG words with data that cause a sequence of bytes on the host to end
up in the same order in the target memory after a write. And vice versa
after a read. It's quite possible that the mapping differs depending on the
type and width of access that should be performed. And for some targets the
mapping can be very convoluted. For example, the debug unit may have to
access memory by feeding an instruction stream into the CPU. So the data to
write may have to be encoded into CPU machine code to load the data into a
register, the address into another and then perform a store of the right
width.
And on ARM, the memory access component of an ADI v5 debug unit, is defined
to map the least significant byte of the JTAG word written to a specific
debug register, into the lowest addressed byte in memory. I.e little-endian
byte order. And this is so even if the ARM would be configured as a
big-endian machine. My point is that endianness is too vague a concept to
speak about without clearly defining *which* endianness you mean. There may
be multiple different "endiannesses" involved in a single system at the
same time, depending on which level you're looking at.
And in the end, the only thing that matters is that, for memory access, a
sequence of bytes shall have their order preserved after transfer. And for
register access, the value we intend the register to have shall be
interpreted as such by the target CPU. And this shall be independent of the
byte order of the machine running OpenOCD.
Should I fix the opencores debug unit ?
>
Depends. Is it broken?
Regards,
Andreas
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
