[U-Boot] armv5 and OMAP3 Question

[U-Boot] armv5 and OMAP3 Question

[Adam Ford]

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.

 (please don't flame me, I am honestly curious).

adam

[U-Boot] armv5 and OMAP3 Question

[Tom Rini]

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.

-- 
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/20170725/bf324a44/attachment.sig>

[U-Boot] armv5 and OMAP3 Question

[Adam Ford]

On Tue, Jul 25, 2017 at 11:08 AM Tom Rini <trini@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?

adam

>
> --
> Tom

[U-Boot] armv5 and OMAP3 Question

[Tom Rini]

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@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.

-- 
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/20180803/dada87df/attachment.sig>

[U-Boot] armv5 and OMAP3 Question

[Adam Ford]

On Fri, Aug 3, 2018 at 10:00 AM Tom Rini <trini@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@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.

adam
>
> --
> Tom

[U-Boot] armv5 and OMAP3 Question

[Tom Rini]

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@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@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.

-- 
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/20180803/bd14b386/attachment.sig>

[U-Boot] armv5 and OMAP3 Question

[Adam Ford]

On Fri, Aug 3, 2018 at 10:20 AM Tom Rini <trini@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@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@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@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.

adam
>
> --
> Tom

[U-Boot] armv5 and OMAP3 Question

[Tom Rini]

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@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@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@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.

-- 
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/02077417/attachment.sig>

[U-Boot] armv5 and OMAP3 Question

[Adam Ford]

On Sat, Aug 4, 2018 at 6:44 AM Tom Rini <trini@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@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@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@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.

adam
>
> --
> Tom

[U-Boot] armv5 and OMAP3 Question

[Tom Rini]

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@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@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@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@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>