[opensuse-arm] bootstrapping current Factory for ARM

newer
Re: [opensuse-arm] bootstrapping...

Dirk Müller

23 Sep 2011 23 Sep '11

18:12

Hi, The last few days Adrian and I have been working on reviving Base:build:arm, and at least for armv7el we're quite near a complete build. The current state is that we've rebuilt all current sources versions of the toolchain for Factory, and are in a state where it can almost bootstrap itself. I'm saying almost because it seems the gcc4.6 compiler is miscompiling things, so the rpm db corrupts itself quite quickly. I'm still trying to find a fix for that. On the other side we did not get far enough with 4.4 either, so it seems we currently do need a newer compiler. We've also setup openSUSE:Factory:ARM, which is supposed to bootstrap itself and become a complete Factory distribution. We'll be working on this during the next week. Currently this project is empty and not yet building due to some initial issues still. Currently we're building armv7el with softfp, although people have been indicating that we should switch to hardfp, and revive armv5el for the softfp targets. Any other comments? Any help in the form of submitrequests is appreciated :-) Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

Show replies by date

Joop Boonen

23 Sep 23 Sep

20:04

On Fri, September 23, 2011 8:12 pm, Dirk Müller wrote:

...

Hi,

The last few days Adrian and I have been working on reviving Base:build:arm, and at least for armv7el we're quite near a complete build.

That's great to hear. Is it possible to also build armv8el?

...

The current state is that we've rebuilt all current sources versions of the toolchain for Factory, and are in a state where it can almost bootstrap itself.

I'm saying almost because it seems the gcc4.6 compiler is miscompiling things, so the rpm db corrupts itself quite quickly. I'm still trying to find a fix for that. On the other side we did not get far enough with 4.4 either, so it seems we currently do need a newer compiler.

We've also setup openSUSE:Factory:ARM, which is supposed to bootstrap itself and become a complete Factory distribution. We'll be working on this during the next week. Currently this project is empty and not yet building due to some initial issues still.

Currently we're building armv7el with softfp, although people have been indicating that we should switch to hardfp, and revive armv5el for the softfp targets. Any other comments?

Is it possible to also build armv8el? armv7 with hardfp if I'm not mistaken. ( armv7hl ) . That'll get that maximum performance out of Cortex A8/A9.

...

Any help in the form of submitrequests is appreciated :-)

Greetings, Dirk

Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

Andrew Wafaa

25 Sep 25 Sep

08:40

On 23 September 2011 19:12, Dirk Müller wrote:

...

Hi,

The last few days Adrian and I have been working on reviving Base:build:arm, and at least for armv7el we're quite near a complete build.

The current state is that we've rebuilt all current sources versions of the toolchain for Factory, and are in a state where it can almost bootstrap itself.

Great Job! Thanks for choosing to get ARM on openSUSE as your HackWeek project.

...

I'm saying almost because it seems the gcc4.6 compiler is miscompiling things, so the rpm db corrupts itself quite quickly. I'm still trying to find a fix for that. On the other side we did not get far enough with 4.4 either, so it seems we currently do need a newer compiler.

Speaking to some in the Fedora camp, they seem to think that having the latest gcc made a difference, especially ensuring it had the PRs listed in [0]. I'm no compiler expert so I wouldn't like to say. What's the best way of checking, just branch/build/submit?

...

We've also setup openSUSE:Factory:ARM, which is supposed to bootstrap itself and become a complete Factory distribution. We'll be working on this during the next week. Currently this project is empty and not yet building due to some initial issues still.

Currently we're building armv7el with softfp, although people have been indicating that we should switch to hardfp, and revive armv5el for the softfp targets. Any other comments?

My thinking behind preferring hardfp is that the boards/systems that we will hopefully be running on (at least initially) will be the newer variaty which support hardfp. My understanding of the situation is that there is a significant gain if using hardfp vs softfp. Saying that though I am open to being educated on the situation. I know our competitors/peers are all switching to hardfp too.

...

Any help in the form of submitrequests is appreciated :-)

Also help with documentation and beefing out the wiki at [1] would be helpful too :-) Regards, Andy 0 - http://koji.fedoraproject.org/koji/buildinfo?buildID=262575 1 - http://en.opensuse.org/Portal:ARM -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

Peter Czanik

26 Sep 26 Sep

06:01

Hello, On 09/25/2011 10:40 AM, Andrew Wafaa wrote:

...

...
I'm saying almost because it seems the gcc4.6 compiler is miscompiling things, so the rpm db corrupts itself quite quickly. I'm still trying to find a fix for that. On the other side we did not get far enough with 4.4 either, so it seems we currently do need a newer compiler.

