armv6 tree vs. buildkernel

[Tim Kientzle]

On the BeagleBone, running a very recent armv6 tree:

# make TARGET_CPUTYPE=armv6 buildworld
# make TARGET_CPUTYPE=armv6 KERNCONF=BEAGLEBONE buildkernel
….
--------------------------------------------------------------
>>> stage 3.2: building everything
--------------------------------------------------------------
cd /usr/obj/usr/src/sys/BEAGLEBONE; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=arm  MACHINE=arm  CPUTYPE=armv6 GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac  _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp  VERSION="FreeBSD 10.0-CURRENT arm 1000011"  INSTALL="sh /usr/src/tools/install.sh"  PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel all -DNO_MODULES_OBJ
cc -mlittle-endian -c -x assembler-with-cpp -DLOCORE -O -pipe -march=armv6 -DARM_ARCH_6=1 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -D_ARM_ARCH_6 -ffreestanding -Werror /usr/src/sys/arm/arm/locore.S
In file included from /usr/src/sys/arm/arm/locore.S:38:
./machine/asm.h:139:1: error: "_ARM_ARCH_6" redefined
<command-line>: error: this is the location of the previous definition


One solution to this seems to be to edit sys/arm/include/asm.h to properly redefine these symbols, e.g.,

  #if defined(_ARM_ARCH_7) || defined (__ARM_ARCH_6__) || \
      defined (__ARM_ARCH_6J__)
+ #undef _ARM_ARCH_6
  #define _ARM_ARCH_6
  #endif


After this change, it gets as far as:

cc -mlittle-endian -c -O -pipe -march=armv6 -DARM_ARCH_6=1 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -D_ARM_ARCH_6 -ffreestanding -Werror  /usr/src/sys/kern/kern_clock.c
{standard input}: Assembler messages:
{standard input}:1363: Error: selected processor does not support `dmb'
{standard input}:1382: Error: selected processor does not support `dmb'
*** [kern_clock.o] Error code 1

This seems to be due to some mismatch between sys/arm/include/atomic.h (which is getting ARM_ARCH_7A from somewhere?) and the -march setting.  I hope to track down the details this weekend.

Tim

P.S.  How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for regular "buildworld"?
The only option I can find is to set it explicitly in /etc/src.conf._______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Warner Losh-2]

On Jun 22, 2012, at 10:11 PM, Tim Kientzle wrote:

> On the BeagleBone, running a very recent armv6 tree:
>
> # make TARGET_CPUTYPE=armv6 buildworld
> # make TARGET_CPUTYPE=armv6 KERNCONF=BEAGLEBONE buildkernel
> ….
> --------------------------------------------------------------
>>>> stage 3.2: building everything
> --------------------------------------------------------------
> cd /usr/obj/usr/src/sys/BEAGLEBONE; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=arm  MACHINE=arm  CPUTYPE=armv6 GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac  _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp  VERSION="FreeBSD 10.0-CURRENT arm 1000011"  INSTALL="sh /usr/src/tools/install.sh"  PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel all -DNO_MODULES_OBJ
> cc -mlittle-endian -c -x assembler-with-cpp -DLOCORE -O -pipe -march=armv6 -DARM_ARCH_6=1 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -D_ARM_ARCH_6 -ffreestanding -Werror /usr/src/sys/arm/arm/locore.S
> In file included from /usr/src/sys/arm/arm/locore.S:38:
> ./machine/asm.h:139:1: error: "_ARM_ARCH_6" redefined
> <command-line>: error: this is the location of the previous definition
>
>
> One solution to this seems to be to edit sys/arm/include/asm.h to properly redefine these symbols, e.g.,
>
>  #if defined(_ARM_ARCH_7) || defined (__ARM_ARCH_6__) || \
>      defined (__ARM_ARCH_6J__)
> + #undef _ARM_ARCH_6
>  #define _ARM_ARCH_6
>  #endif
>
>
> After this change, it gets as far as:
>
> cc -mlittle-endian -c -O -pipe -march=armv6 -DARM_ARCH_6=1 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -D_ARM_ARCH_6 -ffreestanding -Werror  /usr/src/sys/kern/kern_clock.c
> {standard input}: Assembler messages:
> {standard input}:1363: Error: selected processor does not support `dmb'
> {standard input}:1382: Error: selected processor does not support `dmb'
> *** [kern_clock.o] Error code 1
>
> This seems to be due to some mismatch between sys/arm/include/atomic.h (which is getting ARM_ARCH_7A from somewhere?) and the -march setting.  I hope to track down the details this weekend.
>
> Tim
>
> P.S.  How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for regular "buildworld"?
> The only option I can find is to set it explicitly in /etc/src.conf

It can't possibly work very well.  We need to get TARGET_ARCH=armv6 working instead of continuing these kludges.

Warner_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Tim Kientzle]

On Jun 23, 2012, at 7:35 AM, Warner Losh wrote:

