[opensuse-arm] ask for chroot to suse

older
[opensuse-arm] Re: [RFC 0/4] ARM:...

Huangwenhui

2 Jul 2014 2 Jul '14

03:08

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) #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 +++ What could it? Expect replies. huangwenhui -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Show replies by date

Andreas Färber

2 Jul 2 Jul

06:05

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

Alexander Graf

07:30

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

Huangwenhui

11:41

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

Andreas Schwab

12:16

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. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

12:32

...

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

Andreas Schwab

12:46

Alexander Graf writes:

...

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

Are you sure vstmia is NEON? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Steve McIntyre

12:46

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

Alexander Graf

3 Jul 3 Jul

11:20

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

Steve McIntyre

11:34

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

Alexander Graf

11:37

On 03.07.14 13:34, Steve McIntyre wrote:

...

On Thu, Jul 03, 2014 at 01:20:14PM +0200, Alexander Graf 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

On 02.07.14 14:46, Steve McIntyre wrote: 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!

In between library / application boundaries? Very unlikely hopefully :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Huangwenhui

2 Jul 2 Jul

13:52

...

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

...

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.

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

Alexander Graf

3 Jul 3 Jul

11:31

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... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Färber

13:58

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

Alexander Graf

14:03

On 03.07.14 15:58, Andreas Färber wrote:

...

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.

Ah, sorry, couldn't find that mail (or repo) anymore ;). But yeah, a real rootfs works just the same. The binaries shouldn't differ. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Färber

2 Jul 2 Jul

15:35

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

Andreas Färber

15:45

Hi Wenhui, Am 02.07.2014 13:41, schrieb Huangwenhui:

...

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

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

You could try our armv6hl build: http://download.opensuse.org/ports/armv7hl/factory/images/openSUSE-Factory-A... (note the "armv6" in the file name despite located in armv7hl/ dir) That would be a workaround only, of course. 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

3591

Age (days ago)

3592

Last active (days ago)

List overview

Download

16 comments

5 participants

participants (5)

Alexander Graf
Andreas Färber
Andreas Schwab
Huangwenhui
Steve McIntyre