Announce: rmk's nightly builder gets ARM64 support

Announce: rmk's nightly builder gets ARM64 support

[Russell King - ARM Linux]

Today, I have added ARM64 support to my automated nightly kernel builder.
Initially, this will result in ARM64 builds being tested with allnoconfig
and defconfig, and I shall add allmodconfig and allyesconfig to this in
the coming days.

Once that is done and stable, I will investigate adding an ARM Juno
platform to my boot farm so we can run the results of the builder.

Other recent changes have been a disk upgrade, so the builder now has
plenty of disk space to run the allmodconfig and allyesconfig, which
used to fail (or be skipped) when the disk space was low.

I've also added a new ARM target for building the defconfig without a
seed.

As ever, all results are in the usual place, at:

http://www.arm.linux.org.uk/developer/build/

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Announce: rmk's nightly builder gets ARM64 support

[Russell King - ARM Linux]

On Thu, Feb 19, 2015 at 05:12:20PM +0000, Russell King - ARM Linux wrote:
> Today, I have added ARM64 support to my automated nightly kernel builder.
> Initially, this will result in ARM64 builds being tested with allnoconfig
> and defconfig, and I shall add allmodconfig and allyesconfig to this in
> the coming days.
> 
> Once that is done and stable, I will investigate adding an ARM Juno
> platform to my boot farm so we can run the results of the builder.
> 
> Other recent changes have been a disk upgrade, so the builder now has
> plenty of disk space to run the allmodconfig and allyesconfig, which
> used to fail (or be skipped) when the disk space was low.
> 
> I've also added a new ARM target for building the defconfig without a
> seed.
> 
> As ever, all results are in the usual place, at:
> 
> http://www.arm.linux.org.uk/developer/build/

It seems that there's either something wrong with the kernel, or
there's a problem with binutils.

/tmp/cc1B9ysz.s:99: Error: selected processor does not support `aese v0.16b,v1.16b'
/tmp/cc1B9ysz.s:207: Error: selected processor does not support `aesimc v1.16b,v0.16b'
/tmp/cc1B9ysz.s:255: Error: selected processor does not support `aese v0.16b,v1.16b'
/tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
/tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
/tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v3.16b'
/tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
/tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v1.16b'
/tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
/tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
/tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
/tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
/tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v3.16b'
/tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
/tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v1.16b'
/tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
/tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
make[2]: *** [arch/arm64/crypto/aes-ce-cipher.o] Error 1

I've tried both the mainline git version, and the sourceware.org
binutils-gdb.git version, both result in the same errors.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Announce: rmk's nightly builder gets ARM64 support

[Will Deacon]

[adding Ard]

On Thu, Feb 19, 2015 at 06:34:44PM +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 19, 2015 at 05:12:20PM +0000, Russell King - ARM Linux wrote:
> > Today, I have added ARM64 support to my automated nightly kernel builder.
> > Initially, this will result in ARM64 builds being tested with allnoconfig
> > and defconfig, and I shall add allmodconfig and allyesconfig to this in
> > the coming days.
> > 
> > Once that is done and stable, I will investigate adding an ARM Juno
> > platform to my boot farm so we can run the results of the builder.
> > 
> > Other recent changes have been a disk upgrade, so the builder now has
> > plenty of disk space to run the allmodconfig and allyesconfig, which
> > used to fail (or be skipped) when the disk space was low.
> > 
> > I've also added a new ARM target for building the defconfig without a
> > seed.
> > 
> > As ever, all results are in the usual place, at:
> > 
> > http://www.arm.linux.org.uk/developer/build/
> 
> It seems that there's either something wrong with the kernel, or
> there's a problem with binutils.
> 
> /tmp/cc1B9ysz.s:99: Error: selected processor does not support `aese v0.16b,v1.16b'
> /tmp/cc1B9ysz.s:207: Error: selected processor does not support `aesimc v1.16b,v0.16b'
> /tmp/cc1B9ysz.s:255: Error: selected processor does not support `aese v0.16b,v1.16b'
> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v3.16b'
> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v1.16b'
> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v3.16b'
> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v1.16b'
> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
> make[2]: *** [arch/arm64/crypto/aes-ce-cipher.o] Error 1
> 
> I've tried both the mainline git version, and the sourceware.org
> binutils-gdb.git version, both result in the same errors.

It sounds like GCC isn't propagating the march flags down to the assembler,
since we take care in arch/arm64/crypto/Makefile to pass the '+crypto'
option for these files.