>>
>> P.S.  How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for regular "buildworld"?
>> The only option I can find is to set it explicitly in /etc/src.conf
>
> It can't possibly work very well.  We need to get TARGET_ARCH=armv6 working instead of continuing these kludges.


Help get me oriented and I'll start grinding through this.

What values of TARGET_ARCH should be supported?

Right now, there are ARCH values of arm and armeb.
Should there be armv6eb?  armv7?

I'm also unclear on the distinction between make's MACHINE_ARCH
and uname -p; are these supposed to be the same?  If so, shouldn't
make be using a sysctl instead of a hard-coded value?

Tim

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Warner Losh-2]

On Jun 23, 2012, at 12:58 PM, Tim Kientzle wrote:

> On Jun 23, 2012, at 7:35 AM, Warner Losh wrote:
>>
>>> P.S.  How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for regular "buildworld"?
>>> The only option I can find is to set it explicitly in /etc/src.conf
>>
>> It can't possibly work very well.  We need to get TARGET_ARCH=armv6 working instead of continuing these kludges.
>
>
> Help get me oriented and I'll start grinding through this.
>
> What values of TARGET_ARCH should be supported?

arm, armeb, armv6 (and maybe armv6eb if they make those).

> Right now, there are ARCH values of arm and armeb.
> Should there be armv6eb?  armv7?

There should be no armv7, since armv6 means v6 and later.  At some point there will be an arm64, I suppose too.

> I'm also unclear on the distinction between make's MACHINE_ARCH
> and uname -p; are these supposed to be the same?  If so, shouldn't
> make be using a sysctl instead of a hard-coded value?

I thought it already did.  That might not be a bad idea.  MACHINE_ARCH and uname -p should be identical.  If they aren't, that's a bug.

I posted patches here before to do all (most?) of MACHINE_ARCH=armv6.  Have you tried them on the armv6 branch?  I've not had a chance to port them over yet.

Warner


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Tim Kientzle]

On Jun 23, 2012, at 12:58 PM, Warner Losh wrote:

>
> On Jun 23, 2012, at 12:58 PM, Tim Kientzle wrote:
>> On Jun 23, 2012, at 7:35 AM, Warner Losh wrote:
>>>
>>>> P.S.  How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for regular "buildworld"?
>>>> The only option I can find is to set it explicitly in /etc/src.conf
>>>
>>> It can't possibly work very well.  We need to get TARGET_ARCH=armv6 working instead of continuing these kludges.
>>
>>
>> Help get me oriented and I'll start grinding through this.
>>
>> What values of TARGET_ARCH should be supported?
>
> arm, armeb, armv6 (and maybe armv6eb if they make those).

So do you consider the -DARM_ARCH_6  and -D_ARM_ARCH_6
defines to be among these "kluges"?

How should the C source identify the architecture and
customize itself?

I'm trying to get a clearer picture of how this *should*
work before I start roto-tilling a lot of code.

>> Right now, there are ARCH values of arm and armeb.
>> Should there be armv6eb?  armv7?
>
> There should be no armv7, since armv6 means v6 and later.  At some point there will be an arm64, I suppose too.

So if someone wants an armv7 tree, they should have
  TARGET=arm
  TARGET_ARCH=armv6
  TARGET_CPUTYPE=armv7

>> I'm also unclear on the distinction between make's MACHINE_ARCH
>> and uname -p; are these supposed to be the same?  If so, shouldn't
>> make be using a sysctl instead of a hard-coded value?
>
> I thought it already did.  That might not be a bad idea.  MACHINE_ARCH and uname -p should be identical.  If they aren't, that's a bug.

Ah.  That helps.  (This certainly isn't true in the current
make source and I can't find where this assumption
is documented.)

> I posted patches here before to do all (most?) of MACHINE_ARCH=armv6.  Have you tried them on the armv6 branch?  I've not had a chance to port them over yet.

I've seen some oblique references to those patches but
haven't tracked them down to study yet.

Is this r234548 in users/imp?

Tim

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Warner Losh-2]

On Jun 23, 2012, at 3:07 PM, Tim Kientzle wrote:

>
> On Jun 23, 2012, at 12:58 PM, Warner Losh wrote:
>
>>
>> On Jun 23, 2012, at 12:58 PM, Tim Kientzle wrote:
>>> On Jun 23, 2012, at 7:35 AM, Warner Losh wrote:
>>>>
>>>>> P.S.  How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for regular "buildworld"?
>>>>> The only option I can find is to set it explicitly in /etc/src.conf
>>>>
>>>> It can't possibly work very well.  We need to get TARGET_ARCH=armv6 working instead of continuing these kludges.
>>>
>>>
>>> Help get me oriented and I'll start grinding through this.
>>>
>>> What values of TARGET_ARCH should be supported?
>>
>> arm, armeb, armv6 (and maybe armv6eb if they make those).
>
> So do you consider the -DARM_ARCH_6  and -D_ARM_ARCH_6
> defines to be among these "kluges"?

