|
Message
From: "Damjan Lampret" <lampret@o...>
Date: Fri, 24 Oct 2003 08:42:30 +0200
Subject: Re: [openrisc] prefetch problem
Hand written. See sw directory under orp_soc.
regards,
Damjan
----- Original Message -----
From: "Tomas Jonsson" <toj@s...>
To: <openrisc@o...>
Sent: Thursday, October 23, 2003 11:16 PM
Subject: SV: [openrisc] prefetch problem
>
> Is the openRISC test suite available?
> What kind of test cases have you used, hand written or directed random
> generated (assertion or spec based)?
> Regards, Tomas Jonsson
>
> -----Ursprungligt meddelande-----
> Från: owner-openrisc@o...
> [mailto:owner-openrisc@o...]För Damjan Lampret
> Skickat: den 23 oktober 2003 21:35
> Till: openrisc@o...
> Ämne: Re: [openrisc] prefetch problem
>
>
> Did you try to run uClinux on your HW platform? It will hang sooner or
later
> unless you have more or less bugless HW. It puts nice amount of torture on
> HW.
>
> regards,
> Damjan
>
> ----- Original Message -----
> From: "Tomas Jonsson" <toj@s...>
> To: <openrisc@o...>
> Cc: "Tomas Jonsson" <toj@s...>
> Sent: Thursday, October 23, 2003 9:32 PM
> Subject: SV: [openrisc] prefetch problem
>
>
> >
> > When I digged into the new problem appeared after the caches was
switched
> on
> > I discoverred an SRAM controller bug (not opencore). I fixed that one
and
> > simulated further on. Now the first problem does not appear. When I am
> > trying to insert the SRAM controller bug again and verify that the first
> > problem not has something to do with the SRAM controller bug I cannot
trig
> > that thing again. Annoying!!!
> > It is hard to tell if this caused the problem. I realy spend a lot of
time
> > in looking into it and I think I should have seen it if it was the SRAM
> > controller bug in the first place. The SRAM controller bug did not have
> the
> > same behaivour as the first bug. I will let you now if I hit it again.
> >
> > I am using an RTL simulator (Modelsim) and a development board. I am
> > debugging on both environments.
> >
> > The only thing I have changed in ORPMON is the system frequency. To be
> sure
> > of not get into timing problems I am only using 100/16MHz as system
> > frequency.
> >
> > I am only using SRAM (no FLASH). The LD-file is included below. I am
using
> > the same UART base as you are.
> >
> > Thanks for your time
> > Regards, Tomas Jonsson
> >
> > MEMORY
> > {
> > vectors : ORIGIN = 0x00000000, LENGTH = 0x00002000
> > ram : ORIGIN = 0x00002000, LENGTH = 0x00400000 - 0x00002000
> > }
> >
> > SECTIONS
> > {
> > .vectors :
> > {
> > *(.crc)
> > *(.vectors)
> > } > vectors
> >
> > .text :
> > {
> > *(.text)
> > } > ram
> >
> > .data :
> > {
> > *(.data)
> > } > ram
> >
> > .rodata :
> > {
> > *(.rodata)
> > } > ram
> >
> > .bss :
> > {
> > *(.bss)
> > } > ram
> >
> > .stack :
> > {
> > *(.stack)
> > _src_addr = .;
> > } > ram
> > }
> >
> >
> >
> > -----Ursprungligt meddelande-----
> > Från: owner-openrisc@o...
> > [mailto:owner-openrisc@o...]För Damjan Lampret
> > Skickat: den 23 oktober 2003 13:35
> > Till: openrisc@o...
> > Ämne: Re: [openrisc] prefetch problem
> >
> >
> > Tomas,
> >
> > what surprises me is that we have orpmon running on both development
board
> > and not to mention on real silicon implementation (an ASIC). In case you
> > didn't change orpmon then it is really a little bit strange. Can you
> confirm
> > you haven't changed orpmon. Can you send me your binary of orpmon and
also
> > explain your address space (particulary where do you have SRAM, Flash
amd
> > UART) - this should allow me to run your binary of orpmon on a similar
> > environment - if that is going to work I'll ask you to send me your
entire
> > RTL environment. Can you also tell if you are running everything in RTL
> > simulation (the output below is from RTL simulation?). Thanks.
> >
> > regards,
> > Damjan
> >
> > ----- Original Message -----
> > From: "Tomas Jonsson" <toj@s...>
> > To: <openrisc@o...>
> > Sent: Thursday, October 23, 2003 10:28 AM
> > Subject: SV: [openrisc] prefetch problem
> >
> >
> > >
> > > I am not using the latest or1200 rtl but it is not old and I have
> checked
> > if
> > > you did some changes. Anyway I have checked out the latest code now
and
> it
> > > does not change anything. The same problem appears at the same time.
> > >
> > > I have also enabled the caches and it makes the program execute longer
> > (6000
> > > more instructions). The tick interrupt appears in another task. Ii
seems
> > > there is the same problem. I am exploring it right now and I will come
> > back
> > > to you.
> > >
> > > Regards, Tomas
> > >
> > > -----Ursprungligt meddelande-----
> > > Från: owner-openrisc@o...
> > > [mailto:owner-openrisc@o...]För Damjan Lampret
> > > Skickat: den 23 oktober 2003 00:10
> > > Till: openrisc@o...
> > > Ämne: Re: [openrisc] prefetch problem
> > >
> > >
> > > Hi Tomas,
> > >
> > > I'm curious, what happens if you enable instruction cache.
> > >
> > > And of course you are using the latest or1200 rtl, aren't you.
> > >
> > > regards,
> > > Damjan
> > >
> > > ----- Original Message -----
> > > From: "Tomas Jonsson" <toj@s...>
> > > To: <openrisc@o...>
> > > Cc: "Tomas Jonsson" <toj@s...>
> > > Sent: Wednesday, October 22, 2003 11:45 PM
> > > Subject: [openrisc] prefetch problem
> > >
> > >
> > > >
> > > > I have a problem that the last executed instruction is executed
> forever.
> > > It
> > > > happends in the uart_putc() function of orpmon. The uart_putc() has
> > worked
> > > > properly for several times but when a tick interrupt happends in the
> > > middle
> > > > of it the uart_putc() polling loop not work properly. See the
> > instruction
> > > > sequence below.
> > > >
> > > >
> > > > 0xbad0 <uart_putc+124>: l.lbz r3,0x0(r5)
> > > > 0xbad4 <uart_putc+128>: l.andi r3,r3,0x60
> > > > ...
> > > > 0xbbd4 <tick_interrupt+52>: l.jr r9
> > > > 0xbbd8 <tick_interrupt+56>: l.addi r1,r1,0x4
> > > > ...
> > > > 0x2180 <_tick+244>: l.mfspr r31,r0,0x40
> > > > 0x2184 <_tick+248>: l.lwz r31,0x74(r1)
> > > > 0x2188 <_tick+252>: l.lwz r3,0x78(r1)
> > > > 0x218c <_tick+256>: l.addi r1,r1,0x80
> > > > 0x2190 <_tick+260>: l.rfe
> > > >
> > > > 0xbad8 <uart_putc+132>: l.sfne r3,r4
> > > > 0xbadc <uart_putc+136>: l.bf 0xfffffffd
> > > > 0xbae0 <uart_putc+140>: l.nop 0x0
> > > >
> > > > 0xbad0 <uart_putc+124>: l.lbz r3,0x0(r5)
> > > > #(is the never ending instruction, 8c650000)
> > > >
> > > > #after this should the following instr had been executed but never
did
> > > > 0xbad4 <uart_putc+128>: l.andi r3,r3,0x60
> > > > 0xbad8 <uart_putc+132>: l.sfne r3,r4
> > > > 0xbadc <uart_putc+136>: l.bf 0xfffffffd
> > > > 0xbae0 <uart_putc+140>: l.nop 0x0
> > > > ... and so on.
> > > >
> > > > Another strange thing is that the CPU still is doing infinite
> > instruction
> > > > fetch accesses to address 0xbadc. They never stops even if the
> execution
> > > of
> > > > instructions seems to stop?!
> > > >
> > > > The caches are disabled. I have attached a wave dump.
> > > >
> > > > Please can someone help me?
> > > > If you need more information do not hesitate to ask me.
> > > >
> > > > Best regards, Tomas Jonsson
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
>
|
 |
Browse