It's weird that nobody else is reporting this. I'm not saying that we
shouldn't look at fixing it, but I'd like to understand why you're hitting
this and I'm not as it could reveal a gap in our build testing.

Will

Announce: rmk's nightly builder gets ARM64 support

[Ard Biesheuvel]

On 20 February 2015 at 09:20, Will Deacon <will.deacon@arm.com> wrote:
> [adding Ard]
>
> On Thu, Feb 19, 2015 at 06:34:44PM +0000, Russell King - ARM Linux wrote:
>> On Thu, Feb 19, 2015 at 05:12:20PM +0000, Russell King - ARM Linux wrote:
>> > Today, I have added ARM64 support to my automated nightly kernel builder.
>> > Initially, this will result in ARM64 builds being tested with allnoconfig
>> > and defconfig, and I shall add allmodconfig and allyesconfig to this in
>> > the coming days.
>> >
>> > Once that is done and stable, I will investigate adding an ARM Juno
>> > platform to my boot farm so we can run the results of the builder.
>> >
>> > Other recent changes have been a disk upgrade, so the builder now has
>> > plenty of disk space to run the allmodconfig and allyesconfig, which
>> > used to fail (or be skipped) when the disk space was low.
>> >
>> > I've also added a new ARM target for building the defconfig without a
>> > seed.
>> >
>> > As ever, all results are in the usual place, at:
>> >
>> > http://www.arm.linux.org.uk/developer/build/
>>
>> It seems that there's either something wrong with the kernel, or
>> there's a problem with binutils.
>>
>> /tmp/cc1B9ysz.s:99: Error: selected processor does not support `aese v0.16b,v1.16b'
>> /tmp/cc1B9ysz.s:207: Error: selected processor does not support `aesimc v1.16b,v0.16b'
>> /tmp/cc1B9ysz.s:255: Error: selected processor does not support `aese v0.16b,v1.16b'
>> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
>> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
>> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v3.16b'
>> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
>> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v1.16b'
>> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
>> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
>> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
>> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
>> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v3.16b'
>> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
>> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v1.16b'
>> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
>> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
>> make[2]: *** [arch/arm64/crypto/aes-ce-cipher.o] Error 1
>>
>> I've tried both the mainline git version, and the sourceware.org
>> binutils-gdb.git version, both result in the same errors.
>
> It sounds like GCC isn't propagating the march flags down to the assembler,
> since we take care in arch/arm64/crypto/Makefile to pass the '+crypto'
> option for these files.
>

Yes, this looks like a GCC problem, not binutils, since there are
other .S files in the same folder that contain crypto instructions
that build fine. This particular one is a .c file with AES
instructions in inline asm() (and we pass -march=armv8-a+crypto)

> It's weird that nobody else is reporting this. I'm not saying that we
> shouldn't look at fixing it, but I'd like to understand why you're hitting
> this and I'm not as it could reveal a gap in our build testing.
>
> Will

Announce: rmk's nightly builder gets ARM64 support

[Russell King - ARM Linux]

On Fri, Feb 20, 2015 at 09:24:39AM +0000, Ard Biesheuvel wrote:
> On 20 February 2015 at 09:20, Will Deacon <will.deacon@arm.com> wrote:
> > [adding Ard]
> >
> > On Thu, Feb 19, 2015 at 06:34:44PM +0000, Russell King - ARM Linux wrote:
> >> On Thu, Feb 19, 2015 at 05:12:20PM +0000, Russell King - ARM Linux wrote:
> >> > Today, I have added ARM64 support to my automated nightly kernel builder.
> >> > Initially, this will result in ARM64 builds being tested with allnoconfig
> >> > and defconfig, and I shall add allmodconfig and allyesconfig to this in
> >> > the coming days.
> >> >
> >> > Once that is done and stable, I will investigate adding an ARM Juno
> >> > platform to my boot farm so we can run the results of the builder.
> >> >
> >> > Other recent changes have been a disk upgrade, so the builder now has
> >> > plenty of disk space to run the allmodconfig and allyesconfig, which
> >> > used to fail (or be skipped) when the disk space was low.
> >> >
> >> > I've also added a new ARM target for building the defconfig without a
> >> > seed.
> >> >
> >> > As ever, all results are in the usual place, at:
> >> >
> >> > http://www.arm.linux.org.uk/developer/build/
> >>
> >> It seems that there's either something wrong with the kernel, or
> >> there's a problem with binutils.
> >>
> >> /tmp/cc1B9ysz.s:99: Error: selected processor does not support `aese v0.16b,v1.16b'
> >> /tmp/cc1B9ysz.s:207: Error: selected processor does not support `aesimc v1.16b,v0.16b'
> >> /tmp/cc1B9ysz.s:255: Error: selected processor does not support `aese v0.16b,v1.16b'
> >> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
> >> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
> >> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v3.16b'
> >> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
> >> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v1.16b'
> >> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesimc v0.16b,v0.16b'
> >> /tmp/cc1B9ysz.s:389: Error: selected processor does not support `aesd v0.16b,v2.16b'
> >> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
> >> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
> >> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v3.16b'
> >> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
> >> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v1.16b'
> >> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aesmc v0.16b,v0.16b'
> >> /tmp/cc1B9ysz.s:455: Error: selected processor does not support `aese v0.16b,v2.16b'
> >> make[2]: *** [arch/arm64/crypto/aes-ce-cipher.o] Error 1
> >>
> >> I've tried both the mainline git version, and the sourceware.org
> >> binutils-gdb.git version, both result in the same errors.
> >
> > It sounds like GCC isn't propagating the march flags down to the assembler,
> > since we take care in arch/arm64/crypto/Makefile to pass the '+crypto'
> > option for these files.
> >
> 
> Yes, this looks like a GCC problem, not binutils, since there are
> other .S files in the same folder that contain crypto instructions
> that build fine. This particular one is a .c file with AES
> instructions in inline asm() (and we pass -march=armv8-a+crypto)

Maybe we need to get jk's blog post updated - it's currently on of
the top hits in google, so this is probably going to trip up a lot of
people if they follow the instructions there.

http://jk.ozlabs.org/docs/arm64-toolchain/

So it sounds like possibly the binutils part of those instructions is
fine, it's the gcc part which isn't.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Announce: rmk's nightly builder gets ARM64 support

[Russell King - ARM Linux]

On Fri, Feb 20, 2015 at 09:40:35AM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 20, 2015 at 09:24:39AM +0000, Ard Biesheuvel wrote:
> > Yes, this looks like a GCC problem, not binutils, since there are
> > other .S files in the same folder that contain crypto instructions
> > that build fine. This particular one is a .c file with AES
> > instructions in inline asm() (and we pass -march=armv8-a+crypto)
> 
> Maybe we need to get jk's blog post updated - it's currently on of
> the top hits in google, so this is probably going to trip up a lot of
> people if they follow the instructions there.
> 
> http://jk.ozlabs.org/docs/arm64-toolchain/
> 
> So it sounds like possibly the binutils part of those instructions is
> fine, it's the gcc part which isn't.

Note that it would also be useful to know where to get a working gcc
from (preferably in source form - I doubt there's any Fedora 14
binaries around.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Announce: rmk's nightly builder gets ARM64 support

[Fabio Estevam]

Hi Russell,

On Fri, Feb 20, 2015 at 8:20 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> Note that it would also be useful to know where to get a working gcc
> from (preferably in source form - I doubt there's any Fedora 14
> binaries around.)

The kbuild robot uses the following method:

wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross

make.cross ARCH=arm64  defconfig
make.cross ARCH=arm64

This builds 3.19 fine.

Announce: rmk's nightly builder gets ARM64 support

[Russell King - ARM Linux]

On Fri, Feb 20, 2015 at 08:35:31AM -0200, Fabio Estevam wrote:
> Hi Russell,
> 
> On Fri, Feb 20, 2015 at 8:20 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > Note that it would also be useful to know where to get a working gcc
> > from (preferably in source form - I doubt there's any Fedora 14
> > binaries around.)
> 
> The kbuild robot uses the following method:
> 
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> 
> make.cross ARCH=arm64  defconfig
> make.cross ARCH=arm64
> 
> This builds 3.19 fine.

>From what I can see, this doesn't _build_ a compiler.  It grabs
gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
http://releases.linaro.org/14.08/components/toolchain/binaries
and installs that - which contains a load of binaries.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Announce: rmk's nightly builder gets ARM64 support

[Fabio Estevam]

On Fri, Feb 20, 2015 at 11:38 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> From what I can see, this doesn't _build_ a compiler.  It grabs
> gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
> http://releases.linaro.org/14.08/components/toolchain/binaries
> and installs that - which contains a load of binaries.

That's correct. It uses the pre-built binaries from Linaro.

Announce: rmk's nightly builder gets ARM64 support

[Ard Biesheuvel]

On 20 February 2015 at 13:49, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Feb 20, 2015 at 11:38 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
>> From what I can see, this doesn't _build_ a compiler.  It grabs
>> gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
>> http://releases.linaro.org/14.08/components/toolchain/binaries
>> and installs that - which contains a load of binaries.
>
> That's correct. It uses the pre-built binaries from Linaro.

OK, so this is the command line GCC uses to invoke the assembler when
building aes-ce-cipher.o

 /usr/local/gcc-linaro-aarch64-linux-gnu-4.9-2014.07_linux/bin/../lib/gcc/aarch64-linux-gnu/4.9.1/../../../../aarch64-linux-gnu/bin/as
-v -I /home/ard/linux-2.6/arch/arm64/include -I
arch/arm64/include/generated/uapi -I arch/arm64/include/generated -I
/home/ard/linux-2.6/include -I include -I
/home/ard/linux-2.6/arch/arm64/include/uapi -I
arch/arm64/include/generated/uapi -I /home/ard/linux-2.6/include/uapi
-I include/generated/uapi -I /home/ard/linux-2.6/arch/arm64/crypto -I
arch/arm64/crypto -EL -march=armv8-a+crypto -mabi=lp64 -o
arch/arm64/crypto/aes-ce-cipher.o /tmp/ccqUB3dr.s

So in my case, it correctly relays the -march option to GAS, and it
builds fine. Note that I am not using a bare metal compiler, but I
don't think that that should make a difference.

GCC -v output:

Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-linaro-aarch64-linux-gnu-4.9-2014.07_linux/bin/../libexec/gcc/aarch64-linux-gnu/4.9.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/gcc-linaro-4.9-2014.06/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu
--target=aarch64-linux-gnu
--prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install
--with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc
--enable-languages=c,c++,fortran --disable-multilib --enable-multiarch
--with-arch=armv8-a --with-pkgversion='crosstool-NG
linaro-1.13.1-4.9-2014.07 - Linaro GCC 4.9-2014.06'
--with-bugurl=https://bugs.launchpad.net/gcc-linaro
--enable-__cxa_atexit --disable-libmudflap --enable-libgomp
--disable-libssp
--with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--enable-threads=posix --disable-libstdcxx-pch
--enable-linker-build-id --enable-plugin
--with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc
--enable-c99 --enable-long-long
Thread model: posix
gcc version 4.9.1 20140529 (prerelease) (crosstool-NG
linaro-1.13.1-4.9-2014.07 - Linaro GCC 4.9-2014.06)

Anyone care to try the same with the non-working toolchain?

Announce: rmk's nightly builder gets ARM64 support

[Will Deacon]

On Fri, Feb 20, 2015 at 01:49:22PM +0000, Fabio Estevam wrote:
> On Fri, Feb 20, 2015 at 11:38 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > From what I can see, this doesn't _build_ a compiler.  It grabs
> > gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
> > http://releases.linaro.org/14.08/components/toolchain/binaries
> > and installs that - which contains a load of binaries.
> 
> That's correct. It uses the pre-built binaries from Linaro.

For sources, you can usually just pick up the latest GCC release. For
example, 4.9.2 worked for me:

  ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.bz2

I can't recommend using trunk at the moment (i.e. GCC 5), as we hit some
issues with the PSCI calling code that I plan to post fixes for at -rc1.

Will

Announce: rmk's nightly builder gets ARM64 support

[Russell King - ARM Linux]

On Fri, Feb 20, 2015 at 02:04:40PM +0000, Will Deacon wrote:
> On Fri, Feb 20, 2015 at 01:49:22PM +0000, Fabio Estevam wrote:
> > On Fri, Feb 20, 2015 at 11:38 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > 
> > > From what I can see, this doesn't _build_ a compiler.  It grabs
> > > gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
> > > http://releases.linaro.org/14.08/components/toolchain/binaries
> > > and installs that - which contains a load of binaries.
> > 
> > That's correct. It uses the pre-built binaries from Linaro.
> 
> For sources, you can usually just pick up the latest GCC release. For
> example, 4.9.2 worked for me:
> 
>   ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.bz2
> 
> I can't recommend using trunk at the moment (i.e. GCC 5), as we hit some
> issues with the PSCI calling code that I plan to post fixes for at -rc1.

Thanks, that version of gcc appears to work correctly with the kernel.
I've updated the builder with that.

There's a number of worrying warnings for ldp/stp instructions though.
Is that a binutils issue, or a KVM issue?

I've sent Greg a fix for the drivers/base/component.c warning.

There's a number of warnings in drivers/pci/host/pci-xgene.c which
look like they need resolving - returning NULL from a function which
returns an 'int' has never been valid - has this commit (which seems
to have introduced the problem) actually been tested?

Maybe xgene_pcie_map_bus() is supposed to return a void * ?

commit 350f8be5bb402a1d6804adeba0031926ad246bf1
Author: Rob Herring <robh@kernel.org>
Date:   Fri Jan 9 20:34:49 2015 -0600

    PCI: xgene: Convert to use generic config accessors
    
    Convert the xgene host PCI driver to use the generic config access
    functions.
    
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Tanmay Inamdar <tinamdar@apm.com>
    CC: linux-arm-kernel at lists.infradead.org


-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Announce: rmk's nightly builder gets ARM64 support

[Fabio Estevam]

On Fri, Feb 20, 2015 at 3:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> There's a number of warnings in drivers/pci/host/pci-xgene.c which
> look like they need resolving - returning NULL from a function which
> returns an 'int' has never been valid - has this commit (which seems
> to have introduced the problem) actually been tested?
>
> Maybe xgene_pcie_map_bus() is supposed to return a void * ?

Correct. I have already sent a patch for this:
http://www.spinics.net/lists/linux-pci/msg38743.html

Announce: rmk's nightly builder gets ARM64 support

[Marc Zyngier]

On 20/02/15 17:59, Russell King - ARM Linux wrote:
> On Fri, Feb 20, 2015 at 02:04:40PM +0000, Will Deacon wrote:
>> On Fri, Feb 20, 2015 at 01:49:22PM +0000, Fabio Estevam wrote:
>>> On Fri, Feb 20, 2015 at 11:38 AM, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>>
>>>> From what I can see, this doesn't _build_ a compiler.  It grabs
>>>> gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
>>>> http://releases.linaro.org/14.08/components/toolchain/binaries
>>>> and installs that - which contains a load of binaries.
>>>
>>> That's correct. It uses the pre-built binaries from Linaro.
>>
>> For sources, you can usually just pick up the latest GCC release. For
>> example, 4.9.2 worked for me:
>>
>>   ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.bz2
>>
>> I can't recommend using trunk at the moment (i.e. GCC 5), as we hit some
>> issues with the PSCI calling code that I plan to post fixes for at -rc1.
> 
> Thanks, that version of gcc appears to work correctly with the kernel.
> I've updated the builder with that.
> 
> There's a number of worrying warnings for ldp/stp instructions though.
> Is that a binutils issue, or a KVM issue?

Likely a binutils issue. GAS seems to get confused with the use of XZR
and SP in the same instruction, probably because the two registers share
the same encoding.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Announce: rmk's nightly builder gets ARM64 support

[Will Deacon]

On Fri, Feb 20, 2015 at 05:59:31PM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 20, 2015 at 02:04:40PM +0000, Will Deacon wrote:
> > On Fri, Feb 20, 2015 at 01:49:22PM +0000, Fabio Estevam wrote:
> > > On Fri, Feb 20, 2015 at 11:38 AM, Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> wrote:
> > > 
> > > > From what I can see, this doesn't _build_ a compiler.  It grabs
> > > > gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
> > > > http://releases.linaro.org/14.08/components/toolchain/binaries
> > > > and installs that - which contains a load of binaries.
> > > 
> > > That's correct. It uses the pre-built binaries from Linaro.
> > 
> > For sources, you can usually just pick up the latest GCC release. For
> > example, 4.9.2 worked for me:
> > 
> >   ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.bz2
> > 
> > I can't recommend using trunk at the moment (i.e. GCC 5), as we hit some
> > issues with the PSCI calling code that I plan to post fixes for at -rc1.
> 
> Thanks, that version of gcc appears to work correctly with the kernel.
> I've updated the builder with that.
> 
> There's a number of worrying warnings for ldp/stp instructions though.
> Is that a binutils issue, or a KVM issue?

That one's a binutils issue -- it's erroneously aliasing sp and xzr. I filed
a bug internally with our tools team, so it should be fixed soon.

> I've sent Greg a fix for the drivers/base/component.c warning.
> 
> There's a number of warnings in drivers/pci/host/pci-xgene.c which
> look like they need resolving - returning NULL from a function which
> returns an 'int' has never been valid - has this commit (which seems
> to have introduced the problem) actually been tested?

Yeah, I noticed those but haven't dug into them yet (I also don't have
an xgene).

Will

Announce: rmk's nightly builder gets ARM64 support

[Rob Herring]

On Fri, Feb 20, 2015 at 11:59 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Feb 20, 2015 at 02:04:40PM +0000, Will Deacon wrote:
>> On Fri, Feb 20, 2015 at 01:49:22PM +0000, Fabio Estevam wrote:
>> > On Fri, Feb 20, 2015 at 11:38 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >
>> > > From what I can see, this doesn't _build_ a compiler.  It grabs
>> > > gcc-linaro-aarch64-linux-gnu-4.9-2014.08_linux.tar.xz from
>> > > http://releases.linaro.org/14.08/components/toolchain/binaries
>> > > and installs that - which contains a load of binaries.
>> >
>> > That's correct. It uses the pre-built binaries from Linaro.
>>
>> For sources, you can usually just pick up the latest GCC release. For
>> example, 4.9.2 worked for me:
>>
>>   ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.bz2
>>
>> I can't recommend using trunk at the moment (i.e. GCC 5), as we hit some
>> issues with the PSCI calling code that I plan to post fixes for at -rc1.
>
> Thanks, that version of gcc appears to work correctly with the kernel.
> I've updated the builder with that.
>
> There's a number of worrying warnings for ldp/stp instructions though.
> Is that a binutils issue, or a KVM issue?
>
> I've sent Greg a fix for the drivers/base/component.c warning.
>
> There's a number of warnings in drivers/pci/host/pci-xgene.c which
> look like they need resolving - returning NULL from a function which
> returns an 'int' has never been valid - has this commit (which seems
> to have introduced the problem) actually been tested?
>
> Maybe xgene_pcie_map_bus() is supposed to return a void * ?

There's a fix for this which has not yet landed[1].

Rob

[1] https://patchwork.ozlabs.org/patch/440759/

>
> commit 350f8be5bb402a1d6804adeba0031926ad246bf1
> Author: Rob Herring <robh@kernel.org>
> Date:   Fri Jan 9 20:34:49 2015 -0600
>
>     PCI: xgene: Convert to use generic config accessors
>
>     Convert the xgene host PCI driver to use the generic config access
>     functions.
>
>     Signed-off-by: Rob Herring <robh@kernel.org>
>     Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>     CC: Tanmay Inamdar <tinamdar@apm.com>
>     CC: linux-arm-kernel at lists.infradead.org
>
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.

Announce: rmk's nightly builder gets ARM64 support

[Robert Schwebel]

On Fri, Feb 20, 2015 at 10:20:09AM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 20, 2015 at 09:40:35AM +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 20, 2015 at 09:24:39AM +0000, Ard Biesheuvel wrote:
> > > Yes, this looks like a GCC problem, not binutils, since there are
> > > other .S files in the same folder that contain crypto instructions
> > > that build fine. This particular one is a .c file with AES
> > > instructions in inline asm() (and we pass -march=armv8-a+crypto)
> > 
> > Maybe we need to get jk's blog post updated - it's currently on of
> > the top hits in google, so this is probably going to trip up a lot of
> > people if they follow the instructions there.
> > 
> > http://jk.ozlabs.org/docs/arm64-toolchain/
> > 
> > So it sounds like possibly the binutils part of those instructions is
> > fine, it's the gcc part which isn't.
> 
> Note that it would also be useful to know where to get a working gcc
> from (preferably in source form - I doubt there's any Fedora 14
> binaries around.)

We have an arm 64 bit toolchain in OSELAS.Toolchain:
http://git.pengutronix.de/?p=OSELAS.Toolchain.git

with this ptxconfig:
http://git.pengutronix.de/?p=OSELAS.Toolchain.git;a=blob;f=ptxconfigs/aarch64-v8a-linux-gnu_gcc-4.9.2_glibc-2.20_binutils-2.24_kernel-3.16-sanitized.ptxconfig

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Announce: rmk's nightly builder gets ARM64 support

[Jeremy Kerr]

Hi all,

> Maybe we need to get jk's blog post updated - it's currently on of
> the top hits in google, so this is probably going to trip up a lot of
> people if they follow the instructions there.
> 
> http://jk.ozlabs.org/docs/arm64-toolchain/
> 
> So it sounds like possibly the binutils part of those instructions is
> fine, it's the gcc part which isn't.

I'd be happy to update it, or provide a link to more up-to-date
instructions, if there's something around - just let me know.

Cheers,


Jeremy