Yes.  The compilers built when we're doing armv6 should have them defined.  I believe they are standard.  If not, we should migrate tot he standard defines.  There was some churn in Mips land because of this (some of which I fixed, some of which I caused :).

> How should the C source identify the architecture and
> customize itself?

I'm not sure I understand this question.

> I'm trying to get a clearer picture of how this *should*
> work before I start roto-tilling a lot of code.

Excellent idea.

>>> Right now, there are ARCH values of arm and armeb.
>>> Should there be armv6eb?  armv7?
>>
>> There should be no armv7, since armv6 means v6 and later.  At some point there will be an arm64, I suppose too.
>
> So if someone wants an armv7 tree, they should have
>  TARGET=arm
>  TARGET_ARCH=armv6
>  TARGET_CPUTYPE=armv7

Correct.  This is much the same as if someone wants a nahalem tree on x86:

TARGET=i386
TARGET_ARCH=i386
TARGET_CPUTYPE=nahalem

or

TARGET=amd64
TARGET_ARCH=amd64
TARGET_CPUTYPE=nahalem

to pick which base you are compiling against, and then which optimizations you wish to build for.

>>> I'm also unclear on the distinction between make's MACHINE_ARCH
>>> and uname -p; are these supposed to be the same?  If so, shouldn't
>>> make be using a sysctl instead of a hard-coded value?
>>
>> I thought it already did.  That might not be a bad idea.  MACHINE_ARCH and uname -p should be identical.  If they aren't, that's a bug.
>
> Ah.  That helps.  (This certainly isn't true in the current
> make source and I can't find where this assumption
> is documented.)

I'm not sure it is.  Note that there's a planned migration to bmake soonish.

>> I posted patches here before to do all (most?) of MACHINE_ARCH=armv6.  Have you tried them on the armv6 branch?  I've not had a chance to port them over yet.
>
> I've seen some oblique references to those patches but
> haven't tracked them down to study yet.
>
> Is this r234548 in users/imp?

Yes, that's one of the two intermingled patches.

Warner_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Tim Kientzle]

On Jun 23, 2012, at 3:17 PM, Warner Losh wrote:

>
> On Jun 23, 2012, at 3:07 PM, Tim Kientzle wrote:
>
>> On Jun 23, 2012, at 12:58 PM, Warner Losh wrote:
>>>
>>> On Jun 23, 2012, at 12:58 PM, Tim Kientzle wrote:
>>>> On Jun 23, 2012, at 7:35 AM, Warner Losh wrote:
>>>>>
>>>>>> P.S.  How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for regular "buildworld"?
>>>>>> The only option I can find is to set it explicitly in /etc/src.conf
>>>>>
>>>>> It can't possibly work very well.  We need to get TARGET_ARCH=armv6 working instead of continuing these kludges.
>>>>
>>>>
>>>> Help get me oriented and I'll start grinding through this.
>>>>
>>>> What values of TARGET_ARCH should be supported?
>>>
>>> arm, armeb, armv6 (and maybe armv6eb if they make those).
>>
>> So do you consider the -DARM_ARCH_6  and -D_ARM_ARCH_6
>> defines to be among these "kluges"?
>
> Yes.  The compilers built when we're doing armv6 should have them defined.  I believe they are standard.  If not, we should migrate tot he standard defines.  There was some churn in Mips land because of this (some of which I fixed, some of which I caused :).

Ah, yes.  Of course.  That's the other piece I was missing.

I found a list of the standard defines for GCC; I'll compare this to the current
headers and see if I can fix up any mismatches.  At a cursory glance, it looks like
we're pretty close already.

BTW, I like the way the Chromium folks handled these:

http://www.mail-archive.com/v8-dev@.../msg11102.html

That's a lot clearer than the _ARM_ARCH_6, etc, that we're
currently defining (apparently for the same purpose) in
sys/arm/includes/asm.h.

The current xdev arm/arm GCC seems to default to ARMv4:
$ arm-freebsd-gcc -E -dM /tmp/foo.h  | grep -i arm
#define __ARMEL__ 1
#define __ARM_ARCH_4__ 1
#define __arm__ 1

I'll try your patches; I presume they support an arm/armv6 xdev that defaults to ARMv6.

>> So if someone wants an armv7 tree, they should have
>> TARGET=arm
>> TARGET_ARCH=armv6
>> TARGET_CPUTYPE=armv7
>
> Correct.  This is much the same as if someone wants a nahalem tree on x86:
>
> TARGET=i386
> TARGET_ARCH=i386
> TARGET_CPUTYPE=nahalem

Thanks.  That clarifies a lot.

What is the relation between our ARCH and CPUTYPE and GCC's -march and -mcpu options?  Based on the above, it looks like our ARM CPUTYPE should map to GCC's -march:

http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html


Tim

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"