Speaking to some in the Fedora camp, they seem to think that having the latest gcc made a difference, especially ensuring it had the PRs listed in [0]. I'm no compiler expert so I wouldn't like to say. What's the best way of checking, just branch/build/submit?

I'm not a compiler expert either, but I was told by Debian developers and at different conferences that using compilers from Linaro (the non-profit Linux development company of ARM, http://www.linaro.org/ ) should give the best results.

...

...
We've also setup openSUSE:Factory:ARM, which is supposed to bootstrap itself and become a complete Factory distribution. We'll be working on this during the next week. Currently this project is empty and not yet building due to some initial issues still.

Currently we're building armv7el with softfp, although people have been indicating that we should switch to hardfp, and revive armv5el for the softfp targets. Any other comments? My thinking behind preferring hardfp is that the boards/systems that we will hopefully be running on (at least initially) will be the newer variaty which support hardfp. My understanding of the situation is that there is a significant gain if using hardfp vs softfp. Saying that though I am open to being educated on the situation. I know our competitors/peers are all switching to hardfp too. When I was at the spring Linaro meeting, there were two EFIKA's displayed next to each other. One was running the regular ARM port, the other ARMHF. Both was running PovRay and rendering the same scene. One was ready in 5 minutes the other over 20 minutes. Of course the difference is not this striking in all use cases, but still visible. The Debian ARMHF port was originally done on EFIKA MX, but runs on many other machines. Some Debian ARMHF links, which might have some useful information. http://wiki.debian.org/ArmHardFloatPort http://wiki.debian.org/ArmHardFloatTodo https://wiki.linaro.org/Linaro-arm-hardfloat Bye, CzP -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

Andrew Wafaa

07:55

On 26 September 2011 07:01, Peter Czanik wrote:

...

I'm not a compiler expert either, but I was told by Debian developers and at different conferences that using compilers from Linaro (the non-profit Linux development company of ARM, http://www.linaro.org/ ) should give the best results.

