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
