[U-Boot] [PATCH 1/2] arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm code

[Tom Rini]

On Tue, Apr 05, 2016 at 10:44:42AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 05-04-16 10:33, Hans de Goede wrote:
> >Hi,
> >
> >On 05-04-16 01:59, 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
> >>
> >>So, I see on the bug you want to know if U-Boot is OK with this patch
> >>series being the fix.  At the high level, yes, borrowing code from the
> >>Linux Kernel is a good clean-up and I'd like to see this series could
> >>clean up things a little more and borrow from cache-v7.S when we could.
> >>
> >>But I'd also push back on the toolchain team.  Are they happy saying
> >>"that code is just too fragile, it's probably relying on undefined
> >>behavior, investigation concluded" ?
> >
> >You should be able to reproduce the problems we're seeing on sunxi
> >yourself. Add a "noinline" to "v7_clean_inval_dcache_level_setway"
> >and then boot on say a lime2 you should see a data abort
> >after "Starting kernel" instead of, well, the kernel starting.
> >
> >Given that just adding a noinline already breaks the code with
> >gcc-5 the "too fragile" thing was my own conclusion really.
> >
> >I'll ask for some more info from the toolchain team in the bug
> >(note you're welcome to join the discussion in bugzilla yourself
> >  creating an account if you don't have one only requires an email
> >  address).

Yes, I added myself to the bug earlier :)

> Answer from Jakub Jelinek who has been helping me from the toolchain side
> with this bug sofar:
> 
> "That would need to answer somebody familiar with the ARM cache flushing
> instructions.  All I can say is that I haven't found any obvious errors on the
> toolchain side when compiling the code.  Ask somebody from Linaro or ARM?"

It's a good thing there's a bunch of Linaro and ARM people around here
right now.  I'll see if I can talk one of them into looking into the
bug.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160405/a503c5ae/attachment.sig>