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

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 won’t 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 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

On Thu, September 22, 2011 5:22 pm, Alexander Graf wrote:

Am 22.09.2011 um 17:13 schrieb Pavol Rusnak :

...

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

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

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

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

Am 30.09.2011 um 20:27 schrieb Chris Tyler :

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

2011/9/30 Chris Tyler :

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