From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Niebel Date: Thu, 27 Aug 2015 19:19:01 +0200 Subject: [U-Boot] armv7 DMA and cache mangement functions In-Reply-To: <55DACDA9.1090502@tqsc.de> References: <55DACDA9.1090502@tqsc.de> Message-ID: <55DF4685.9010304@tqsc.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >