From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Wed, 6 Apr 2016 17:22:25 +0200 Subject: [U-Boot] [PATCH 1/2] arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm code In-Reply-To: <20160406145103.GP23166@bill-the-cat> References: <1459794709-21601-1-git-send-email-hdegoede@redhat.com> <20160406145103.GP23166@bill-the-cat> Message-ID: <570529B1.5050300@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 06-04-16 16:51, Tom Rini wrote: > On Mon, Apr 04, 2016 at 08:31:48PM +0200, Hans de Goede wrote: > >> v7_maint_dcache_all() does not work reliable when build with gcc6, >> see: https://bugzilla.redhat.com/show_bug.cgi?id=1318788 >> >> While debugging this I learned that v7_maint_dcache_all() is unreliable >> when build with gcc5 too when it is marked as noinline. >> >> This commit fixes the reliability issues by replacing the C-code with >> the ready to use asm implementation from the kernel. >> >> Given that this code when written as C-code clearly is quite fragile >> (also see the existing comments about the C-code being the way it is >> to get optimal assembly) and that we have a proven asm alternative, >> I believe that this is the best solution. >> >> Note that we actually already have a copy of the kernel's >> v7_flush_dcache_all() in arch/arm/mach-uniphier/arm32/lowlevel_init.S. >> >> We should replace that implementation with a call to this one, but I'm >> leaving this up to people with access to actual unifier hw. With this >> replacement in mind I've kept the original function as is, only renamed >> it to __v7_flush_dcache_all and v7_flush_dcache_all is a wrapper >> saving the registered clobbered by the core __v7_flush_dcache_all code >> >> Signed-off-by: Hans de Goede > > So I was able to talk with a few people and this is the right approach. > The cache routines we're doing here in C must not in fact be done in C. > That things work today with some compilers is not by design. This is at > least a minimally correct thing to do and a more correct thing to do > would be to leverage more of the code from the kernel for cache > functions (and not just for v7). Thanks! I guess that means that we can consider this issue resolved? Which is good news as this was a nasty bug to track down. So are you planning on merging this patch / these 2 patches to master then ? Note that in my testing only the first patch is necessary to fix various sunxi boards no longer booting. Regards, Hans