Supported Processor Configurations: Difference between revisions
No edit summary |
m (drop highmem and aliasing cache notes as both are resolved now) |
||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
= Recommendations = | = Hardware Recommendations = | ||
This section contains recommendations, notes, limitations and requirements for the development of hardware systems using Linux-Xtensa. They are oriented more towards hardware designer when they create a new Xtensa processor configuration or design an SOC with Xtensa processors. | |||
== MMU == | == MMU == | ||
Processor configurations | Processor configurations that run Linux should always include the MMU feature. Although Linux also supports MMU-less processors, it is not very well tested and has a lot of pitfalls. If the overhead of an MMU is too big, an alternative open or closed source operating system should be considered. | ||
== Atomic Memory Access Support == | == Atomic Memory Access Support == | ||
| Line 10: | Line 12: | ||
Tensilica's PIF Bridges all support this, but if you are using other bridges, this implementation should be verified. | Tensilica's PIF Bridges all support this, but if you are using other bridges, this implementation should be verified. | ||
Latest revision as of 23:31, 15 October 2014
Hardware Recommendations
This section contains recommendations, notes, limitations and requirements for the development of hardware systems using Linux-Xtensa. They are oriented more towards hardware designer when they create a new Xtensa processor configuration or design an SOC with Xtensa processors.
MMU
Processor configurations that run Linux should always include the MMU feature. Although Linux also supports MMU-less processors, it is not very well tested and has a lot of pitfalls. If the overhead of an MMU is too big, an alternative open or closed source operating system should be considered.
Atomic Memory Access Support
For future compatibility with Linux kernel releases for the Xtensa architecture, please include support for the atomic load-conditional-store S32C1I instruction when designing your memory system. The memory system must provide for the atomic update of a memory location by holding off the load until all other transactions are complete, and holding off any other transactions once the atomic operation has started until it has finished.
Tensilica's PIF Bridges all support this, but if you are using other bridges, this implementation should be verified.