When I run the basic.or32 thru the or32-uclinux-sim, I get into the
following problem.

One of the last instructions in the file is;
l.jal _report

I dont find the pointer "_report" anywhere in the file. When I simulate it
(architecture simulation) it translates the above statement to
1.jal 0x8a
And it jumps to that space and somewhere in that space it encounters
a jump to 0 and goes into an infinite loop of staying at 0th location.
This causes a problem when I run "run_sw" since it keeps on writing on
to the log file till it reaches the disk quota.
What should I do to avert this problem? Specifically, where does it jump
when it encounters l.jal _report?
Thanks,
Guru

* gurumurt@c... (gurumurt@c...) wrote:
into the

file. When I simulate it

encounters

location.

keeps on writing on

does it jump

hm, symbol _report has to be somewhere else linker would complain.
(any library you're linking with ?)
regards,
p.

I just noticed that the report function is in support.c. But as seen from
the traces that I given below, the report function doesnot match with
the execution.

Here is the execution trace for the last few instructions in the basic.S
I have typed in the corresponding instructions in brackets.

EXECUTED( 565): 040006dc: 0400008a (l.jal _report)
GPR 0: 00000000 GPR 1: 00000001 GPR 2: 00000003 GPR 3:
deaddead
GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa
GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11:
000007ff
GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff
GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f
GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b
GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7
GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040
SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001

EXECUTED( 566): 040006e0: 15000000 (l.nop 0)
GPR 0: 00000000 GPR 1: 00000001 GPR 2: 00000003 GPR 3:
deaddead
GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa
GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11:
000007ff
GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff
GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f
GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b
GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7
GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040
SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001

EXECUTED( 567): 04000904: 9c21fffc (l.addi r1,r1,-4)
GPR 0: 00000000 GPR 1: fffffffd GPR 2: 00000003 GPR 3: deaddead
GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa
GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11:
000007ff
GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff
GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f
GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b
GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7
GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040
SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001

EXECUTED( 568): 04000908: d4011000 (l.sw 0x0(r1),r2)
GPR 0: 00000000 GPR 1: fffffffd GPR 2: 00000003 GPR 3: deaddead
GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa
GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11:
000007ff
GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff
GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f
GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b
GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7
GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040
SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001

EXECUTED( 569): 00000600: 00000000 (l.j 0x0)
GPR 0: 00000000 GPR 1: fffffffd GPR 2: 00000003 GPR 3: deaddead
GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa
GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11:
000007ff
GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff
GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f
GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b
GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7
GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040
SR : 00008001 EPCR0: 04000908 EEAR0: fffffffd ESR0 : 00008001


There is an execption at 568th instruction, here is the exception
message:
"Exception 0x600 (Alignment) at 0x4000908, EA: 0xfffffffd, ppc:
0x4000908, npc: 0x400090c, #568"

Why would this exception happen?

One more thing here is the report function from support.c.
void report(unsigned long value)
{
asm("l.addi\tr3,%0,0": :"r" (value));
asm("l.nop %0": :"K" (NOP_REPORT));
}

You would notice that these statements do not seem to correspond to
the statements listed above. Am I missing something?

I just noticed that the report function is in support.c. But as seen from the traces that I given below, the report function doesnot match with the execution. Here is the execution trace for the last few instructions in the basic.S I have typed in the corresponding instructions in brackets. EXECUTED( 565): 040006dc: 0400008a (l.jal _report) GPR 0: 00000000 GPR 1: 00000001 GPR 2: 00000003 GPR 3: deaddead GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11: 000007ff GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7 GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040 SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001 EXECUTED( 566): 040006e0: 15000000 (l.nop 0) GPR 0: 00000000 GPR 1: 00000001 GPR 2: 00000003 GPR 3: deaddead GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11: 000007ff GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7 GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040 SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001 EXECUTED( 567): 04000904: 9c21fffc (l.addi r1,r1,-4) GPR 0: 00000000 GPR 1: fffffffd GPR 2: 00000003 GPR 3: deaddead GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11: 000007ff GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7 GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040 SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001 EXECUTED( 568): 04000908: d4011000 (l.sw 0x0(r1),r2) GPR 0: 00000000 GPR 1: fffffffd GPR 2: 00000003 GPR 3: deaddead GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11: 000007ff GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7 GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040 SR : 00008001 EPCR0: 040006bc EEAR0: 00000000 ESR0 : 00008001 EXECUTED( 569): 00000600: 00000000 (l.j 0x0) GPR 0: 00000000 GPR 1: fffffffd GPR 2: 00000003 GPR 3: deaddead GPR 4: 00000000 GPR 5: 00008001 GPR 6: ffffffff GPR 7: fffffffa GPR 8: 1243f8b2 GPR 9: 040006e4 GPR10: 04000660 GPR11: 000007ff GPR12: 00000fff GPR13: 00001fff GPR14: 00003fff GPR15: 00007fff GPR16: ffff0012 GPR17: ffff0011 GPR18: ffff8010 GPR19: ffffc00f GPR20: ffffe00e GPR21: fffff00d GPR22: fffff80c GPR23: fffffc0b GPR24: fffffe0a GPR25: ffffff09 GPR26: ffffff88 GPR27: ffffffc7 GPR28: ffffffe6 GPR29: fffffff5 GPR30: fffffffc GPR31: 00000040 SR : 00008001 EPCR0: 04000908 EEAR0: fffffffd ESR0 : 00008001 There is an execption at 568th instruction, here is the exception message: "Exception 0x600 (Alignment) at 0x4000908, EA: 0xfffffffd, ppc: 0x4000908, npc: 0x400090c, #568" Why would this exception happen? One more thing here is the report function from support.c. void report(unsigned long value) { asm("l.addi\tr3,%0,0": :"r" (value)); asm("l.nop %0": :"K" (NOP_REPORT)); } You would notice that these statements do not seem to correspond to the statements listed above. Am I missing something? Thanks, Guru ----- Original Message ----- From: Matjaz Breskvarphoenix@o...> To: Date: Wed Jun 23 15:51:16 CEST 2004 Subject: [openrisc] Architecture simulation of basic.S _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

can't tell from all this. you are probably seeing a prologue of report()

Khm khm, your stack pointer R1 is not 32-bit word aligned. This causes problems as evident from the executed.log that you posted. Analysis: in first execution of l.jal insn you have R1 set to 0x1 and this gets substracted by 4 to 0xfffffffd and then a 32-bit store is executed to unaligned address and this causes alignment exeception as indicated by jump to 0x600. Fix: set your R1 properly. If your stack pointer is set by the linker configuration file, align .stack sectyion to 0x4. regards, Damjan ----- Original Message ----- From: gurumurt@c...> To: openrisc@o...> Sent: Wednesday, June 23, 2004 9:11 PM Subject: Re: [openrisc] Architecture simulation of basic.S
as seen from

match with

the basic.S

fffffffa

00007fff

ffffc00f

fffffc0b

ffffffc7

00000040

00008001

fffffffa

00007fff

ffffc00f

fffffc0b

ffffffc7

00000040

00008001

deaddead

fffffffa

00007fff

ffffc00f

fffffc0b

ffffffc7

00000040

00008001

deaddead

fffffffa

00007fff

ffffc00f

fffffc0b

ffffffc7

00000040

00008001

deaddead

fffffffa

00007fff

ffffc00f

fffffc0b

ffffffc7

00000040

exception

0xfffffffd, ppc:

asm("l.addi\tr3,%0,0": :"r" (value)); >
asm("l.nop %0": :"K" (NOP_REPORT)); > } >
correspond to > the statements listed above. Am I missing something? > > Thanks, > Guru > ----- Original Message ----- > From: Matjaz Breskvarphoenix@o...> > To: > Date: Wed Jun 23 15:51:16 CEST 2004 > Subject: [openrisc] Architecture simulation of basic.S > > > * gurumurt@c... (gurumurt@c...) wrote: > > > When I run the basic.or32 thru the or32-uclinux-sim, I get > > into the > > > following problem. > > > > > > One of the last instructions in the file is; > > > l.jal _report > >
anywhere in the > > file. When I simulate it > > >
(architecture simulation) it translates the above statement to >

somewhere in that space it > > encounters > > > a
jump to 0 and goes into an infinite loop of staying at 0th >

"run_sw" since it > > keeps on writing on > >

What should I do to avert this problem? Specifically, where >

I changed the orp.ld file's. Now the stack section looks like this:

.stack ALIGN(8192);
{
*(.stack)

_src_addr = .;
} > ram

But the problem still occurs. I am using the basic.S program from the

or1k/orp/orp_soc/sw/basic package without changing anything. Is the
expected value for r1 at statement "l.jal _report" 1 for that program?

* gurumurt@c... (gurumurt@c...) wrote:
this:
aligning to just 0x4 woun't work since r1 has value 0x1, aligning
it will
just make it 0x4, but you need more space for stack. let's try this
way

FILL(0);
. = ALIGN(8192);

this should make some space on stack... now please check
that somewhere value of symbol '_src_addr' gets loaded to r1
l.movhi r1,hi(_src_addr)
l.ori r1,r1,lo(_src_addr)

from the
if you still get 0x600 exception then either aligning didn't work,
program
doesn't load _src_addr into r1 or it gets corrupted in the first
place.
just trace the execution and make sure that r1 gets the proper
value
at the first place and than look where it changes...

Is the

for that program?
to be honest i do not know. it could be just a test for unaligned
access or
something. if you'll still have problems i'll take a closer look.
ok?
best regards,
p.

Now Iam getting the following error, when I run or32-uclinux-sim, even
before I reach the sim> prompt:


Section: .reset, vaddr: 0x04000000, paddr: 0x04000000, offset:
0x00004000, size: 0x000001a0
EXCEPTION: write out of memory (32-bit access to 04000000)
Exception 0x200 (Bus Error) at 0x0, EA: 0x0, ppc: 0x0, npc: 0x0, #0
EXCEPTION: write out of memory (32-bit access to 04000004)
Exception 0x200 (Bus Error) at 0x0, EA: 0x0, ppc: 0x0, npc: 0x0, #0
EXCEPTION: write out of memory (32-bit access to 04000008)
Exception 0x200 (Bus Error) at 0x0, EA: 0x0, ppc: 0x0, npc: 0x0, #0
....
.....
EXCEPTION: write out of memory (32-bit access to 04000c90)
Exception 0x200 (Bus Error) at 0x0, EA: 0x0, ppc: 0x0, npc: 0x0, #0

In the orp.ld file flash is configured to start at 0x4000000. Hence my
program is not loaded on to the flash memory. What could be the
reason for this?
Here is my orp.ld file .

*********************************************************************************** MEMORY { vectors : ORIGIN = 0x00000000, LENGTH = 0x00002000 flash : ORIGIN = 0x04000000, LENGTH = 0x00200000 ram : ORIGIN = 0x00002000, LENGTH = 0x001fe000 icm : ORIGIN = 0x00800000, LENGTH = 0x00004000 } SECTIONS { .reset : { *(.reset) } > flash .text ALIGN(0x04): { *(.text) } > flash .rodata : { *(.rodata) } > flash .dummy ALIGN(0x04): { _src_beg = .; } > flash .vectors : AT ( ADDR (.dummy) ) { _vec_start = .; *(.vectors) _vec_end = .; } > vectors .icm : AT ( ADDR (.dummy) + SIZEOF (.vectors) ) { _icm_start = .; *(.icm) _icm_end = .; } > icm .data : AT ( ADDR (.dummy) + SIZEOF (.vectors) + SIZEOF(.icm) ) { _dst_beg = .; *(.data) _dst_end = .; } > ram .bss : { *(.bss) } > ram .stack ALIGN(8192): { *(.stack) FILL(0); . = ALIGN(8192); _src_addr = .; } > ram } *********************************************************************************** Thanks, Sankar ----- Original Message ----- From: Matjaz Breskvarphoenix@o...> To: Date: Wed Jun 23 23:55:10 CEST 2004 Subject: [openrisc] Architecture simulation of basic.S _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc