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_u32_array(struct target *target, uint8_t *buffer, >> uint32_t count, uint32_t *srcbuf); >> +void target_buffer_set_u16_array(struct target *target, uint8_t *buffer, >> uint32_t count, uint16_t *srcbuf); > > Great, these helper functions are on my todo list. There are several other > places where they are useful.
Ok, attached as single patch. > Those comments suggest to me that the mips32_..._write_mem > and mips32_pracc_fastdata_xfer functions are the ones > that are broken (by design?). If the byte array already is in target > endianness, why on earth do we need to swap > it back and forth? Why can't mips32_pracc_write_mem8/16/32 simply copy the > already properly formatted memory block > to the target, using load/store byte for the -8 version, load/store halfword > for the -16 version and load/store > word for the -32 version? Broken by design - yes, that's the problem. Fixing this issue may have a big impact on code, so I try to avoid it for now. > Looking at the -32 version, the memory block (that with your patch has been > swapped to host order) is simply passed on > to mips32_pracc_exec(), which I assume perform the actual transfer. Where in > the following process is the data swapped > *back* to target order? Never. The array is written as uint32 array to target. > It seems to me that the endianness handling in the MIPS code is very much > more complex than it would need to be. > Maybe the root cause of the complexity is that the mips_ejtag scan functions > are handling arrays of uint32_ts > when they should be handling arrays of bits (which in OpenOCD is represented > by a LSBit-filled-first array of bytes)? > That approach forces *host* endianness and alignment considerations far down > into the low level code where they don't > belong. I'm not sure if this makes sense, since it would make debug tap handling much more complicated. At the moment mips_ejtag is independant of target endianness. Stefan
0001-target-add-helper-functions-to-get-set-u16-or-u32-ar.patch
Description: 0001-target-add-helper-functions-to-get-set-u16-or-u32-ar.patch
0002-mips-fix-big-endian-host-and-potential-alignment-err.patch
Description: 0002-mips-fix-big-endian-host-and-potential-alignment-err.patch
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
