On Sat, Apr 7, 2012 at 11:07 PM, Richard Herveille <[email protected]>wrote:
> Somehow I thought this was always the case, or always the intended > behaviour. This is what was agreed with Damjan 10years ago. > First action of the bootup code is to clear R0 and invalidate the MMU and > Cache registers. After that the CPU should be ready for normal > bootup-sequence. > The issue is that you can reset the cpu so that it always powers up with a 0 in R0 and the caches and mmus invalidated with very little cost or effort. You are putting a critical requirement on the firmware designer that is non-obvious and hard to debug. Our goal is to make this cpu easy to use. Spending a few hours chasing a problem that turned out to be that you forgot to clear R0 is not going to help anyone. Likewise we should not deal with every problem by simply putting in a status bit that describes how the cpu behaves. Do you really expect that firmware will load in two sets of drivers and only use one of them based on the value that it reads from the status register? Don't put in options unless you know how setting them and reporting there status will get passed between hardware and software designers. Getting that wrong is a big problem in the design world. > > R0 is an always 0 register, it is not null (as in the big iggy-bin). As a > result it can be used as a source register, but it should never be used as > a destination register (exception first instr of boot sequence). > > > Root kit developers love the word "should". They go into your design and find out what happens when they do things that they shouldn't. John Eaton
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
