[openrisc] Boot up...

[Chris Ziomkowski <chris@asics.ws>]

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