[U-Boot] ELF_RELOC causes strange I-cache issues

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 20/10/2010 20:49, Wolfgang Denk a ?crit :
> Hello everybody,
>
> after nailing down a few USB and FAT related bugs we had USB running
> stable on i.MX31, but suddenly the current mainline code behaves
> strangely again:
>
> Repeating simple calls like "usb read 80800000 0 1000" will reliably
> hard hang the system after 3...5 calls.
>
> The problem can be avoided by switching off the instruction cache
> (using the "icache off" command).
>
>
> Trying to track down this problem it turns out that somehow the
> ELF_RELOC patches seem to be responsible for it.  I have a source tree
> that works perfectly fine, with I-caches on, and after cherry-picking
> the following commits from the elf_reloc branch the problem appears:
>
> 92d5ecb   2010-10-13 10:10:21   arm: implement ELF relocations
> bafe743   2010-10-13 10:12:52   arm1136, qong: add support for ELF relocations
>
> However, we cannot find a real cause in the modified code.
>
>
> Here my request for help:
>
> - Has anybody experienced similar problems?
>
> - Did your tests of the elf_reloc code include any thorough testing
>    of USB mass storage devices?
>
> - If you have any suitable hardware around, could you please run a few
>    such tests (as mentioned above, a simple "usb read<addr>  0 1000",
>    repeated 5 times or so, should be sufficient. If you want to be
>    sure, increase the block count and repeat more often.
>
>
> All ideas welcome.  Thanks a lot in advance.
>
> Best regards,
>
> Wolfgang Denk

Is the data cache on or off when you experience the issue? If it was on, 
can you try with data cache off and instruction cache on?

If the issue arises when both caches are on, then *maybe* the issue is 
caused by code which was loaded into i-cache *before* it was fixed up, 
or loaded while its fixups were still in the data cache. However this 
does not explain everything, since even with instruction cache off, data 
cache can hold fixups for some time and thus non-cached instruction 
fetches could return the wrong code.

Still, since ELF fixups are some sort of code self-modification, they 
must, according to the ARM doc, be followed by an IMB sequence. The 
exact sequence varies; I will look up and provide the sequence for 
ARM1136 tomorrow -- unless someone else can do it sooner, of course.

Amicalement,
-- 
Albert.