On 10/6/12, R. Diez <[email protected]> wrote: > Hi OpenRISC gurus: > > newlib uses Special Purpose Register NPC, which is discouraged in the spec: > > These and the GPR registers mapped into SPR space should only > be used for debugging purposes by an external debugger. > Applications should use the l.jal instruction > to obtain the current program counter and arithmethic > instructions to obtain GPR register values. > > I noticed because my OR10 CPU didn't implement such SPRs at the > beginning, as they are not needed for most of the test cases. It may > still be worth leaving them out sometimes to save FPGA resources. > > I also realised that newlib wants to program the Tick Timer on start-up > by writing to TTMR, even if the CPU has been configured without this > unit. I'm not sure whether a timer is a must for newlib, but my simple > newlib test case runs fine without one (provided that the CPU ignores > any writes to TTMR). > > I'm using Peter Gavin's version of newlib, but I guess the problem also > exists in the original one. > > I don't have time at the moment to fix these issues myself, but I still > thought it was worth pointing them out in this mailing list.
The new libgloss crt0.S appears to read the NPC into r3 and then use that value to determine the exception which has occurred eg. (0x500>>6) = byte offset into a table of exception handler pointers. Probably, according to the spec, it should instead just l.jal and use the value in r9 in the or1k_exception_handler function. I see the TTMR is cleared by default in the reset vector (probably to disable any timer interrupts which may occur if the PC was just set back to the reset vector with the timer still running.) The timer isn't enabled or configured by default in newlib (I wouldn't mind a crt0 which did enable the timer by deafult, and therefore simply make available the ticks value to software tests.) This is probably a contentious point, but why shouldn't writing to unimplemented SPRs be alright? Does it say anything about this in the spec? Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
