Cacheable OCM support for the Zynq BSP
Chris Johns
chrisj at rtems.org
Thu Jun 11 02:08:31 UTC 2020
On 11/6/20 10:10 am, Jonathan Brandmeyer wrote:
> On Wed, Jun 10, 2020 at 5:57 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>
> On 11/6/20 9:30 am, Jonathan Brandmeyer wrote:
> > We've patched the RTEMS kernel in order to support using the Zynq on-chip
> memory
> > as inner-cacheable memory. The enclosed patch should apply cleanly to master.
> >
> > 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.
>
> Have the patches been tested with the OCM in the default state?
>
> Yes. Performing a cache flush by virtual address to a line which has Device
> memory attributes appears to be harmless.
>
Great.
Could you please create a ticket for this change and attach the patch? Please
set the milestone to 6. The change might be OK for 5.2 so a new ticket for that
milestone can be created once we have the change merged onto master.
A ticket means the change is not lost as a post to this list.
Thanks
Chris
More information about the devel
mailing list