On Thu, May 3, 2012 at 10:19 PM, Pekon Gupta <[email protected]> wrote: > Hi Stefan, > > I think we are aligned in Request(2) and Request(3) based on ur input .. > >> "we protected this by making it write (and read?) only in supervisor >> mode?" >> "(That it should be protected should be added to the spec either way)" > [Pekon]: Please explicitly mention that READ(s) to above register should > only be allowed only in supervisor mode.
This is probably what we want. > > > What remains is Request(1).. >> "Or by passing a parameter, although then it'd only be configurable at >> synthesis time." > > [Pekon]: Using parameter is better option, than having extra ports at > boundary of OR1200.. > having configurable during at synthesis time is okay, afterall we are just > taking about "default-value after reset". Anyways you are providing a > Software Register which can be programmed in supervisor mode to update the > final value during boot. > > [Background]: configurability of exception_vector_base_addr "right from > reset" was needed to take care of scenarios where exception happens before > boot-software could update this register. > [Example]: while booting from external interface, when source code is being > downloaded the code from external memory, suddenly an exception is raised. > [Limitation]: With current system, user has to put his default > exception_vectors only at 0x0000. > [Possible Solution]: Using parameter for reset-value of Register > "exception_vector_base_addr". > [Possible Advantages]: > (a) Parameter gives user flexibility to put "default" exception_vectors at > any other place also, say some different address of external_memory itself, > from where code was getting downloaded. Thus user has complete control. > (b) whole code (including default_exception_vectors) can lie in single > external memory (under contiguous memory map). > If I understand you correctly - you want something which lets you set a post-power-on-reset reset exception address prefix? And the reason is that during your next boot (after some other kind of reset, but not power-on-reset) you could get an exception and it shouldn't be handled by the power-on-reset exception handler? This, then, can be used to detect issues on non-power-on-reset, I guess? (If I've misunderstood this, disregard the following.) So, I presume we need just an optional POR exception prefix configurable at synthesis time via a parameter (both its presence and its address.) POR reset code should probably then have to enable a bit somewhere to start using the post-POR exception prefix register for any subsequent non-POR resets? Perhaps this is neater than putting this outside the CPU (making it a feature of the system instead), someting like a set-on-POR enable on the bus that redirects to a ROM which is then disabled after the first reset code has been run and subsequent resets then go to the non-POR-ROM code. It ultimately sounds like useful behaviour, and although I guess being tricky to implement, would help very early bring up debugging. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
