Re: [openrisc] Boot up...

["Damjan Lampret" <lampret@opencores.org>]

Maybe I should explain what is the difference between RISC's debug unit and
development interface core of Igor.

Basically debug unit is RISC's internal thing and development interface core
is everything that doesn't make sense to put in the RISC. Either because of
the technology or because of the functionality. Development interface
controls reset of the RISC (by controlling reset logic), it can freeze the
RISC etc.
Also development interface has more system like function. For example it
implements TAP for chip's boundary scan and scan chains to verify chip's
integrity in the production.
At the same it it also provides uniform interface to the debug unit. Ie
development interface can implement JTAG interface to the entire SoC and
therefore to RISC's debug unit or it could implement ICE - you don't have to
modify the RISC to use different external interface. This is very important
because you don't have to repeat verification of the RISC block when you
want to use something else instead of JTAG.

Additionally you can remove development interface in production chip if you
don't need it (maybe because you are doing a really low cost chip where size
matters and/or you have different TAP for BS). And even in this case RISC's
debug unit is self sufficient to run resident monitor on target and do
debugging w/o external debugger hardware.

And with the last featured that I mentioned I should probably expalin two
different ways how debug unit can operate. One way is to cause a breakpoint
exception in the RISC when debug condition is met. another possibility is to
not cause a breakpoint exception but rather just transfer control to the
development interface (it signals to the development interface that debug
condition was met and development interface can freeze the RISC to examine
the situation). This last mode of operation of the debug unit means that
application really runs w/o any breakpoint exceptions (obviously only affect
on the application code is some missing time when RISC was stoped by the
development interface). And of course both modes (they really aren't
distinct modes !) can work in simultaneously.

Said all this, I think we have very advanced debugging capabilities.

regards,
Damjan

----- Original Message -----
From: "Damjan Lampret" <lampret@opencores.org>
To: <openrisc@opencores.org>
Sent: Thursday, May 17, 2001 9:45 PM
Subject: Re: [openrisc] Boot up...


> Hi Chris,
>
> GDB talks to development interface over JTAG. Development interface
controls
> the RISC. Most common way to go is like this:
> - hold reset of the RISC (this can't be done by the RISC because reset
> generation logic is external to the RISC - set a reset in development
> interface register)
> - freeze the RISC (again control register in RISC)
> - release reset
> - feed the RISC with first instruction through DIR
>
> You need to look at the development interface specification to understand
> how host controls the RISC though JTAG and development interface.
>
> Also remember that in our case you don't have entire chip just the
> processor. But it is system on chip and you have some control functions
> outside the RISC.
>
> regards,
> Damjan
>
> ----- Original Message -----
> From: "Chris Ziomkowski" <chris@asics.ws>
> To: <openrisc@opencores.org>
> Sent: Thursday, May 17, 2001 7:12 PM
> Subject: [openrisc] Boot up...
>
>
> > OK,
> >
> > So let me see if I understand what Marko has been telling me
> > about bootup. I really need someone to walk me through the
> > proposed GDB protocol, because this is very confusing and
> > not well documented.
> >
> > First, the processor starts executing random garbage at power
> > up. In effect, the state is undefined. It could be anything. If I
> > simply write to DMR1[ST] at this point, I have no idea what
> > will happen. It will cause a breakpoint exception, but because
> > random garbage has been executed, exceptions could be
> > enabled or disabled, and I have no idea what the exception
> > handler might actually be. There is absolutely no guarantee
> > writing DMR1[ST] will actually do anything. In fact, if exceptions
> > are disabled and the random garbage just happens to be
> > an infinite loop which clears DMR1, then I've accomplished
> > nothing. The exception will be ignored, and my bit will be
> > cleared.
> >
> > First thing I need to do is get exceptions enabled and put
> > something sensible into the breakpoint exception vector
> > at location 0x700. To do this reliably, I need to have the
> > processor stopped or it could be overwriting the code I'm
> > placing at the exception vector (it's executing garbage after
> > all.) However, there is no reliable way to get it to stop....
> >
> > If I write PMR[SME], then it will stop, but it will also wake
> > up if an external interrupt is present. I need to make sure
> > interrupts are disabled also (they could be enabled...I've
> > been executing garbage). But because interrupts are enabled,
> > the processor may wake up between the time I set
> > PMR[SME] and I clear SR[EIR]. In that case, by the time
> > I clear interrupts, the processor could be executing garbage
> > again and reenabling the interrupts. I don't know how likely
> > this scenario is, but I don't like the chance that it is possible.
> > However small, I think we should eliminate this possibilty.
> > We need to add a global halt bit to the PMR which will not
> > respond to any interrupt except reset.
> >
> > However, let's move on. I've gotten the processor to stop.
> > I can now place sensible code at location 0x700 and
> > make sure that SR[EXR] is 1 and SR[EIR] is 1. I now need
> > to simulate an interrupt to get the processor moving again.
> > (If we add the global halt bit as I suggest above, I will also
> > need to load something sensible at 0x100 and the interrupt
> > will need to be a reset.)
> >
> > Can I do this over the JTAG interface?
> >
> > Assume I've found a way.  Before I interrupt to wake the
> > CPU up, I set DMR1[ST]. Now my code that I just loaded
> > is executed at 0x700. It probably does something like make
> > sure interrupts are disabled, and then sets PMR[DME] so
> > that the core stops executing and I can examine whatever
> > I want.
> >
> > gdb knows everything is OK, because it sees DDR[BE]
> > set. gdb now proceeds to download code over the JTAG
> > interface into memory. It then sets the PC to the start of
> > this code, sets SR[EIR], clears DMR1[ST] and wakes
> > the processor up by sending an interrupt. (Again, how
> > do I fake an interrupt over the JTAG interface?) Because
> > this is my code at this point, I could actually leave the
> > core running and locked in an infinite loop with exceptions
> > and interrupts disabled as opposed to using the PMR. I
> > could then simply write to the PC to branch to what I
> > want. (This wouldn't work above because the core is
> > executing garbage, and I have no confidence that what I
> > write will still be there when I change the PC.)
> >
> > If I can reboot over the JTAG interface, and I can get
> > a new bit added to the PMR which ignores all interrupts
> > independent of the state of SR[EIR], then I can
> > understand how this is supposed to work.
> >
> > Otherwise, if  I am missing a crucial step or there is
> > another alternative, then I need someone to walk me
> > through the protocol.
> >
> > I can't write a realistic simulator for a processor unless I
> > understand exactly  how the processor is supposed to work.
> >
> > I know you are all busy with your own efforts, and I respect
> > that, but helping me to understand the bootup sequence and
> > gdb protocol is going to benefit us all. I will need to understand
> > how this works intimately to debug any issues that arise.
> >
> > Can someone spend 2 or 3 hours and write up a short
> > document on how we are planning to implement each
> > piece of gdb functionality? (halt, continue, single step,
> > breakpoint, watchpoint, tracepoint, etc.) What is the
> > protocol flow going to be?
> >
> > Thanks for your assistance,
> >
> > Chris
> > chris@asics.ws
> >
>
>