> -----Original Message----- > From: Zach Welch [mailto:z...@superlucidity.net] > Sent: vrijdag 12 juni 2009 10:39 > To: Nico Coesel > Cc: David Claffey; openocd-development > Subject: Re: [Openocd-development] mips32 big endian fix > > On Fri, 2009-06-12 at 09:55 +0200, Nico Coesel wrote: > > > -----Original Message----- > > > From: openocd-development-boun...@lists.berlios.de [mailto:openocd- > > > development-boun...@lists.berlios.de] On Behalf Of David Claffey > > > Sent: donderdag 11 juni 2009 23:18 > > > To: openocd-development > > > Subject: [Openocd-development] mips32 big endian fix > > > > > > A patch is needed for MIPS big endian (elf32-tradbigmips) targets. > > Perhaps > > > I'm the first to test trunk with a MIPS big endian target. > > > > > > If "-endian big" is not set in target create, the endianess defaults > > to > > > little. > > > mw and md commands will still work, but binary file loads will have > > the > > > incorrect word order loaded into memory. > > > > > > The EJTAG processor access data register (PrAcc) is little endian > > regardless > > > of the CPU endianness; it is always loaded LSB first. This is > > confirmed by > > > the fact that mips_ejtag_drscan_32() uses buf_set_u32() to load the > > scan > > > field; > > > buf_set_u32() is a little-endian formatter. For big endian targets, > > data > > > buffers have to be modified so the LSB of each u32 or u16 is at the > > lower > > > (first) memory location. > > > > > > The attached patch for src/target/mips_m4k.c fixes the problem. > > > > > > Included is a patch for src/target/mips_ejtag.c that fixes the case of > > a big > > > endian host. Again it is related to PrAcc. If the drscan out_value > > word > > > order is set using buf_set_u32() then it makes sense to also fixup the > > > in_value with buf_get_u32(); a symmetry argument. This has no affect > > on > > > little endian hosts. > > > > > David, > > I strongly doubt your patch is required. AFAIK OpenOCD already modifies > > the loaded data for correct endianess at a higher level. Secondly I > > think endianess conversions should not be done inside a target specific > > file. > > > > I'm using OpenOCD with a MIPS target (AU1100) as well which is also big > > endian. I've configured OpenOCD to use little endian mode and that seems > > to be the proper setting. A thing to look out for is that the MIPS EJTAG > > interface may do the endian conversion for you. Is the order of the > > special function registers correct when OpenOCD is in little endian > > mode? This the case with 'my' AU1100 target. You might want to check > > that first. If the special function registers read correctly in little > > endian mode then you'll need to modify the endianess of the binary file > > before loading it with OpenOCD. There are tools to do that. If I'm > > correct the bootloader Yamon comes with a tool called 'smunge' which can > > be used to modify the endianess of a file. > > As you probably noticed, I already committed these changes, but they > will be trivial to revert. Please let me know if I should remove them. > > That said, why require an external tool manage the conversion? Can > OpenOCD reasonably offer such support built-in?
Zach, In case of the AU1100 the answer is no. The AU1100 SOC is a complete endian mess. For starters: the MIPS core starts in big endian but the external memory controller starts in little endian. This would imply endian conversion depending on the address. Way too complicated. Anyway when I use OpenOCD I can load the binary file (bootloader) without need for byte shuffling. If I use the MacGraigor software I need to shuffle the data first. I would like to hear from David first before a final judgement about his patches is made. I'm curious about the target he is working on. Nico Coesel _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
