On Sat, Jul 30, 2011 at 4:26 AM, Mahr, Stefan <[email protected]>wrote:
> Hi Drasko. > > > Drasko DRASKOVIC (1): > > mips32 : Fixed memory byte access > > Your patch fixes the broken byte access, but not the big endian host issue. > Since both problems are tied together, I would prefer a more common > solution. Attached patch hopefully fixes both issues. It should also fix > alignment warning that Øyvind had reported. Unfortunately I can't test it > for the time being. > > > +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. Comments for the get functions are broken, though. > /* mips32_..._write_mem with size 4/2 requires uint32_t/uint16_t in host */ > /* endianness, but byte array represents target endianness */ > /* mips32_pracc_fastdata_xfer requires uint32_t in host endianness, */ > /* but byte array represents target endianness */ 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? 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? BTW, I'm puzzled by the naming here. It seems mips32_pracc_exec_read is used for transfers host->target and mips32_pracc_exec_write for target->host? 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. /Andreas
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
