[opensuse-arm] Growing some openSUSE ARMs
Sorry for the cross posting, but I thought it worth the extra noise ;-) One of the things that came out of the recent Geeko Love-In for me was a new project to immerse myself in within openSUSE. Yeah I know, we have enough existing projects already so why create a new one? Simples! Believe it or not but openSUSE is behind the curve in a specific segment, and that segment has yet to explode to its full potential. That segment is ARM. No I'm not talking about your upper body appendages, but the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees. Didn't openSUSE do something about this a while ago? Yes we did. Unfortunately the effort seems to have bitrotted somewhat, there were numerous reasons and I don't even prophesise to know the all either. As such I'm going to try and kickstart things, and see it through and hopefully see it grow. As I mentioned, this idea came up at the conference when I was talking to numerous people (I forget how it all started, but that doesn't really matter). There was an overwhelmingly positive view on the matter, and that for me was all that counts. Now let me be crystal clear here, *THIS WILL NOT BE A ONE MAN SHOW!!* I mentioned previously that my view is that we as a community are pretty lazy at times with getting our hands dirty. As such if you think things are going slow or not going in the direction you would like, don't moan. Get your hands dirty and help make a difference. The process will not be an easy one either, so don't expect a port to magically appear over night. If we're lucky we might be able to have a working port in 6 months. Maybe longer, maybe shorter; ultimately that lies with us as a community. Stage one has begun already thanks to Adrian Schroeter, Alex Graf and Dirk Mueller. Stage one comprises of getting the boot strap process to work. At a cursory level this means getting the packages required for setting up a build chroot environment and for building these packages on the target ARM architecture. This will possibly take a fair amount of time, and no I won't give any timelines for this - how long is a piece of string? openSUSE has a couple of advantages here, 1) we have the OBS which can cross build and if need be cross compile packages for numerous architectures (ARM included) so we are going to make a start with that; 2) SUSE are going to be doing another HackWeek (I think it is next week) which means Adrian, Alex, Dirk and anyone else that has knowledge, experience or interest can join in the fun and pain almost full time for a week - let's not kid ourselves here there is a high probability for lots of pain, but also fun ;-) Thing is HackWeek is not just for SUSE staff, it is also for the community. You can join in and spend some quality time on the project with those that know a whole heap of stuff, and learn from them and maybe even teach them something too. We are going to be targeting ARMv7 nothing older I'm afraid this means CORTEX-A8 and above (looking at A9 primarily and then the new A15 when it's available), it gets too messy otherwise and it is already messy enough.If you have knowledge and experience, please help out. If you don't take part you have no justification to complain - you've got to be in it to win it ;-) So I'm basically just giving you all a heads up on this effort, and will update you as regularly as possible (I'm hoping to do something weekly maybe). In the meantime, if you're interested join #opensuse-arm on Freenode and the opensuse-arm mailing list. *DO NOT HARRASS* for updates, if there is something to say it will be said. If you've got a question, ask and *WAIT* for an answer. If you want to help out but want to know how ask and *WAIT* for an answer. I will try and get something on the wiki soon, with a todo list etc. Thanks and here's to getting our Geeko some ARMs. 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
On Donnerstag 22 September 2011 16:05:44 Andrew Wafaa wrote:
the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees.
The openSUSE member who were allowed to vote decided that openSUSE does not want to run on those “little devices”. http://en.opensuse.org/openSUSE:Strategy says:
openSUSE does not: (...) Work on Mobile or embedded devices. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On 09/22/2011 04:42 PM, Markus Slopianka wrote:
The openSUSE member who were allowed to vote decided that openSUSE does not want to run on those “little devices”. http://en.opensuse.org/openSUSE:Strategy says:
openSUSE does not: (...) Work on Mobile or embedded devices.
The same document also says: "It does not aim to limit anyone within the community to work on what they want!" and "We encourage and enable the users in our community to contribute to openSUSE and to shape its future, lowering participation barriers in our community wherever possible." -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
Markus Slopianka schrieb:
On Donnerstag 22 September 2011 16:05:44 Andrew Wafaa wrote:
the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees.
The openSUSE member who were allowed to vote decided that openSUSE does not want to run on those “little devices”. http://en.opensuse.org/openSUSE:Strategy says:
openSUSE does not: (...) Work on Mobile or embedded devices.
ARM Servers have been the new buzz for a while, due to the energy-saving prospects I'm pretty sure they'll have an interesting market. I guess openSUSE wants to run on those, right? Robert Kaiser -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Thu, September 22, 2011 4:42 pm, Markus Slopianka wrote:
On Donnerstag 22 September 2011 16:05:44 Andrew Wafaa wrote:
the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees.
The openSUSE member who were allowed to vote decided that openSUSE does not want to run on those âlittle devicesâ. http://en.opensuse.org/openSUSE:Strategy says:
openSUSE does not: (...) Work on Mobile or embedded devices.
See also link: http://news.opensuse.org/2011/08/09/strategy-done/ <quote> The future The team noted that the strategy is of course not set in stone for eternity although we probably wont go through this process every year and asked for further feedback in the mass mailing to the membership. Some comments did indeed come in, most notably asking for the ARM port and mobile devices as well as the impact of the openSUSE Foundation. In the future, the strategy documents will surely require some revision. Once somebody in the openSUSE community steps up to do an ARM port, which is likely to attract significant help, the document will have to be revisited to reflect this, just like Tumbleweed resulted in a change. </quote> Joop -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Thu, Sep 22, 2011 at 03:05:44PM +0100, Andrew Wafaa wrote:
We are going to be targeting ARMv7 nothing older I'm afraid this means CORTEX-A8 and above (looking at A9 primarily and then the new A15 when it's available), it gets too messy otherwise and it is already messy enough.If you have knowledge and experience, please help out. If you don't take part you have no justification to complain - you've got to be in it to win it ;-)
I know we talked about this at the openSUSE conference, and I'm glad that you are starting to kick this off, it's great. But, what specific machine are you targeting this to run on to start with? We need some kind of specific platform to aim for besides a semi-vague processor level, in order to get a valid kernel and tool-chain up and running. The kernel specifically is going to be a bit difficult as each individual platform needs tweaks in order to have it work properly due to the lack of discoverable busses (device-tree work notwithstanding). In other words, what box do I need to go buy in order to help make this possible? :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On 09/22/2011 04:56 PM, Greg KH wrote:
In other words, what box do I need to go buy in order to help make this possible? :)
I think BeagleBoard (Cortex-A8) or PandaBoard (Cortex-A9) would be a good start. http://en.wikipedia.org/wiki/BeagleBoard http://en.wikipedia.org/wiki/PandaBoard -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
Am 22.09.2011 um 17:13 schrieb Pavol Rusnak <prusnak@opensuse.org>:
On 09/22/2011 04:56 PM, Greg KH wrote:
In other words, what box do I need to go buy in order to help make this possible? :)
I think BeagleBoard (Cortex-A8) or PandaBoard (Cortex-A9) would be a good start.
http://en.wikipedia.org/wiki/BeagleBoard http://en.wikipedia.org/wiki/PandaBoard
To kick thibgs off (and for easy development), I would target QEMU, so everyone can try it out and attach gdb when needed. I agree though that we need to target one particular board for real hw development, so things don't get more painful than they have to be. I'm reasonably indifferent on what we're targeting there, but it should be < 200€ and widely available. Either way, for bootstrapping going with an emulated platform is probably more useful. Once we have a proper base system, let's go for the real fun and target a board. Alex-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Thu, September 22, 2011 5:22 pm, Alexander Graf wrote:
Am 22.09.2011 um 17:13 schrieb Pavol Rusnak <prusnak@opensuse.org>:
On 09/22/2011 04:56 PM, Greg KH wrote:
In other words, what box do I need to go buy in order to help make this possible? :)
I think BeagleBoard (Cortex-A8) or PandaBoard (Cortex-A9) would be a good start.
http://en.wikipedia.org/wiki/BeagleBoard http://en.wikipedia.org/wiki/PandaBoard
To kick thibgs off (and for easy development), I would target QEMU, so everyone can try it out and attach gdb when needed.
I agree though that we need to target one particular board for real hw development, so things don't get more painful than they have to be. I'm reasonably indifferent on what we're targeting there, but it should be < 200⬠and widely available.
I think the best choice would be the snowball board of the igloo community. http://www.igloocommunity.org/ http://shop.strato.com/epages/61428605.sf/en_GB/?ObjectPath=/Shops/61428605/... It'll set you back 164.00 excluding tax and postage for version with GPS/bluetooth and wifi. The reason why I think the snowball is the best choice is because it's using the ST-Ericsson Nova A9500 processor (Dual Cortex A9 + Mali 400 GPU) like the Samsung Exynos 4210 SoC. The advantage of this board over the pandaboard is that it has a OSS video driver (GPL and MIT license), while the SGX540 driver is closed source. http://www.malideveloper.com/developer-resources/drivers/open-source-mali-gp... I have the the Pandaboard the problem is the current SGX drivers don't work for hardfp, which I think is the best for a openSuSE ARM distro. If it's decided to use this board I wouldn't mind ordering it together with people near me, the postage is quite high 32.56 excluding tax, to the Netherlands. I live in Limburg (SE Netherlands), near Germany and Belgium.
Either way, for bootstrapping going with an emulated platform is probably more useful. Once we have a proper base system, let's go for the real fun and target a board.
Alex-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
Le 22/09/2011 16:56, Greg KH a écrit :
We are going to be targeting ARMv7 nothing older I'm afraid this means CORTEX-A8 and above (looking at A9 primarily and then the new A15 when it's available), it gets too messy otherwise and it is already messy enough.If you have knowledge and experience, please help out. If you don't take part you have no justification to complain - you've got to be in it to win it ;-) I know we talked about this at the openSUSE conference, and I'm glad
On Thu, Sep 22, 2011 at 03:05:44PM +0100, Andrew Wafaa wrote: that you are starting to kick this off, it's great.
But, what specific machine are you targeting this to run on to start with? We need some kind of specific platform to aim for besides a semi-vague processor level, in order to get a valid kernel and tool-chain up and running. The kernel specifically is going to be a bit difficult as each individual platform needs tweaks in order to have it work properly due to the lack of discoverable busses (device-tree work notwithstanding).
In other words, what box do I need to go buy in order to help make this possible? :)
I think we need more than 1 board to check the port. I think Beagleboard, Beagleboard xM or a Pandaboard could be a nice board to develop openSUSE on ARM (in addition to qemu). Firstly, we have to decide what kind of ARM processor we want to support. I think we should target ARMv7 and above Application processor family (Cortex A8, A9 and above) to have enough "power" to run openSUSE. I think we will have poor performances with ARMv5 for openSUSE. Then, we have to decide which optimization (in GCC) we want to enable. I would say : - ARM EABI with ARMv7-a instructions - VFP (vector floating point) - thumb/thumb2 instructions if possible (some packages do not compile with thumb or thumb2 enabled) - NEON (not all processor have it, maybe enable it as an option for video libraries for examples to have good performances) Interesting pages: http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores http://en.wikipedia.org/wiki/ARM_architecture I have experiences in embedded Linux and I have a beagleboard xM, so I can help if you want. But I have no experiences in RPM packaging. AFAIK, someone worked on ARM port some time ago in google summer of code. It could be nice to know what have been done. Cheers, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Thu, September 22, 2011 5:41 pm, Guillaume Gardet wrote:
Le 22/09/2011 16:56, Greg KH a écrit :
We are going to be targeting ARMv7 nothing older I'm afraid this means CORTEX-A8 and above (looking at A9 primarily and then the new A15 when it's available), it gets too messy otherwise and it is already messy enough.If you have knowledge and experience, please help out. If you don't take part you have no justification to complain - you've got to be in it to win it ;-) I know we talked about this at the openSUSE conference, and I'm glad
On Thu, Sep 22, 2011 at 03:05:44PM +0100, Andrew Wafaa wrote: that you are starting to kick this off, it's great.
But, what specific machine are you targeting this to run on to start with? We need some kind of specific platform to aim for besides a semi-vague processor level, in order to get a valid kernel and tool-chain up and running. The kernel specifically is going to be a bit difficult as each individual platform needs tweaks in order to have it work properly due to the lack of discoverable busses (device-tree work notwithstanding).
In other words, what box do I need to go buy in order to help make this possible? :)
I think we need more than 1 board to check the port. I think Beagleboard, Beagleboard xM or a Pandaboard could be a nice board to develop openSUSE on ARM (in addition to qemu).
Firstly, we have to decide what kind of ARM processor we want to support. I think we should target ARMv7 and above Application processor family (Cortex A8, A9 and above) to have enough "power" to run openSUSE. I think we will have poor performances with ARMv5 for openSUSE. Then, we have to decide which optimization (in GCC) we want to enable. I would say : - ARM EABI with ARMv7-a instructions - VFP (vector floating point) - thumb/thumb2 instructions if possible (some packages do not compile with thumb or thumb2 enabled) - NEON (not all processor have it, maybe enable it as an option for video libraries for examples to have good performances)
I think that if you look at the time that it'll take to have a stable distro, I think it would be best to focus on the Cortex A9 (hardfp etc) with or without NEON. Why start with a distro that is already based on "old" hardware. Nearly all tablets are using a Cortex A9 (mostly in the form of a Tegra 2). That has one small downside. This one doesn't have a NEON FPU at least not one that meets the full specs. What are the plans for a openSuSE ARM distro. Where should it run on? I think as a distro it would be useful to have it running on a tablet like the Asus Transformer and upcoming ARM Cortex A15 servers.
Interesting pages: http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores http://en.wikipedia.org/wiki/ARM_architecture
I have experiences in embedded Linux and I have a beagleboard xM, so I can help if you want. But I have no experiences in RPM packaging.
I would like to take part. I have Pandaboard (OMAP4430) and Toshiba AC100 (Tegra2).
AFAIK, someone worked on ARM port some time ago in google summer of code. It could be nice to know what have been done.
Cheers,
Guillaume
Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Thu, 2011-09-22 at 07:56 -0700, Greg KH wrote:
In other words, what box do I need to go buy in order to help make this possible? :)
At the minute no decision has been made on exact hardware. I'm assessing certain opportunities and as soon as any form of decision or recommendation is reached, I'll make an announcement. 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
On Thu, September 22, 2011 4:05 pm, Andrew Wafaa wrote:
Sorry for the cross posting, but I thought it worth the extra noise ;-)
One of the things that came out of the recent Geeko Love-In for me was a new project to immerse myself in within openSUSE. Yeah I know, we have enough existing projects already so why create a new one? Simples! Believe it or not but openSUSE is behind the curve in a specific segment, and that segment has yet to explode to its full potential. That segment is ARM. No I'm not talking about your upper body appendages, but the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees. <snip> .. </snip>
The process will not be an easy one either, so don't expect a port to magically appear over night. If we're lucky we might be able to have a working port in 6 months. Maybe longer, maybe shorter; ultimately that lies with us as a community.
Stage one has begun already thanks to Adrian Schroeter, Alex Graf and Dirk Mueller. Stage one comprises of getting the boot strap process to work. At a cursory level this means getting the packages required for setting up a build chroot environment and for building these packages on the target ARM architecture. This will possibly take a fair amount of time, and no I won't give any timelines for this - how long is a piece of string?
openSUSE has a couple of advantages here, 1) we have the OBS which can cross build and if need be cross compile packages for numerous architectures (ARM included) so we are going to make a start with that;
If I understood correctly the ARM build is currently broken in OBS (build.opensuse.org)?
2) SUSE are going to be doing another HackWeek (I think it is next week) which means Adrian, Alex, Dirk and anyone else that has knowledge, experience or interest can join in the fun and pain almost full time for a week - let's not kid ourselves here there is a high probability for lots of pain, but also fun ;-) Thing is HackWeek is not just for SUSE staff, it is also for the community. You can join in and spend some quality time on the project with those that know a whole heap of stuff, and learn from them and maybe even teach them something too.
We are going to be targeting ARMv7 nothing older I'm afraid this means CORTEX-A8 and above (looking at A9 primarily and then the new A15 when it's available), it gets too messy otherwise and it is already messy enough.If you have knowledge and experience, please help out. If you don't take part you have no justification to complain - you've got to be in it to win it ;-)
So I'm basically just giving you all a heads up on this effort, and will update you as regularly as possible (I'm hoping to do something weekly maybe). In the meantime, if you're interested join #opensuse-arm on Freenode and the opensuse-arm mailing list. *DO NOT HARRASS* for updates, if there is something to say it will be said. If you've got a question, ask and *WAIT* for an answer. If you want to help out but want to know how ask and *WAIT* for an answer. I will try and get something on the wiki soon, with a todo list etc.
I think we should get people like Jan-Simon Möller on board as he started the first openSuSE ARM build in 2009 and also the ARM build in OBS. I think it'll kick-start the ARM port.
Thanks and here's to getting our Geeko some ARMs.
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
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
<snip> Well cool - why did it take us ~ 1.5 years to notice ;) . I just dropped factory pack then as it is too much for just one penguin.
2) SUSE are going to be doing another HackWeek (I think it is next week) which means Adrian, Alex, Dirk and anyone else that has knowledge, experience or interest can join in the fun and pain almost full time for a week - let's not kid ourselves here there is a high probability for lots of pain, but also fun ;-) Thing is HackWeek is not just for SUSE staff, it is also for the community. You can join in and spend some quality time on the project with those that know a whole heap of stuff, and learn from them and maybe even teach them something too.
We are going to be targeting ARMv7 nothing older I'm afraid this means CORTEX-A8 and above (looking at A9 primarily and then the new A15 when it's available), it gets too messy otherwise and it is already messy enough.If you have knowledge and experience, please help out. If you don't take part you have no justification to complain - you've got to be in it to win it ;-)
So I'm basically just giving you all a heads up on this effort, and will update you as regularly as possible (I'm hoping to do something weekly maybe). In the meantime, if you're interested join #opensuse-arm on Freenode and the opensuse-arm mailing list. *DO NOT HARRASS* for updates, if there is something to say it will be said. If you've got a question, ask and *WAIT* for an answer. If you want to help out but want to know how ask and *WAIT* for an answer. I will try and get something on the wiki soon, with a todo list etc.
I think we should get people like Jan-Simon Möller on board as he started the first openSuSE ARM build in 2009 and also the ARM build in OBS. I think it'll kick-start the ARM port.
Thanks and here's to getting our Geeko some ARMs.
So let get a crew together - we have the knowledge and the tools. I'm willing to do my part on the weekends and continue what I did back then. Time to wipe android from the transformer ?! ;) Best, Jan-Simon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
Hello, On 09/23/2011 09:16 PM, Jan-Simon Möller wrote:
<snip>
Well cool - why did it take us ~ 1.5 years to notice ;) . I guess, I was a bit ahead of time when I wrote https://features.opensuse.org/310070 :-)
So let get a crew together - we have the knowledge and the tools. I'm willing to do my part on the weekends and continue what I did back then. I ready to help with packaging. As I learned with PPC, it's often not coding but packaging work, and that's something I can also do.
Time to wipe android from the transformer ?! ;) Or Ubuntu from my EFIKA MX :) Well, that's Linux, but that the one I prefer...
Personally I'd prefer porting to the EFIKA MX. Not only because I already have it, but because it's both an end user device and a developer machine with serial port access & Co. Most of the other ARM based machines are either too developer centric or too much end user. A notable exception is the trimslice, but that's not available in a portable format, like the EFIKA smartbook. Bye, CzP -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
Just a quick reminder that openFATE is the supposed to be the way to discuss ideas like this. And yet, no one has brought up: https://features.opensuse.org/310070 fyi: I don't really think openFATE works all that well because you can't edit the comments down into a readable end-product. A team page on the wiki might be the best way to track plans and options. Greg On Thu, Sep 22, 2011 at 10:05 AM, Andrew Wafaa <awafaa@opensuse.org> wrote:
Sorry for the cross posting, but I thought it worth the extra noise ;-)
One of the things that came out of the recent Geeko Love-In for me was a new project to immerse myself in within openSUSE. Yeah I know, we have enough existing projects already so why create a new one? Simples! Believe it or not but openSUSE is behind the curve in a specific segment, and that segment has yet to explode to its full potential. That segment is ARM. No I'm not talking about your upper body appendages, but the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees.
Didn't openSUSE do something about this a while ago? Yes we did. Unfortunately the effort seems to have bitrotted somewhat, there were numerous reasons and I don't even prophesise to know the all either.
As such I'm going to try and kickstart things, and see it through and hopefully see it grow. As I mentioned, this idea came up at the conference when I was talking to numerous people (I forget how it all started, but that doesn't really matter). There was an overwhelmingly positive view on the matter, and that for me was all that counts. Now let me be crystal clear here, *THIS WILL NOT BE A ONE MAN SHOW!!* I mentioned previously that my view is that we as a community are pretty lazy at times with getting our hands dirty. As such if you think things are going slow or not going in the direction you would like, don't moan. Get your hands dirty and help make a difference.
The process will not be an easy one either, so don't expect a port to magically appear over night. If we're lucky we might be able to have a working port in 6 months. Maybe longer, maybe shorter; ultimately that lies with us as a community.
Stage one has begun already thanks to Adrian Schroeter, Alex Graf and Dirk Mueller. Stage one comprises of getting the boot strap process to work. At a cursory level this means getting the packages required for setting up a build chroot environment and for building these packages on the target ARM architecture. This will possibly take a fair amount of time, and no I won't give any timelines for this - how long is a piece of string?
openSUSE has a couple of advantages here, 1) we have the OBS which can cross build and if need be cross compile packages for numerous architectures (ARM included) so we are going to make a start with that; 2) SUSE are going to be doing another HackWeek (I think it is next week) which means Adrian, Alex, Dirk and anyone else that has knowledge, experience or interest can join in the fun and pain almost full time for a week - let's not kid ourselves here there is a high probability for lots of pain, but also fun ;-) Thing is HackWeek is not just for SUSE staff, it is also for the community. You can join in and spend some quality time on the project with those that know a whole heap of stuff, and learn from them and maybe even teach them something too.
We are going to be targeting ARMv7 nothing older I'm afraid this means CORTEX-A8 and above (looking at A9 primarily and then the new A15 when it's available), it gets too messy otherwise and it is already messy enough.If you have knowledge and experience, please help out. If you don't take part you have no justification to complain - you've got to be in it to win it ;-)
So I'm basically just giving you all a heads up on this effort, and will update you as regularly as possible (I'm hoping to do something weekly maybe). In the meantime, if you're interested join #opensuse-arm on Freenode and the opensuse-arm mailing list. *DO NOT HARRASS* for updates, if there is something to say it will be said. If you've got a question, ask and *WAIT* for an answer. If you want to help out but want to know how ask and *WAIT* for an answer. I will try and get something on the wiki soon, with a todo list etc.
Thanks and here's to getting our Geeko some ARMs.
Regards,
Andy
-- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Thu, Sep 22, 2011 at 03:05:44PM +0100, Andrew Wafaa wrote:
Sorry for the cross posting, but I thought it worth the extra noise ;-)
One of the things that came out of the recent Geeko Love-In for me was a new project to immerse myself in within openSUSE. Yeah I know, we have enough existing projects already so why create a new one? Simples! Believe it or not but openSUSE is behind the curve in a specific segment, and that segment has yet to explode to its full potential. That segment is ARM. No I'm not talking about your upper body appendages, but the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees.
Didn't openSUSE do something about this a while ago? Yes we did. Unfortunately the effort seems to have bitrotted somewhat, there were numerous reasons and I don't even prophesise to know the all either.
</lurk> Hi! If you'd like to join in some cross-distribution discussion about ARM porting etc., please sign up to the cross-distro mailing list hosted by Linaro: http://lists.linaro.org/mailman/listinfo/cross-distro There's already been a big meetup at LPC earlier on this month, and we're resolving to do more regular sessions in the future. If there's anything we can help with, please shout! 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 For additional commands, e-mail: opensuse-arm+help@opensuse.org
On 27.09.2011, at 16:30, Steve McIntyre wrote:
On Thu, Sep 22, 2011 at 03:05:44PM +0100, Andrew Wafaa wrote:
Sorry for the cross posting, but I thought it worth the extra noise ;-)
One of the things that came out of the recent Geeko Love-In for me was a new project to immerse myself in within openSUSE. Yeah I know, we have enough existing projects already so why create a new one? Simples! Believe it or not but openSUSE is behind the curve in a specific segment, and that segment has yet to explode to its full potential. That segment is ARM. No I'm not talking about your upper body appendages, but the architecture that powers most of your little devices (and some bigger ones too). Almost all smartphones, tablets and many other consumer devices are powered by ARM from one of the numerous licensees.
Didn't openSUSE do something about this a while ago? Yes we did. Unfortunately the effort seems to have bitrotted somewhat, there were numerous reasons and I don't even prophesise to know the all either.
</lurk>
Hi!
If you'd like to join in some cross-distribution discussion about ARM porting etc., please sign up to the cross-distro mailing list hosted by Linaro:
Ah, cool. That might be very interesting, yes. Andrew, please join there too :).
There's already been a big meetup at LPC earlier on this month, and we're resolving to do more regular sessions in the future. If there's anything we can help with, please shout!
Right now we're trying to bootstrap some base packages with hardfp still. If you like, you can see the current progress on: https://build.opensuse.org/project/monitor?project=Base:build:arm I'm pretty sure that we could use quite some help once we get the base system up and running and want to move on to activate the full system. For now, there is only so much work that can be parallelized unfortunately. Alex
[ dropping CCs to other lists ] On Tue, Sep 27, 2011 at 06:06:32PM +0200, Alexander Graf wrote:
On 27.09.2011, at 16:30, Steve McIntyre wrote:
</lurk>
Hi!
If you'd like to join in some cross-distribution discussion about ARM porting etc., please sign up to the cross-distro mailing list hosted by Linaro:
http://lists.linaro.org/mailman/listinfo/cross-distro
Ah, cool. That might be very interesting, yes. Andrew, please join there too :).
There's already been a big meetup at LPC earlier on this month, and we're resolving to do more regular sessions in the future. If there's anything we can help with, please shout!
Right now we're trying to bootstrap some base packages with hardfp still. If you like, you can see the current progress on:
https://build.opensuse.org/project/monitor?project=Base:build:arm
OBS is nice for this kind of display... :-) Out of curiosity, what are you using as a triplet for your hard-float port? The discussion at LPC focussed on this to some extent: http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
I'm pretty sure that we could use quite some help once we get the base system up and running and want to move on to activate the full system. For now, there is only so much work that can be parallelized unfortunately.
Yup, understood. 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 For additional commands, e-mail: opensuse-arm+help@opensuse.org
On 27.09.2011, at 18:19, Steve McIntyre wrote:
[ dropping CCs to other lists ]
On Tue, Sep 27, 2011 at 06:06:32PM +0200, Alexander Graf wrote:
On 27.09.2011, at 16:30, Steve McIntyre wrote:
</lurk>
Hi!
If you'd like to join in some cross-distribution discussion about ARM porting etc., please sign up to the cross-distro mailing list hosted by Linaro:
http://lists.linaro.org/mailman/listinfo/cross-distro
Ah, cool. That might be very interesting, yes. Andrew, please join there too :).
There's already been a big meetup at LPC earlier on this month, and we're resolving to do more regular sessions in the future. If there's anything we can help with, please shout!
Right now we're trying to bootstrap some base packages with hardfp still. If you like, you can see the current progress on:
https://build.opensuse.org/project/monitor?project=Base:build:arm
OBS is nice for this kind of display... :-)
Out of curiosity, what are you using as a triplet for your hard-float port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where the discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego. Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb. Target-wise, we're currently targeting arm-suse-linux-gnueabi. I assume we need to switch to gnueabihf then? Is that target already available in recent toolchains? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your hard-float port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where the discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb.
That's close enough to what others are doing, yeah.
Target-wise, we're currently targeting arm-suse-linux-gnueabi. I assume we need to switch to gnueabihf then? Is that target already available in recent toolchains?
gnueabihf is the best place to aim, yes. Most of what you need is in place already in the toolchains that people are using (Linaro toolchain in Ubuntu, upstream-ish gcc in Debian), *except* the change to move ld.so into /lib/<triplet>/. That's not *critical* yet, but you'll need to rebuild things to pick up that change once it happens. You'll be able to cope with it by using compatibility sym-links, unless you want to support multi-arch... 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 For additional commands, e-mail: opensuse-arm+help@opensuse.org
On 28.09.2011, at 12:50, Steve McIntyre wrote:
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your hard-float port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where the discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code. So we can either build our packages against armv7hl, breaking the assumption that we can find the machine type from uname (basically adding a hack that armv7hl is compatible to armv7l). Or we could build our packages against armv7l which is what the kernel emits (good!), but would diverge from how Fedora and Meego call their packages. We're currently not sure which path would be the better one to walk down on. What's the rationale from the other distro folks here? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Sep 30, 2011, at 8:11 AM, Alexander Graf wrote:
On 28.09.2011, at 12:50, Steve McIntyre wrote:
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your hard-float port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where the discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
Bzzzt! rpm hasn't usesd uname(2) solely to determine arch for all of this century.
So we can either build our packages against armv7hl, breaking the assumption that we can find the machine type from uname (basically adding a hack that armv7hl is compatible to armv7l).
Or we could build our packages against armv7l which is what the kernel emits (good!), but would diverge from how Fedora and Meego call their packages.
We're currently not sure which path would be the better one to walk down on. What's the rationale from the other distro folks here?
I propose -- in order to move this discussion forward faster than distro consensus -- that other body parts be used as as signifiers for CPU capabilities on ARM. Specifically leg = Little Endian GNU hip = Hardly Intensive Prothesis The avoidance of any common letters of the alphabet will speed up arch identifictaion without the necessity of hand crufted assembly for strlen(3): any letter can be randommly chosen in any order to compare from each set of identifier strings and compared with exactly the same result as comparing the ful string. hth 73 de Jeff-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Fri, 2011-09-30 at 14:11 +0200, Alexander Graf wrote:
On 28.09.2011, at 12:50, Steve McIntyre wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your
hard-float
port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote: the
discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
Any host with an armv7l kernel is *capable* of running armv7hl code (in v7 [A profile], vfp hardware must be present). Since kernel doesn't dictate the userspace API standard, it's impossible to select hardfp/softfp based on uname -- the kernel will work with either. In fact, we can and do mix the APIs on one system (by fiddling the LD paths and/or using chroot to prevent cross-API linking). The real question is "what is the API variant of the binaries and libraries installed on the host?", which cannot be answered by querying the CPU or the kernel. -Chris -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
Am 30.09.2011 um 20:27 schrieb Chris Tyler <chris@tylers.info>:
On Fri, 2011-09-30 at 14:11 +0200, Alexander Graf wrote:
On 28.09.2011, at 12:50, Steve McIntyre wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your
hard-float
port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote: the
discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
Any host with an armv7l kernel is *capable* of running armv7hl code (in v7 [A profile], vfp hardware must be present). Since kernel doesn't dictate the userspace API standard, it's impossible to select hardfp/softfp based on uname -- the kernel will work with either. In fact, we can and do mix the APIs on one system (by fiddling the LD paths and/or using chroot to prevent cross-API linking).
The real question is "what is the API variant of the binaries and libraries installed on the host?", which cannot be answered by querying the CPU or the kernel.
So declaring armv7hl as compatible to any armv7l host system seems like the way to go then :) Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
On Fri, 2011-09-30 at 14:27 -0400, Chris Tyler wrote:
On Fri, 2011-09-30 at 14:11 +0200, Alexander Graf wrote:
On 28.09.2011, at 12:50, Steve McIntyre wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your
hard-float
port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote: the
discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
Any host with an armv7l kernel is *capable* of running armv7hl code (in v7 [A profile], vfp hardware must be present). Since kernel doesn't dictate the userspace API standard, it's impossible to select hardfp/softfp based on uname -- the kernel will work with either. In fact, we can and do mix the APIs on one system (by fiddling the LD paths and/or using chroot to prevent cross-API linking).
The real question is "what is the API variant of the binaries and libraries installed on the host?", which cannot be answered by querying the CPU or the kernel.
btw, I'd like to add a +1 to Chris' summary here. I would *love* to work with the OpenSuSE folks to standardize as much as we can. Jon. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
2011/9/30 Chris Tyler <chris@tylers.info>:
On Fri, 2011-09-30 at 14:11 +0200, Alexander Graf wrote:
On 28.09.2011, at 12:50, Steve McIntyre wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your
hard-float
port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote: the
discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits
The "softfp" abi has the misfortune of making it easy to think it does not use vfp registers, maybe the same way people will confuse "arm9" and "arm11". Nevertheless, currently I am working on a Mandriva port using the softfp abi. Reason of choosing it is because softfp abi allow running unmodified armv5 or older binaries (there may be special cases), and for example it is what you will have if you donwload the "sample" linux images from http://www.arm.com/community/software-enablement/linux.php?tab=Linux+OS+Down... upack it and objdump contents of binaries and libraries, you will notice it uses softfp. Same for most existing pre built toolchains like codesourcery. Aside that, if it were not the fact that gcc is smarth enough to take short circuits avoiding fpr -> gpr|mem -> fpr in calls to "non exported functions", I would prefer to use the --with-float=hard abi. But pathological worst case forcing it to pass arguments in gpr and memory, of a function receiving 8 doubles and returning one shows sub 20% slower in my tests. I did bootstrap Mandriva in all combinations of --with-fpu=vfpv3-v16 or --with-fpu=neon, -with-float=softfp or --with-float=hard, and --with-mode=thumb or --with-mode=arm. My choice ended up being: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: ./configure --build=armv7l-mandriva-linux-gnueabi --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --x-includes=/usr/include --x-libraries=/usr/lib --disable-libjava-multilib --with-java-home=/usr/lib/jvm/java-rpmbuild --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-java-awt=gtk --enable-gtk-cairo --with-cloog --with-ppl --enable-cloog-backend=ppl --disable-libquadmath --disable-libquadmath-support --disable-libssp --disable-libunwind-exceptions --disable-werror --enable-__cxa_atexit --enable-bootstrap --enable-checking=release --enable-gnu-unique-object --enable-languages=c,c++,fortran,java,lto --enable-linker-build-id --enable-plugin --enable-shared --enable-threads=posix --with-system-zlib --with-bugurl=https://qa.mandriva.com/ --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-mode=thumb --with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi Thread model: posix gcc version 4.6.1 20110916 (Mandriva) (GCC) I know I already did make my points before, but I still need to explain this from time to time for people that know more what is going on in the packages I already had built, and, well, out of some silence I made some decisions and started packaging and have built a "stage3" with almost all possible build requires...
armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
Any host with an armv7l kernel is *capable* of running armv7hl code (in v7 [A profile], vfp hardware must be present). Since kernel doesn't dictate the userspace API standard, it's impossible to select hardfp/softfp based on uname -- the kernel will work with either. In fact, we can and do mix the APIs on one system (by fiddling the LD paths and/or using chroot to prevent cross-API linking).
I did take advantage of that by using chroots for the different abi setups, and currently I am working on a fedora chroot, but sans a Mandriva kernel (I cannot help much as so far I have been working remotely), it can run a distro already.
The real question is "what is the API variant of the binaries and libraries installed on the host?", which cannot be answered by querying the CPU or the kernel.
-Chris
Paulo -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org
participants (17)
-
Alexander Graf -
Andrew Wafaa -
Chris Tyler -
Greg Freemyer -
Greg KH -
Guillaume Gardet -
Jan-Simon Möller -
Jeff Johnson -
Jon Masters -
Joop Boonen -
Joop Boonen -
KaiRo - Robert Kaiser -
Markus Slopianka -
Paulo César Pereira de Andrade -
Pavol Rusnak -
Peter Czanik -
Steve McIntyre