The only issue with Linaro is they fork upstream tweak and then submit back upstream. This on its own is fine and is how even we use the obs. Problem is that you get a delay between their tweaks being done and their tweaks being accepted and merged upstream. openSUSE have an upstream policy which means we use whatever is upstream first. We could use Linaro's versions of gcc, kernel etc but that would mean that the ARM port isn't a true port of the distro. We (I think I'm safe in saying we for openSUSE here) would much rather just have one repository of source, in this case Factory. I suppose we could use Linaro's versions until the fixes have been accepted upstream and hit Factory. That's something we as a community and those doing the hard work will need to agree and decide on.

...

When I was at the spring Linaro meeting, there were two EFIKA's displayed next to each other. One was running the regular ARM port, the other ARMHF. Both was running PovRay and rendering the same scene. One was ready in 5 minutes the other over 20 minutes. Of course the difference is not this striking in all use cases, but still visible. The Debian ARMHF port was originally done on EFIKA MX, but runs on many other machines. Some Debian ARMHF links, which might have some useful information. http://wiki.debian.org/ArmHardFloatPort http://wiki.debian.org/ArmHardFloatTodo https://wiki.linaro.org/Linaro-arm-hardfloat Bye, CzP

For speed in getting a release done using softfp will probably be easier, although switching to hardfp will require a rebuild and will most likely throw up additional issues. My view is, if we're going to do it and we're targeting ARMv7 which supports hardfp then that's where we should start and get the pain out of the way. I'll admit I'm not 100% clear on the pros & cons but that's where my understanding leads me. I suppose we need to understand if it is possible to have builds for both hardfp and softfp for ARMv7 building and what is involved in that. Maybe we should target softfp first get the bootstrap up and running and then once we can have a decent ARM platform on openSUSE look at doing a hardfp switch. I'm still learning on what's involved so any more experienced input would be appreciated. Regards, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

Guillaume Gardet

08:26

Le 25/09/2011 10:40, Andrew Wafaa a écrit :

...

On 23 September 2011 19:12, Dirk Müller wrote:

...
We've also setup openSUSE:Factory:ARM, which is supposed to bootstrap itself and become a complete Factory distribution. We'll be working on this during the next week. Currently this project is empty and not yet building due to some initial issues still.

Currently we're building armv7el with softfp, although people have been indicating that we should switch to hardfp, and revive armv5el for the softfp targets. Any other comments? My thinking behind preferring hardfp is that the boards/systems that we will hopefully be running on (at least initially) will be the newer variaty which support hardfp. My understanding of the situation is

[...] that there is a significant gain if using hardfp vs softfp. Saying that though I am open to being educated on the situation. I know our competitors/peers are all switching to hardfp too.

According to GCC man page: http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html softfp option uses hardware instructions. Quote: **************************** -mfloat-abi=name Specifies which floating-point ABI to use. Permissible values are: `soft', `softfp' and `hard'. Specifying `soft' causes GCC to generate output containing library calls for floating-point operations. `softfp' allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. `hard' allows generation of floating-point instructions and uses FPU-specific calling conventions. The default depends on the specific target configuration. Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries. **************************** So be sure everyone is speaking about the same thing.

...

[...]

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

Alexander Graf

11:07

On 09/26/2011 10:26 AM, Guillaume Gardet wrote:

...

Le 25/09/2011 10:40, Andrew Wafaa a écrit :

...
On 23 September 2011 19:12, Dirk Müller wrote:

...
We've also setup openSUSE:Factory:ARM, which is supposed to bootstrap itself and become a complete Factory distribution. We'll be working on this during the next week. Currently this project is empty and not yet building due to some initial issues still.

Currently we're building armv7el with softfp, although people have been indicating that we should switch to hardfp, and revive armv5el for the softfp targets. Any other comments? My thinking behind preferring hardfp is that the boards/systems that we will hopefully be running on (at least initially) will be the newer variaty which support hardfp. My understanding of the situation is

[...] that there is a significant gain if using hardfp vs softfp. Saying that though I am open to being educated on the situation. I know our competitors/peers are all switching to hardfp too.

According to GCC man page: http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html softfp option uses hardware instructions. Quote: **************************** -mfloat-abi=name Specifies which floating-point ABI to use. Permissible values are: `soft', `softfp' and `hard'.

Specifying `soft' causes GCC to generate output containing library calls for floating-point operations. `softfp' allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. `hard' allows generation of floating-point instructions and uses FPU-specific calling conventions.

The default depends on the specific target configuration. Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries. ****************************

So be sure everyone is speaking about the same thing.

While VFP is still optional in the architecture, I'd say every system we really want to run openSUSE on should have VFP available. If not, I'd much rather go the PowerPC road and implement an FPU emulator in the kernel rather than confine all user space to a slow ABI. Soon targets without FPU will be gone - and we're not targeting the past here. So yes, we should go with hardfp. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

Joop Boonen

11:42

On Mon, September 26, 2011 1:07 pm, Alexander Graf wrote:

...

On 09/26/2011 10:26 AM, Guillaume Gardet wrote:

...
Le 25/09/2011 10:40, Andrew Wafaa a Ã©crit :

...
On 23 September 2011 19:12, Dirk MÃ¼ller wrote:

...
We've also setup openSUSE:Factory:ARM, which is supposed to bootstrap itself and become a complete Factory distribution. We'll be working on this during the next week. Currently this project is empty and not yet building due to some initial issues still.

Currently we're building armv7el with softfp, although people have been indicating that we should switch to hardfp, and revive armv5el for the softfp targets. Any other comments? My thinking behind preferring hardfp is that the boards/systems that we will hopefully be running on (at least initially) will be the newer variaty which support hardfp. My understanding of the situation is

[...] that there is a significant gain if using hardfp vs softfp. Saying that though I am open to being educated on the situation. I know our competitors/peers are all switching to hardfp too.

According to GCC man page: http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html softfp option uses hardware instructions. Quote: **************************** -mfloat-abi=name Specifies which floating-point ABI to use. Permissible values are: `soft', `softfp' and `hard'.

Specifying `soft' causes GCC to generate output containing library calls for floating-point operations. `softfp' allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. `hard' allows generation of floating-point instructions and uses FPU-specific calling conventions.

The default depends on the specific target configuration. Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries. ****************************

So be sure everyone is speaking about the same thing.

While VFP is still optional in the architecture, I'd say every system we really want to run openSUSE on should have VFP available. If not, I'd much rather go the PowerPC road and implement an FPU emulator in the kernel rather than confine all user space to a slow ABI. Soon targets without FPU will be gone - and we're not targeting the past here.

Would this be comparable to the "wm-FPU-emu is an FPU emulator for Linux"? http://kernelhistory.sourcentral.org/linux-0.99.9/S/294.html I think that would be a great option as the primary support will be new hardware while old hardware is still supported.

...

So yes, we should go with hardfp.

Alex

Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org

4603

Age (days ago)

4606

Last active (days ago)

List overview

Download

7 comments

7 participants

participants (7)

Alexander Graf
Andrew Wafaa
Dirk Müller
Guillaume Gardet
Joop Boonen
Joop Boonen
Peter Czanik