#4003: Zynq-7000 BSP: Support using OCM as cacheable memory ----------------------------------+-------------------- Reporter: Jonathan Brandmeyer | Owner: (none) Type: enhancement | Status: new Priority: normal | Milestone: 6.1 Component: admin | Version: 5 Severity: normal | Keywords: Blocked By: | Blocking: ----------------------------------+-------------------- Background: During normal startup, the ROM bootloader performs vendor- specific initialization of core 1, and then sits in a wait-for-event loop until a special value has been written to a specific address in OCM. In that state, the MMU has not yet been initialized and core 1 is treating OCM as Device memory.
By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's MMU has already been initialized with the application-defined memory map. I'd like to use the on-chip memory as inner cacheable memory in my application. In order to ensure that the kick address write actually becomes visible to core 1, a cache line flush of the affected line is necessary prior to sending the event that wakes up the other core. I also added an invalidation prior to the kick-address write out of an abundance of caution. it shouldn't be necessary, but I had a hard time proving it definitively. There are a plethora of cache maintenance functions available for the job in RTEMS. I picked an inline helper that operates directly on CP15. The code's commentary suggests that the L2 hasn't been initialized yet, and the higher-level `rtems_cache_*_multiple_data_lines` API affects both L1D and L2. Also, I'm using inner-cacheable/outer-shareable memory attributes for OCM specifically because of where it sits in the SOC's busswork, so it turns out that we *never* need to flush L2 for that memory anyway. This patch also works with the default memory map, which defines upper OCM as Device memory. It is harmless to perform a flush by modified virtual address to memory which is marked as Device memory. -- Ticket URL: <http://devel.rtems.org/ticket/4003> RTEMS Project <http://www.rtems.org/> RTEMS Project
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs