From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 20 Dec 2016 08:39:22 -0500 Subject: [U-Boot] [PATCH 1/3] ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra In-Reply-To: References: <1482143465-14584-1-git-send-email-yamada.masahiro@socionext.com> <1482143465-14584-2-git-send-email-yamada.masahiro@socionext.com> <20161219215940.GL4248@bill-the-cat> Message-ID: <20161220133922.GS4248@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Dec 20, 2016 at 01:39:40PM +0900, Masahiro Yamada wrote: > 2016-12-20 6:59 GMT+09:00 Tom Rini : > > 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 > > > > 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: