On Mon, Aug 20, 2012 at 10:18 PM, Andreas Fritiofson <[email protected]> wrote: > On Mon, Aug 20, 2012 at 9:15 PM, Spencer Oliver <[email protected]> wrote: >> >> reverting c3074f377c1da33ca8ba8493826e1b52351eebc6 is not enough, as 16bit >> reads still fail. >> > > I can confirm that there was an issue even before c3074f37. However, > it's not the same behavior. > > str750test.cfg: > script interface/ftdi/jtagkey.cfg > script target/str750.cfg > init > halt > mww 0x40000000 0x76543210 > mdw 0x40000000 1 > mdh 0x40000000 2 > mdb 0x40000000 4 > shutdown > > with c3074f37: > 0x40000000: 76543210 > 0x40000000: 0000 0000 > 0x40000000: 00 00 00 00 > > before c3074f37: > 0x40000000: 76543210 > 0x40000000: 0000 7654 > 0x40000000: 00 00 00 76 > > So even if we scan all bits, there's still some endianness issue. > > /Andreas
Actually, the endianness seems fine, it's just that only the last of the accesses in arm7_9_read_memory() actually produces any data for size 1 or 2. At most 14 accesses are performed each round so a long dump of halfwords or bytes has every 14th element correct, the rest are zero. Every round, all of the accesses are loaded into separate registers and then all used registers are dumped to host in one operation. I didn't have time to examine whether the registers are loaded incorrectly or if it's the register dump that doesn't work for less than size 4. I have found a workaround that can be used as a quick-fix if we don't want to delay the release process. It's a quick-fix in the sense that it doesn't solve the underlying problem and it has a performance penalty (limits to one access per round). I'll push the workaround this evening after work and I'll also try to debug the issue further. /Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
