[RTEMS Project] #4003: Zynq-7000 BSP: Support using OCM as cacheable memory

[RTEMS trac]

#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