> -----Original Message----- > From: David Claffey [mailto:dnclaf...@gmail.com] > Sent: vrijdag 12 juni 2009 13:50 > To: Nico Coesel > Cc: Zach Welch; openocd-development > Subject: Re: [Openocd-development] mips32 big endian fix > > 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.
David, I think the following is happening with your patch applied and OpenOCD in big endian mode: mww command -> endian shuffle in target.c -> endian shuffle in mips target driver -> target binary file -> endian shuffle in mips target driver -> target I tried to read the SFRs in the AU1100 using the mdb and the mdh command with OpenOCD in little endian mode. It reads the correct values on 4 bytes boundaries while the CPU is in big endian mode. This proofs the EJTAG access port is doing the proper endian conversion. In other words: the binary file should be changed for proper endianess before loading it. The MIPS implementation in OpenOCD doesn't need to be fixed regarding the endianess. Nico Coesel PS: It seems reading data on non 4 byte boundaries needs to be fixed for MIPS targets. > 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
