[U-Boot] [PATCH 1/3] ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra

[Tom Rini <trini@konsulko.com>]

On Tue, Dec 20, 2016 at 01:39:40PM +0900, Masahiro Yamada wrote:
> 2016-12-20 6:59 GMT+09:00 Tom Rini <trini@konsulko.com>:
> > On Mon, Dec 19, 2016 at 07:31:02PM +0900, Masahiro Yamada wrote:
> >> Commit be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to
> >> Kconfig") is misconversion.
> >>
> >> The original logic in include/configs/uniphier.h was as follows:
> >>
> >>   #if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64)
> >>   #define CONFIG_USE_ARCH_MEMSET
> >>   #define CONFIG_USE_ARCH_MEMCPY
> >>   #endif
> >>
> >> This means those configs were enabled when building U-Boot proper,
> >> but disabled when building SPL.  Likewise for Tegra.
> >>
> >> Now "depends on !SPL" prevents any boards with SPL support
> >> from reaching these options.  This changed the behavior for
> >> UniPhier and Tegra SoC family.
> >>
> >> Please notice these two options only control the U-Boot proper
> >> build.  As you see arch/arm/Makefile, ARM-specific memset/memcpy
> >> are never compiled for SPL.  So, __HAVE_ARCH_MEMCPY/MEMSET should
> >> not set for SPL.
> >>
> >> Fixes: be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to Kconfig")
> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >
> > Ah, oops, thanks for spotting that one.
> >
> >> ---
> >>
> >> I am restoring the original behavior for now.
> >> But, I have been wondering if we could remove these options entirely.
> >
> > We cannot.  That was my first attempt and we have a handful of active (I
> > checked) boards with tiny enough SPL constraints that switching to the
> > optimized memcpy/memset push them over size limit and they do not have a
> > "something" to disable to gain the space back.  So I went with asking
> > for asking for a conversion to enable by default these options as widely
> > as possible as it's a good thing by and (no pun intended) large.
> 
> 
> Perhaps, I may be missing something, but I could not understand
> why you were talking about SPL size constraints.
> 
> 
> As far as I understood arch/arm/lib/Makefile,
> arch/arm/lib/memset.o is never compiled for SPL
> in the first place.
> 
> I believe CONFIG_USE_ARCH_MEMSET has no impact to SPL.

Because, blarg, oversight.  We want these available to SPL because it
fixes problems (due to non-optimized memset being so slow) on some
platforms and otherwise is a speed win.  I had been testing changes to
move this all globally over, and found the size problems there.

But... at this point, no, I shouldn't also pull in making these
functions be in SPL as I had intended, I should be good and correct that
part in v2017.03.  And take your Kconfig fix as-is, as it's correct.

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