Hi Wolfgang,
On Tuesday 17 May 2011 04:44 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4DD24BD6.5060608@ti.com you wrote:
Would it be possible to do this even _before_ relocation, so to speed up memory accesses during relocation? Of course, proper invalidates/ flushes will be needed before jumping to the RAM address, but I guess this would save a bit of boot times?
I intentionally kept it after relocation to avoid un-necessary complexities.
Yes, I can understand this. Do you plean to extend this to include relocation n a later step?
Relocation is a case of self-modifying code. In Harvard architectures like armv7 there will be coherency issues unless we flush the entire D-cache(range based operation may be equally or more expensive) and invalidate the entire I-cache.
I would not call this self-modifying code.
In ARM literature this kind of situations are also referred to as "self- modifying". Here is an excerpt from ARM manual gloassary:
Self-modifying code Is code that writes one or more instructions to memory and then executes them.
Regarding the need to flush/invalidate caches when jumping to RAM: yes, we have to flush the D-cache to make sure all data actually has hit the memory. But there should be no need to invalidate the I-cache as we have never been fetching any instructions from this address range, so there cannot be any incorrect entries in cache.
Or am I missing something?
This should be largely ok, but not fool-proof for all processors. For processors such as Cortex-A9 that have speculative and out-of-order execution there is no guarantee that any given memory location is not cached at any given point of time as long as the cache is enabled. Here is an excerpt from the ARMv7 manual(section B2.2.2):
"If a memory location is marked as Cacheable there is no mechanism by which it can be guaranteed not to be allocated to an enabled cache at any time. Any application must assume that any Cacheable memory location can be allocated to any enabled cache at any time."
So, in effect everything has to be flushed to memory before you jump to the new location. There may be a small advantage because flushing from cache allows for bursting to the DDR where as bursting is not possible when d-cache is disabled. But I think this is not worth the trouble.
Well, all the data copy will also use cached writes, which are much
You mean, you will do a range-flush on only the .text section's area?
faster. I think this will result in measurable time differences.
Relocation itself was not taking a huge amount of time in my measurement sometime back. It was about 16 ms for OMAP4.
best regards, Aneesh