This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.
> Cache support will be available soon. However, as Stuart points out, > it requires a minimal MMU setup which is board specific; we use a > Cogent board for development, so that is what will be supported to > start with. Customizing the MMU setup for other boards should be > trivial though. The only thing that would need to go in the board specific HAL would be a data structure describing the static mapping of Virtual to Physical Addresses and the Attributes for each map. The actual MMU and cache setup code can be independent. (Motorola's example MMU/Cache code on their web site does it this way.) > The MMU setup is truly minimal, basically marking the IO memory area > of the Cogent board as Cache Inhibited, so generic MMU support (memory > protection, paging, etc.) is *not* supported yet. What about for memory that is used as buffers by the CPM. Since the CPM transfers data to/from I/O devices to memory but bypasses the cache you have to make sure that you don't wind up with stale data in your cache. I don't know if its the best approach but we got around this by creating two Virtual->Physical mappings for main DRAM memory - one cache enabled, the other cache disabled. When ever we read/write CPM I/O buffers we use the cache inhibited virtual addresses. The nice thing about this is that you can use malloc/free to dynamically allocate buffers for use by the CPM. -- Stuart