Hi All,

How can I configure , OR1ksim0.3.0 as the target little endian. Currently I am configuring as
--target=or32-elf , and by default it is big endian.

Thanks in advance.

-Thejus

Hi Thejus,

Looking at configure.ac, if the target CPU name contains the string "little", then OR32_LITTLE_ENDIAN is defined throughout the code.

However there are no or32 architectures defined with the string "little" in them, so there is no way to make this happen.

This is an omission. It reflects the complete lack of testing or Or1ksim for little endian architectures. Would you raise a bug, so this is picked up in the future.

As a workaround, I suggest modifying configure.ac - you could just alter line 57 to define LITTLE_ENDIAN as the default (good for you, but not for anyone else). After changing configure.ac, you'll need to run autoreconf to regenerate the configure file. I believe you need to use autoconf 2.61, automake 1.10.1 and libtool 1.5.24. There are reportedly problems with other versions of autotools.

A possible fix is to either add little endian architecture names for OR32, or provide a configure option to Or1ksim to specify the endianness.

In principle the OR1K architecture has dynamically switchable between endianness (the LEE bit in the SR could potentially be writeable), in which case Or1ksim ought to be able to respond to that bit being written. However it would be a performance nightmare!

HTH

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Hi Jeremy,

Thank You for the response.I tried as per your suggestions to make the target little endian. Unfortunately I couldn't observe any difference (still as Big endian). That is I changed the entry in the configure.ac to make little endian by default. I regenerated the configuration file.Then I configured as --target=or32-elf and built the simulator. No behavioral difference found in the operation i.e, (big endian to little endian).

Could you please suggest ,is there any additional changes require for my requirement.

Regards
Thejus

Hi Thejus,

This looks like bad news. You should check that OR32_LITTLE_ENDIAN is defined and OR32_BIG_ENDIAN is not defined in config.h (just in case the configuration hasn't done its stuff).

However I suspect that Or1ksim has not been fully developed for little endian use. These may just be hooks and the relevant code has not yet been (fully) written. I never tested little endian use, so the code is only that which was there in the existing version.

You are welcome to try making the changes yourself. Or1ksim is reasonably well structured, and where I have modified it, I've tried to add comprehensive commenting. Hopefully you'll only need to change the memory access functions.

Whatever, you should raise this as a bug, so it can be considered in the future.

Best wishes,

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Hello Thejus/Jeremy,
I have tried the suggestions from Jeremy and the final config.h generated has only LITTLE ENDIAN defined.
I also applied the patch from the following link: http://opencores.org/forum,OpenRISC,0,2265
for loading the code (the code is compiled using big endian GNU toolchain ). I guess this patch swaps the instructions if they were compiled in little endian mode. So I have a doubt whether this patch should be taken at all or not. Any suggestions??

After this, I observed that some on the "libtests" fail whereas "or1ksim tests" pass. I looked at the dump in the memory and observed that the instruction bytes are swapped. So can I conclude that OR1KSIM indeed understands the instruction in both the endians???

With these results, how can we check if OR1KSIM with this new "config" file is indeed working in little endian mode?? Should we place some data accesses between memory and CPU to check the endianness?

Please suggest.

Thanks,
Rajani

Hi Rajani,

You need to add Or1ksim tests specifically for little-endian behaviour, and also extend the existing tests which should be independent of endianness to test with both little and big-endian.

Unfortunately, for now, you'll be quite restricted, because the tool chain does not support little-endian properly. You might have to start with manually defined machine code (i.e. use .byte directives to specify the code).

Getting little-endian OpenRISC working is a big task, but if someone is willing to start that would be useful.

Best wishes,

Jeremy