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). 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. 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. feed backs are welcomed.. with regards, pekon
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
