>> buf_get_u32: >> return (((uint32_t)buffer[3]) << 24) | >> (((uint32_t)buffer[2]) << 16) | >> (((uint32_t)buffer[1]) << 8) | >> (((uint32_t)buffer[0]) << 0); >> > > I do not get this function at all... What I see is that it is presumed > that host executing this code must be in the same endianess as the > target who filled this buffer. Otherwise bytes get flipped. > > Here is an experiment : > Let's imagine that target is BE. Then it will put word 0x12345678 read > from the it's (target's) mem like this : > buffer[0] = 0x12 > buffer [1] = 0x34 > buffer[2] = 0x56 > buffer[3] = 0x78
Let's forget target endianness for a moment. If you buffer is filled like above, LE host will do following: result = (uint32_t)buffer[0] << 0; // result = 0x00000012 or in memory 0x12 0x00 0x00 0x00 result |= (uint32_t)buffer[1] << 8; // result = 0x00003412 or in memory 0x12 0x34 0x00 0x00 result |= (uint32_t)buffer[2] << 16; // result = 0x00563412 or in memory 0x12 0x34 0x56 0x00 result |= (uint32_t)buffer[3] << 24; // result = 0x78563412 or in memory 0x12 0x34 0x56 0x78 BE host will do: result = (uint32_t)buffer[0] << 0; // result = 0x00000012 or in memory 0x00 0x00 0x00 0x12 result |= (uint32_t)buffer[1] << 8; // result = 0x00003412 or in memory 0x00 0x00 0x34 0x12 result |= (uint32_t)buffer[2] << 16; // result = 0x00563412 or in memory 0x00 0x56 0x34 0x12 result |= (uint32_t)buffer[3] << 24; // result = 0x78563412 or in memory 0x78 0x56 0x34 0x12 As you see result is always the same, but order in memory differs depending on host endianness. This is what I mean when I say it's ensured the result is in host endianness. If you would simply cast the buffer, result would be swapped: LE host: result = (uint32_t)buffer[0]; // result = 0x78563412 (memory 0x12 0x34 0x56 0x78) BE host: result = (uint32_t)buffer[0]; // result = 0x12345678 (memory 0x12 0x34 0x56 0x78) > What is funny however, is that I have BE target and LE host, and MIPS > code seems to be working fine... Which would say that EJTAG somehow > speaks LE with my host. Crazy thing. >> "Byte 0 refers to bits 7:0, byte 1 refers to bits 15:8, byte 2 refers to >> bits 23:16, and byte 3 refers to bits >> 31:24, independent of endianess." >> >> My guess is, if you read out a 32bit value, target endianness doesn't matter. > This is the only sane solution I can think of. It would say that EJTAG > is a bi-endian machine that can read both BE and LE if we feed it > fixed instr. size. No, there is no bi-endian machine. The sentence "Byte 0 refers to bits 7:0, byte 1 refers to bits 15:8, byte 2 refers to bits 23:16, and byte 3 refers to bits 31:24, independent of endianess." says for me that EJTAG is always LE, no matter of target endianness setting. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
