just a friendly ping:

Am 24.08.2015 um 09:54 schrieb Markus Niebel:
> 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
> 

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to