Re: [openrisc] Boot up...

[Marko Mlinar <markom@opencores.org>]

> 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.
You are right. We should stall processor first. Stall is accomplished
using writing to special register in TAP.

> 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....
TAP cannot be accessed by RISC and it drives RISC stall signal.
This signal can be changed via one bit in register.

> 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.
Stall completely stops risc functionality. Exceptions cannot
occur. 

> 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.)
Actually not. We just set pc to right value and processor
using mentioned bit in TAP.
BTW: do you think I should add special interface functions
to_set_?bit() and to_get_?_bit()
or should we add more general functions needed later (for
trace):
to_write_tap_reg(regno, data) and to_read_tap_reg(regno)

> Can I do this over the JTAG interface?
basically everithing can be controled over JTAG.

> 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.)
Faking interrupts from JTAG would be hard one. I don't
know the exact solution right now - but it should be something
like:
if interrupt can be generated via WB, wishbone should be accesed,
if interrupt is external one should access external pins using JTAG.
But I don't think we will need this. Moreover we should avoid 
this solution since it depends on pin configuration...
Maybe Damjan or Igor can answer this.

> 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.
Look above.

> I can't write a realistic simulator for a processor unless I
> understand exactly  how the processor is supposed to work.
regarding that guide through - we were slightly missunderstood:
I can answer any question you like, if I know the answer.
If I don't we should find the solution together. It's perfectly
ok for you (or anybody else) to ask me, I just wanted to say I
don't want to be your documentation reader.

> 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?
I think this is up to me to write this doc, but I would like
finish limited functionality gdb first. I promise I will
write it till tuesday. Is that ok with you?
But I think it is reasonable to expect that you won't have all
specs needed while developing, since all related systems are
still in development.

Unfortunaly there are some things (I already mentioned them to you)
that are not yet in the documentation. I will explain them now.

1. GPR and VFR registers:
Are mapped into spr group 6 like shown (listed sequentally):

/* group 6 - debug */
  "DVR0", "DVR1", "DVR2", "DVR3", "DVR4", "DVR5", "DVR6", "DVR7",
  "DCR0", "DCR1", "DCR2", "DCR3", "DCR4", "DCR5", "DCR6", "DCR7",
  "DMR1", "DMR2", "DCWR0", "DCWR1", "DSR", "DRR", "PC", "?",

  /* general purpose registers */
  "ZERO", "SP", "FP", "A0", "A1", "A2", "A3", "A4",
  "A5", "LR", "R10", "RV", "R12", "R13", "R14", "R15",
  "R16", "R17", "R18", "R19", "R20", "R21", "R22", "R23",
  "R24", "R25", "R26", "R27", "R28", "R29", "R30", "R31",
  /* vector/floating point registers */
  "VFA0",  "VFA1",  "VFA2",  "VFA3",  "VFA4",  "VFA5",  "VFRV ", "VFR7", 
  "VFR8",   "VFR9",  "VFR10", "VFR11", "VFR12", "VFR13", "VFR14",
"VFR15",
  "VFR16", "VFR17", "VFR18", "VFR19", "VFR20", "VFR21", "VFR22",
"VFR23",
  "VFR24", "VFR25", "VFR26", "VFR27", "VFR28", "VFR29", "VFR30", "VFR31"

You should map them in your simulator.

2. memory access
Accesses with regno above 0x80000000 are accesses to memory. (only half
of the memory can be accessed). Maybe later we will add special
reg/mem select bit in TAP.

3. stall/unstall bit and reset bit
Please wait for TAP documentation.

Some remarks about gdb sim interface:
- you would have to have separate thread to run simulator
- I will add another interface function which shoul ease your debugging
  and allow access to or1ksim "console" :
  void (*to_exec_command (char *args, int from_tty));
which executes command specified in args, with space separated args.
from_tty tell us whether this command was called by user.
Make any output you want.
This command will be exeuted using gdb command 'sim'.

Well, I cannot remember any other issues.

regards,
	Marko