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.