|
Message
From: "Tomas Jonsson" <toj@s...>
Date: Thu, 23 Oct 2003 21:32:17 +0200
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
