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? Thanks Markus _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
