On Thu, May 03, 2012 at 01:10:57PM +0530, Pekon Gupta wrote: > All, > > I think this is nice flexibility to be added, but with some caution.. > May I ask for some updates here..? > > > Request (1): reset-value of all the bits in this register should come from > some config-pins, which are sampled just at next edge of reset de-assertion > (similar to what John Eaton requested earlier). > > [Reason]: Suppose a exception occurs just after boot before, before > software could update these register. so flexibility should come with some > concrete backup. > As OR1200 is becoming popular, it may go into number of systems ranging > from "consumer electronics" to "safety" or "health (medical) critical" > equipments. Some safety/medical systems have to meet strong guidelines to > get certifications from international organizations. At times these > standards test some very corner scenarios, where your system should be > fail-safe or system-recovery should be deterministic in all conditions. > Having some loopholes, where Software can go hay-wire may be discouraging > to use OR1200 in such cases. > Though i agree, there are lot of other checks, which need to be > incorporated in system (as a whole), but at-least we should not introduce > new holes in our system (OR1200). >
Do you really think that's necessary to put in the spec? It seems like an odd requirement to put on implementations: "The reset value has to be configurable by config pins" The reason I'd like to define the reset value to zero is that it makes for backwards compability. If someone really wants to do an implementation that configures the value in hardware right after reset, that's probably fine. > > > Request (2): these bits should be just once-writable after Power-On-Reset. > > [Reason]: This is critical for some security features, which may > maliciously try to update this register, and try to insert its own code in > between by raising exception. > Note: Make it mandatory for software to write this register at-least once > on boot. even with same value as already present. > Would it be enough if 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) > > Request (3): Also, it would be good, if we can group all such boot-time > specific registers in some specific memory-map which can be fire-walled. > > [Reason]: For security reasons, people might not like top-level > applications to see where the actual exception-vectors lie in memory-map. > Hey, by adding the modifiable exception base vector alone, we're already one step closer to hiding where the exception-vectors are ;) Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
