On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC <drasko.drasko...@gmail.com
> wrote:
> On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
> <andreas.fritiof...@gmail.com> 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 made *on the target*.
> How do we determine that ?
>
> I thought that it is kept in the "size" parameter, and
> mips32_pracc_read_mem is doing exactly this :
>
> int mips32_pracc_read_mem(struct mips_ejtag *ejtag_info, uint32_t
> addr, int size, int count, void *buf)
> {
> switch (size)
> {
> case 1:
> return mips32_pracc_read_mem8(ejtag_info, addr,
> count, (uint8_t*)buf);
> case 2:
> return mips32_pracc_read_mem16(ejtag_info, addr,
> count, (uint16_t*)buf);
> case 4:
> if (count == 1)
> return mips32_pracc_read_u32(ejtag_info,
> addr, (uint32_t*)buf);
> else
> return mips32_pracc_read_mem32(ejtag_info,
> addr, count, (uint32_t*)buf);
> }
>
> return ERROR_OK;
> }
>
> > Host data buffer type should be
> > identical, preferrably void*, with no alignment requirement, and count
> > should be in number of bytes.
>
> 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*.
>
But already here buf is cast to uint{8,16,32}_t* (from void* so no warning
but equally risky) which shouldn't be needed because all read_mem* functions
could accept a void* buffer and write the data to arbitrary alignment. Main
point is that the alignment requirement (buffer data type) on the host
should not be coupled to the access size used on the target. And also the
data returned in the host buffer should be identical, regardless of which
target access size is chosen (this requirement probably gives the answer to
whether endian swapping should be done here or not). Does this make sense?
Of course you may not be able to do an access with size 2 or 4 to an
unaligned *target address* but that has nothing to do with host buffer
alignment.
If the memory functions only handle byte addressed generic memory blocks,
there are no endian issues (here). They pop up first when higher level code
tries to interpret the memory contents as multi-byte entities (instructions,
addresses, ...) in which case that code must be aware of the target
endianness. Again, I may be confused here.
/Andreas
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
