Am 27.08.2015 um 19:41 schrieb Mark Rutland:
> On Mon, Aug 24, 2015 at 08:54:17AM +0100, Markus Niebel wrote:
>> Hello,
>>
>> I'm not an expert in the low level details of this area. So please sorry if
>> there are
>> wrong assumptions in this post post.
>>
>> Hardware: i.MX6 Solo (TQMa6 on custom Mainboard)
>> U-Boot: 2014.10
>> gcc: 4.8.3
>>
>> We see an error using TFTP on i.MX6 that seems to triggered, if the code /
>> data size goes
>> over a limit. Code changes have nothing to do with network stack, network
>> drivers,
>> memory mangement. TFTP will completely unusable: device sees frequently
>> erroneous packages
>> with different of wierd errors. If code stays below this size all works fine.
>>
>> Up to now we checked a lot of things. The following brought us to the
>> assumption, that this
>> could be cache related:
>>
>> dynamically disable data cache before doing TFTP: TFTP works well again
>> running with disabled L2 cache (data cache enabled): TFTP works well again
>>
>> Looking at the code in drivers/net/fec_mxc.c, function fec_recv we see a
>> call to
>> invalidate_dcache_range before accessing the received ethernet data. When
>> looking at
>> the code for invalidate_dcache_range in arch/arm/cpu/armv7/cache_v7.c an
>> comparing
>> how the things done in linux and barebox we noticed that the order of L2
>> chache / data cache
>> invalidation is just swapped there. Applying this to the receive code for
>> fec_mxc,
>> TFTP will work again.
>>
>> Question: is the order of cache invalidation important?
>
> The order is important.
>
> Consider the case where both the external and architected caches contain
> stale (but clean) cache lines for the region you care about.
>
> If you invalidate the architected caches before the external L2, the
> architected caches may speculatively fetch (stale) data from the L2
> before the L2 is cleaned, and so in the end you may still see stale
> data in the architected caches.
>
> If you invalidate the L2 first, the architected caches could
> speculatively fetch from the L2 (stale) or memory (new) while this is in
> progress, but they will then be invalidated, and from then on can only
> fetch the new data.
>
> That assumes that both levels were clean to begin with. If they are not,
> then additional maintenance is required. It's also conceivable that
> caches could be implemented such that the above is insufficient, YMMV.
>
Thank you for the clarification. Given your statement the code in question:
arch/arm/cpu/armv7/cache_v7.c
/*
* Invalidates range in all levels of D-cache/unified cache used:
* Affects the range [start, stop - 1]
*/
void invalidate_dcache_range(unsigned long start, unsigned long stop)
{
v7_dcache_maint_range(start, stop, ARMV7_DCACHE_INVAL_RANGE);
v7_outer_cache_inval_range(start, stop);
}
is wrong - and also the flush_dcache_all logic.
Given
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14802.html
the chache invalidate handler needs to be fixed in a way, that also the
platforms providing
atomic maintenance are taken in account.
Correct me if I'm wrong.
Regards
Markus
> Thanks,
> Mark.
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
