[U-Boot] armv5 and OMAP3 Question
Tom Rini
trini at konsulko.com
Sat Aug 4 15:50:52 UTC 2018
On Sat, Aug 04, 2018 at 09:39:12AM -0500, Adam Ford wrote:
> On Sat, Aug 4, 2018 at 6:44 AM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sat, Aug 04, 2018 at 05:32:18AM -0500, Adam Ford wrote:
> > > On Fri, Aug 3, 2018 at 10:20 AM Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
> > > > > On Fri, Aug 3, 2018 at 10:00 AM Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
> > > > > > > On Tue, Jul 25, 2017 at 11:08 AM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
> > > > > > > >
> > > > > > > > > The readme file for OMAP indicates that we compile using armv5 to "to
> > > > > > > > > allow more compilers to work"
> > > > > > > > >
> > > > > > > > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting
> > > > > > > > > some special assembly insturctions becuse we use armv5. The barriers
> > > > > > > > > defined also indicate we're using CP15 instead of the separate barrier
> > > > > > > > > instructions for armv7 because we're using armv5 instead.
> > > > > > > > >
> > > > > > > > > I just wonder in this day and age when we're noting a GCC version and
> > > > > > > > > generating warnings based on the GCC warning, do we still need to
> > > > > > > > > compile as armv5 any more? It seems like "to allow more compilers to
> > > > > > > > > work" would not really apply any more we're trying to push newer
> > > > > > > > > versions of GCC.
> > > > > > > >
> > > > > > > > So, these are historical notes that really should be corrected.
> > > > > > > > Initially, when ARMv7 support was added, most people did not have
> > > > > > > > compilers new enough to recognize -march=armv7-a. We still even support
> > > > > > > > them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the
> > > > > > > > options are any sort of modern gcc, llvm, ancient gcc). When we move to
> > > > > > > > gcc-6 being the oldest gcc supported for ARM we can fixup those comments
> > > > > > > > and logic as well.
> > > > > > >
> > > > > > > My understanding is that we've made the requirement for GCC 6 now. I
> > > > > > > just pushed a patch which enabled mtune=armv7-a-generic when
> > > > > > > CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on
> > > > > > > omap3_logic. Does it make sense to remove the , -march=armv5 from
> > > > > > > arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A
> > > > > > > implies armv-a?
> > > > > >
> > > > > > Yes, we can probably at least drop the v5 portion of that logic. As
> > > > > > noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a"
> > > > > > as being the appropriate name, or at least did in the past.
> > > > >
> > > > > Can you point me to an example of how to tune armv7 for both GCC and
> > > > > LLVM? I was looking around and I'm not seeing an obvious syntax.
> > > > > I'll do a 2-part patch. One to remove the armv5, and one to enable
> > > > > the armv7 optimization.
> > > >
> > > > In arch/arm/Makefile:
> > > > arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
> > > > $(call cc-option, -march=armv7, -march=armv5))
> > > >
> > > > this works in both cases. And doc/README.clang is correct on how to
> > > > build with LLVM on ARM.
> > >
> > > I reset my head to origin/master, but using the following, I am not
> > > able to build omap3_logic with clang on Ubuntu 18.04:
> > >
> > > make HOSTCC=clang omap3_logic
> > > make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \
> > > CC="clang -target arm-linux-gnueabi" -j8
> > >
> > > arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT block
> > > stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
> > > ^
> > > arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT block
> > > stmiage ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT block
> > > stmiage ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT block
> > > stmiage ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT block
> > > ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go.
> > > ^
> > > arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT block
> > > stmiane ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT block
> > > stmiane ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT block
> > > stmiane ip!, {r1, r3, r8, lr}
> > > ^
> > > arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT block
> > > stmiane ip!, {r1, r3}
> > > ^
> > > arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT block
> > > strne r1, [ip], #4
> > > ^
> > > arch/arm/lib/memset.S:111:2: error: predicated instructions must be in IT block
> > > strbne r1, [ip], #1
> > > ^
> > > arch/arm/lib/memset.S:112:2: error: predicated instructions must be in IT block
> > > strbne r1, [ip], #1
> > > ^
> > > arch/arm/lib/memset.S:114:2: error: predicated instructions must be in IT block
> > > strbne r1, [ip], #1
> > > ^
> > > arch/arm/lib/memset.S:120:2: error: predicated instructions must be in IT block
> > > strblt r1, [ip], #1 @ 1
> > > ^
> > > arch/arm/lib/memset.S:121:2: error: predicated instructions must be in IT block
> > > strble r1, [ip], #1 @ 1
> > > ^
> > > scripts/Makefile.build:314: recipe for target 'arch/arm/lib/memset.o' failed
> > > make[1]: *** [arch/arm/lib/memset.o] Error 1
> > > Makefile:1373: recipe for target 'arch/arm/lib' failed
> > > make: *** [arch/arm/lib] Error 2
> > > aford at aford-IdeaCentre-A730:~/src/u-boot$
> > >
> > > If you have any suggestions, I'm open to try them. I have never used
> > > clang before, but I would really like to get these armv7a
> > > optimizations in to make SPL smaller.
> >
> > I guess I forgot that you will need to turn off ARCH_MEMCPY/ARCH_MEMSET
> > and EFI support for clang. That said, since you're just making sure the
> > right options are being passed in, in both cases, you can also just use
> > V=1 and just build common/main.o or something like that.
>
> I am not getting compiler errors due to the-mtune=generic-armv7-a on
> clang, or at least the clang version that comes with Ubuntu 18.04
>
> clang -target arm-none-eabi -Wp,-MD,common/.main.o.d -nostdinc
> -isystem /usr/lib/llvm-6.0/lib/clang/6.0.0/include -Iinclude
> -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__
> -D__UBOOT__ -Qunused-arguments -Wall -Wstrict-prototypes
> -Wno-format-security -fno-builtin -ffreestanding -std=gnu11
> -fshort-wchar -Os -fno-stack-protector -g -Wno-format-nonliteral
> -Wno-format-invalid-specifier -Wno-gnu -Wno-address-of-packed-member
> -Werror=date-time -D__ARM__ -marm -mabi=aapcs-linux -fno-pic
> -mno-unaligned-access -ffunction-sections -fdata-sections -fno-common
> -ffixed-r9 -msoft-float -mno-movt -pipe -march=armv7-a
> -D__LINUX_ARM_ARCH__=7 -mtune=generic-armv7-a
> -I./arch/arm/mach-omap2/include -D"KBUILD_STR(s)=#s"
> -D"KBUILD_BASENAME=KBUILD_STR(main)"
> -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o common/main.o common/main.c
>
>
> aford at aford-IdeaCentre-A730:~/src/u-boot$ arm-linux-gnueabi-size common/main.o
> text data bss dec hex filename
> 181 0 0 181 b5 common/main.o
>
> If this is good enough for you, I'd like to push a patch that removes
> the armv5 reference in the Makefile, adds mtune to the Makefile and
> removes the armv5 reference in doc/README.omap3.
>
> Stock
> text data bss dec hex filename
> 50910 429 67580 118919 1d087 spl/u-boot-spl
> 540713 22700 327072 890485 d9675 u-boot
>
> Without Armv5
> text data bss dec hex filename
> 50916 429 67580 118925 1d08d spl/u-boot-spl
> 540719 22700 327064 890483 d9673 u-boot
>
> -mtune=generic-armv7-a
> text data bss dec hex filename
> 50932 429 67580 118941 1d09d spl/u-boot-spl
> 540519 22700 327080 890299 d95bb u-boot
>
> SPL grew a little, but U-Boot seems to shrink (with GCC)
>
> I don't know much about the omap3 assembly code found in
> Lowlevel_init.S, but I was hoping someone might know a better way to
> optimize (or eliminate) it.
Sounds good, thanks for digging into this!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180804/a45eae39/attachment.sig>
More information about the U-Boot
mailing list