Re: [openrisc] Boot up...

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

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
>