OPENCORES.ORG

Hi,

Hi Gyvrgy ,
Thanks again. I will try to fix the similar issue peripheral/memory.c. 
I see your point of checking 32-b vs. 64-b. My system is a 64-bit capable
4-MP UltraSPARC-II with Solaris. But I think the tool chain as 32-bit. I am
not sure that could have made a difference. If it does, then even the
'addprogram' itself may not be sufficient to fix the problem because it only
handles 32-bit instruction at a time. I can see this become an issue even on
64-bit little endian machine like Athlon. This is where you will see a
hardware engineer's (like myself) knowledge fall short. 

I will discuss with you on generating the unified diff once I get all the
tests working. I will try to use testbench/test command to run through all
of the tests available.  

-Charles

-----Original Message-----
From: openrisc-bounces@o... [mailto:openrisc-bounces@o...]
On Behalf Of Gyvrgy 'nog' Jeney
Sent: Thursday, October 06, 2005 11:31 PM
To: List about OpenRISC project
Subject: Re: [openrisc] or1ksim simulator question - endianess issue
confirmed

> Hi,
> 
> I am not sure that if I made the change at the correct place. But by 
> factor in the ENDIAN issue in the addprogram routine, my simulator 
> works.
> 
> void addprogram(oraddr_t address, uint32_t insn, int* breakpoint) {
>   int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) :
> translate(freemem,breakpoint);
> 
>   /* We can't have set_program32 functions since it is not gauranteed 
> that the
>    * section we're loading is aligned on a 4-byte boundry */ /*ZQI 
> patch*/ #ifdef WORDS_BIGENDIAN
>   set_program8 (vaddr + 3, (insn >> 24) & 0xff);
>   set_program8 (vaddr + 2, (insn >> 16) & 0xff);
>   set_program8 (vaddr + 1, (insn >> 8) & 0xff);
>   set_program8 (vaddr, insn & 0xff);
> #else
>   set_program8 (vaddr, (insn >> 24) & 0xff);
>   set_program8 (vaddr + 1, (insn >> 16) & 0xff);
>   set_program8 (vaddr + 2, (insn >> 8) & 0xff);
>   set_program8 (vaddr + 3, insn & 0xff);
> #endif

Your change is correct.  Perhaps you can submit a unified diff?  Also, the
simmem_{read,write}{16,8} functions in peripheral/memory.c need to be
patched to handle big endian correctly.  There is testbench/mem_test, which
you can use to verify that everything is ok with endianess.

> > > I downloaded the tar ball of or1k and built binutils, gcc and gdb 
> > > for or32 successfully for SunOS sun4u sparc SUNW,Ultra-80.

Another stupid question, is this a 32-bit or 64-bit processor?

nog.
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc