|
Message
From: gurumurt@c...<gurumurt@c...>
Date: Wed Jun 23 23:50:19 CEST 2004
Subject: [openrisc] Architecture simulation of basic.S
I changed the orp.ld file's. Now the stack section looks like this:
.stack ALIGN(0x04):
{
*(.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?
Also I am using the orp.cfg and orp.ld files unchanged from what they
were when I downloaded them. I am just doing simulations and I am not
doing any sysnthesis or FPGA implementation. Do I need to change
those files?
Thanks,
Guru
----- Original Message -----
From: Damjan Lampret<damjanl@o...>
To:
Date: Wed Jun 23 23:06:45 CEST 2004
Subject: [openrisc] Architecture simulation of basic.S
> 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
> > 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 Breskvar<phoenix@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 > >
> > > > > 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 > > hm, symbol
> _report has to be somewhere else linker would complain. > >
> (any library you're linking with ?) > > regards, > > p.
> > > > > >
> _______________________________________________ >
> http://www.opencores.org/mailman/listinfo/openrisc
>
|
 |
Browse
