Unable to run run-time loaded code on ZedBoard
pggauvin at gmail.com
Wed Oct 28 23:14:12 UTC 2015
> Many thanks for testing this and reporting back. Can you please raise a
> ticket in Trac for this against me?
Sure, I will open one this week.
> Invalidating even entire instruction cache is safe operation
> but costs time to flush and reload instructions
> but calling rtems_cache_invalidate_entire_data() is wrong
> in running system for sure. All changes not pushed to the
> main memory are lost. So probably some part of the code
> written by CPU.
> The rtems_cache_flush_entire_data() should be more appropriate
> and mostly safe but can cause significant latency to reload
> cache as well. It can result in problems when there is ongoing
> DMA transfer from device to memory but only if DMA area
> targets for which there are modified data in CPU cache.
> Such situation caused by write to DMA target area after DMA start
> is code error. There can be problem when DMA area is not
> allocated cache line aligned and at start or end shares area
> with regular modified variables. But support such memory
> use is generally problematic. So sequence
> should be safe. If the area is smaller than cache size then
> use use of regions operations should take shorter
> and generally means less unrelated latencies to unrelated code/data
> void rtems_cache_flush_multiple_data_lines( const void *, size_t );
> void rtems_cache_invalidate_multiple_instruction_lines( const void *, size_t );
> So it would be great if you can test rtems_cache_flush_entire_data() ...
> and then this approach. It would be great if the code ensuring correct
> behavior on cache equipped systems is included in dlopen
> general path.
Good catch, I tested the first approach with the dl01 example and it
works. I will test the second approach this week.
Thank you both,
More information about the users