Re: [ECOS] Endianness of the XScale

["Krishna Ganugapati" <krishnag at marakicorp dot com>]

See below...
-------------------------------------------------
----- Original Message ----- 
From: "Mark Salter" <msalter@redhat.com>
To: <krishnag@marakicorp.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 11:25 AM
Subject: Re: [ECOS] Endianness of the XScale


> >>>>> Krishna Ganugapati writes:
>
> > Hello Mark, Thanks for the quick response.
> > Could you clarify the first part?
>
> > Endianness in the XScale only applies to data fetches. All instruction
> > opcode fetches are always little endian irrespective of whether the
machine
> > configured BE or LE
>
> > is the above accurate?
>
> No, I don't think it is accurate. Endianess on a 32-bit ARM really only
> comes into play when accessing 8-bit or 16-bit data. Instructions are
> always fetched as 32-bit objects. I think that opcodes and data are

Agreed thay are always retrieved as 32 bit objects but if there is an
instruction AABBCCDD (software representation where left is always MSB), do
we store the 32 bit object as follows


Byte 0 - AA
Byte 1 - BB
Byte 2 - CC
Byte 3 - DD

or

Byte 0 - DD
Byte 1 - CC
Byte 2 - BB
Byte 3 - AA

> stored in memory in the same endianess. For instance, RedBoot may copy

Further in my investigation, I find the following. At reset, the XScale is
in little endian mode.
Instructions are stored on  4 byte boundaries. Consider an instruction
AABBCCDD. This is its software representation where the msb is AA and its
lsb is DD.

When you follow Intel's instructions for building redboot_rom for the XScale
using a big endian compiler, the image on the host has instruction AABBCCDD
stored as

byte 0 - AA
byte 1 - BB
byte 2 - CC
byte 3 - DD

For the Macraigor Flash Programmers, Intel requires byte swapping before you
create an s19 file which you then download. Once I perform the following and
then  dump the first instruction (assume it was AABBCCDD), the instruction
is stored as follows. I verified this by dumping individual bytes in the
Macraigor debugger.

byte 0 - DD
byte 1 - CC
byte 2 - BB
byte 3 - AA

which is a little endian representation.  Single step execution works fine.
About 10 instructions down the line, the redboot image switches endianness
of the  processor by switching the appropriate coprocessor bit.  Execution
continues on.... Though the processor has switched its endianess, its image
continues in the little endian mode (Remember every instruction has now been
represented as LE)  and it continues to execute instructions in the little
endian mode, which led me to the conclusion that instructions are always
stored LE.

Also if we were to assume that the instruction storage format had to map the
endianness of the processor, then once I had executed the instructions that
switched the endianness bit  to BE in the control register ( coprocessor 15
register 0??), then wouldn't it stand to reason that my instructions post
the endianness switch would also have to be BE which would imply that all my
instructions would be interpreted  the other way around. MSB in byte 0 which
would result in something very different for what I intended to execute. My
single step execution continues appropriately even after switching the
endianness.


Further I found the following snippet on web:


And AFAIK The opcode fetches are always little-endian (not that this
helps :(
Little/Big endian refers to the data-view.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=85f19b17.0404280319.69ad72ac%40posting.google.com&rnum=1&prev=/groups%3Fq%3DAre%2Binstruction%2Binterpreted%2Bin%2Blittle%2Bendian%2Bor%2Bbig%2Bendian%2Bfor%2Bthe%2BARM%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D85f19b17.0404280319.69ad72ac%2540posting.google.com%26rnum%3D1


Note: I'm certainly not claiming this is definitive or conclusive... I'm
just a thoroughly confused novice...



> flash driver routines from flash to RAM and run them from RAM. This
> copy is done as data loads and stores. No byte swapping necessary
> regardless of endianess. Also, the compiler will embed some data
> along with the opcodes. That data and the opcodes around it all appear
> to be stored in the same endianess.

Intel says that most Flash programmers do appropriate instruction layout
internally. Macraigor is the only one in their notes where they explicit
require the byte swapping.


>
> As I said. I can load/flash a new redboot.bin on IXDP425 without doing
> any byte swapping as long as the running RedBoot and the new RedBoot
> are the same endianess.
>

I'm sure you're right... I can't explain this mostly because I've not gotten
that far..



> --Mark
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss