Hi Wenhui, Am 02.07.2014 05:08, schrieb Huangwenhui:

We are building a suse arm on our arm-a15 board, Linux kernel is linaro 3.12.0 version, and compiler is arm-linux-gnueabihf-,

For reference, is it about this HiSilicon board? https://wiki.linaro.org/Boards/D01

we got suse source and mount it on by nfsserver.

when I chroot to suse, a error occured like this: sh (81): undefined instruction: pc=b6f76b48

# chroot /mnt/suse_root #[ 35.880000] sh (81): undefined instruction: pc=b6f76b48 #[ 35.890000] Code: e59f3034 e08f2002 e0822003 e5922040 (ecac8b10) #Illegal instruction # cat log #81 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) #81 --- SIGILL (Illegal instruction) @ 0 (0) --- #81 +++ killed by SIGILL +++

Have you tried running any test program with NEON instructions? According to http://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_cores that is non-optional on Cortex-A15, and my Chromebook with working Factory has it in /proc/cpuinfo. Our armv7hl compiler does not require NEON, but glibc may make assumptions that don't apply to your hardware. My colleagues will have more details on what their debugging indicated. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Alex, Our ARM chip don't support the NEON instruction, can you supply a non-NEON instruction SUSE copy? Regards, Huangwenhui

Hi Wenhui(?),

On 02.07.14 05:08, Huangwenhui wrote:

...

Hi,

We are building a suse arm on our arm-a15 board, Linux kernel is linaro 3.12.0 version, and compiler is arm-linux-gnueabihf-,

we got suse source and mount it on by nfsserver.

when I chroot to suse, a error occured like this: sh (81): undefined instruction: pc=b6f76b48

# chroot /mnt/suse_root #[ 35.880000] sh (81): undefined instruction: pc=b6f76b48 #[ 35.890000] Code: e59f3034 e08f2002 e0822003 e5922040 (ecac8b10)

0: e59f3034 ldr r3, [pc, #52] ; 0x3c 4: e08f2002 add r2, pc, r2 8: e0822003 add r2, r2, r3 c: e5922040 ldr r2, [r2, #64] ; 0x40 10: ecac8b10 vstmia ip!, {d8-d15}

The failing instruction is a vector instruction (NEON). From the code flow I would say you're probably in sigsetjmp - either in ld.so or in libc.

But the important question is why a NEON instruction would fail with an illegal intruction trap. Does your kernel have NEON support enabled in its config?

Alex

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 02.07.2014 um 14:16 schrieb Andreas Schwab :

Huangwenhui writes:

...

Our ARM chip don't support the NEON instruction, can you supply a non-NEON instruction SUSE copy?

openSUSE doesn't support soft-float ARM configurations.

It's still hard-float, but without NEON. We used to have builds that worked fine without NEON, as Tegra 2 lacked support for it. But the Tegra 2 was a non-ARM implementation, while this chip should hopefully be ARM Cortex based. Are you 100% sure that there is no NEON support on that chip? If yes, we can try to revive compatibility with non-NEON-compatible cores, but I'm not incredibly fond of the idea, since all ARM Cortex cores should have NEON support. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Wed, Jul 02, 2014 at 02:32:04PM +0200, Alexander Graf wrote:

...

Am 02.07.2014 um 14:16 schrieb Andreas Schwab :

Huangwenhui writes:

...

Our ARM chip don't support the NEON instruction, can you supply a non-NEON instruction SUSE copy?

openSUSE doesn't support soft-float ARM configurations.

It's still hard-float, but without NEON.

We used to have builds that worked fine without NEON, as Tegra 2 lacked support for it. But the Tegra 2 was a non-ARM implementation, while this chip should hopefully be ARM Cortex based.

Are you 100% sure that there is no NEON support on that chip?

If yes, we can try to revive compatibility with non-NEON-compatible cores, but I'm not incredibly fond of the idea, since all ARM Cortex cores should have NEON support.

Ummm... Didn't all the distros agree on VFP3-D16 (i.e. hard-float, non-NEON) as the baseline for cross-distro compatibility for the ARM hard-float ports? Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 02.07.2014 14:32, schrieb Alexander Graf:

the Tegra 2 was a non-ARM implementation,

That's not true AFAIK, Tegra 2 is a dual Cortex-A9 so it must be ARM. And confirming that recent Factory ran fine on tegra20. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 02.07.14 14:46, Steve McIntyre wrote:

On Wed, Jul 02, 2014 at 02:32:04PM +0200, Alexander Graf wrote:

...

...

Am 02.07.2014 um 14:16 schrieb Andreas Schwab :

Huangwenhui writes:

...

Our ARM chip don't support the NEON instruction, can you supply a non-NEON instruction SUSE copy?

openSUSE doesn't support soft-float ARM configurations. It's still hard-float, but without NEON.

We used to have builds that worked fine without NEON, as Tegra 2 lacked support for it. But the Tegra 2 was a non-ARM implementation, while this chip should hopefully be ARM Cortex based.

Are you 100% sure that there is no NEON support on that chip?

If yes, we can try to revive compatibility with non-NEON-compatible cores, but I'm not incredibly fond of the idea, since all ARM Cortex cores should have NEON support.

Ummm...

Didn't all the distros agree on VFP3-D16 (i.e. hard-float, non-NEON) as the baseline for cross-distro compatibility for the ARM hard-float ports?

The idea behind the cross-distro compatibility was to standardize on the ABI and ABI requirements. IIUC these are identical whether you use NEON instructions or not. The fact that code may be compiled with NEON optimizations enabled is thus not an issue of cross-distro compatibility :). It only narrows down the set of hardware that we can run on. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Thu, Jul 03, 2014 at 01:20:14PM +0200, Alexander Graf wrote:

On 02.07.14 14:46, Steve McIntyre wrote:

...

Ummm...

Didn't all the distros agree on VFP3-D16 (i.e. hard-float, non-NEON) as the baseline for cross-distro compatibility for the ARM hard-float ports?

The idea behind the cross-distro compatibility was to standardize on the ABI and ABI requirements. IIUC these are identical whether you use NEON instructions or not.

The fact that code may be compiled with NEON optimizations enabled is thus not an issue of cross-distro compatibility :). It only narrows down the set of hardware that we can run on.

Ah, yes. :-) True, so long as you don't end up with (badly-written?) functions passing so many arguments that they overflow into using the extra NEON VFP registers. Unlikely, I hope! Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 03.07.2014 13:31, schrieb Alexander Graf:

On 02.07.14 15:52, Huangwenhui wrote:

...

...

...

Am 02.07.2014 um 14:16 schrieb Andreas Schwab :

Huangwenhui writes:

...

Our ARM chip don't support the NEON instruction, can you supply a non-NEON instruction SUSE copy?

openSUSE doesn't support soft-float ARM configurations. It's still hard-float, but without NEON. We used to have builds that worked fine without NEON, as Tegra 2 lacked support for it. But the Tegra 2 was a non-ARM implementation, while this chip should hopefully be ARM Cortex based. Are you 100% sure that there is no NEON support on that chip? Yes I do. ARMV7 architecture supports cropping NEON and VFP, we reserved the VFP, cutted off the NEON.

Phew. So how about you try to run the ARMv6 distribution instead? That one does also use hardfloat, but definitely doesn't have any NEON support.

As an easy starting point, you can just use the Raspberry PI image and chroot into that one:

http://download.opensuse.org/repositories/devel:/ARM:/13.1:/Contrib:/Raspber...

Why not just use the ARMv6 rootfs that I pointed to yesterday already? No need for any RPi pieces on Huawei hardware. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org