For me, one of the biggest problems with the OR1K ISA is that it tries to be everything to everyone. Very little in the ISA is mandated, while the toolchains and Linux distributions ignore all these possibilities, i.e., only working for the OR1200.
Much of what you said for debugging purposes can be done by a simple change to the hardware during design time and reset for roll-out. For example, on my hardware, illegal instruction exceptions go to 0x08000000. As far as small codebase systems, it is more appropriate to align the memory subsystem addresses to the interrupt vector than visa-versa. ---Matthew Hicks On Sun, Jan 29, 2012 at 7:01 PM, Ouabache Designworks <[email protected]>wrote: > > > On Sun, Jan 29, 2012 at 3:15 PM, Matthew Hicks <[email protected]>wrote: > >> I think the most important question is why? What does doing this buy us? >> >> >> ---Matthew Hicks >> >> >> >> > > Flexibility. > > I have a small system where the entire codeset fits inside the chip. I can > put that code anywhere in address space and point the reset vector to it. > > > Or my code lives in an external serial flash where the first bytes contain > the code length. I boot into a small internal bootloader that reads the > code > into sram and then points the reset vector to it. You don't have to muck > around with address overlays that have to be switched out on the fly. Those > things scare me. > > Or you put a small barebones debug monitor that is booted when a pin is > strapped to a certain value. These are really useful when bringing a new > system from > scratch. How many times times do people post here asking why their new > design appears dead? Check the power,clock,reset and debug strap and tell > us if > you get serial data out. Great help in debugging > > > John Eaton > >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
