Nico, You are correct, target.c modifies for endianness. This is helpful when I set openocd to -endian big; it sets the word order for mw and md commands to the same endianness as the binary files I want to load. The problem is the mips_m4k target does not adjust for endianness like the xscale target does.
My board is a Atheros ar71xx with a MIPS 24Kc hardcore. The cpu endianness cannot be changed and there is no other endianness in the SoC. The special registers read and write correctly when I configure openocd in little endian mode. When I saw the discrepancy I thought, I have a big endian target, why should I not set "-endian big". So as a fix, I followed the practice in src/target/xscale.c:xscale_send() where word order is swapped depending on target->endianness. I can now read/write the special registers correctly and download a binary from my toolchain without modification. Nico Coesel wrote: >> -----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
