Mailinglist Archive: opensuse-features (82 mails)

< Previous Next >
[openFATE 310070] openSUSE support for ARM
Feature changed by: Lukas Krejza (gryffus)
Feature #310070, revision 56
Title: openSUSE support for ARM

Hackweek VII: Evaluation by engineering manager
Priority
Requester: Desirable

openSUSE-11.4: Rejected by Gerald Pfeifer (geraldpfeifer)
reject date: 2011-03-26 02:45:20
reject reason: Not done for 11.4.
Priority
Requester: Mandatory

openSUSE Distribution: Evaluation by engineering manager
Priority
Requester: Desirable

Requested by: peter czanik (czanik)
Developer: andrea florio (anubisg1)
Partner organization: openSUSE.org

Description:
As indicated by this [1] thread, and many earlier, there is demand for
openSUSE ARM support. As discussed on the mailing list:
- the build infrastructure is already there
- there is a number of cheap and easily available existing ARM based
devices (EFIKA MX [2], Sheeva Plug [3], Beagle Board [4], etc.) and
many more are expected to arrive in the coming months
- we need developers
This last point is the most important, as creating an ARM port is more
than just enabling ARM in the build service. Without enough developers
this port can't be started, as there is a lot of work to do:
- sometimes it is enough just to fix packaging errors (where only x86
is considered in the spec file)
- often compiling on ARM needs some patching (either to find existing
patches from other distributions or develop new ones)
- the openSUSE (YaST, etc.) tools need to be made aware of ARM
- testing on different target machines
Please add your comment, if you are interested in the ARM port and also
that how you could help this initiative!
1.
http://lists.opensuse.org/opensuse-buildservice/2010-06/msg00293.html
2. http://www.genesi-usa.com/products/efika
3.
http://www.globalscaletechnologies.com/p-22-sheevaplug-dev-kit-us.aspx
4. http://beagleboard.org/

Discussion:
#1: andrea florio (anubisg1) (2010-07-01 15:20:02)
please consider me in!
i am probably not yet a "developer" in the strict meaning of the word,
but i guess i can really help that project.

#2: Andreas Jaeger (a_jaeger) (2010-07-01 15:57:11)
Let's move the feature to the next release and not do it for 11.3.

#3: Robert Schweikert (rjschwei) (2010-07-01 16:38:14)
I will help fix packages.

#4: Cristian Rodríguez (elvigia) (2010-07-01 19:06:48)
Im also interested on this port however, afaics the problem is:
1)access to real hardware that has enough resources to actually build
the complete distro natively.
I can actually pucharse one of those little things, but It wont be much
useful for building packages, as it has too liltte RAM. any other
alternatives available that does not require using cross-compilers ?

#5: (sboyce) (2010-07-01 20:50:08)
I have a Beagleboard and hope to get the Beagleboard XM when it is
available, so I can help with testing.
I would hope for a more straightforward approach than is currently
available with Angstrom, Ubuntu or Fedora for ARM.

#6: Jan-Simon Möller (dl9pf) (2010-07-02 14:46:58)
@Christian: We don't need real hardware - we've emulation and cross-
compilers in place.
I can take care of these 2 and become mentor as i did the 11.2@arm
during my GSoC.
IMHO we need 1-2 ppl acting as coordinators/distro-
maintainers/dispatchers - this doesn't involve that much coding - but
should prevent packagers from getting swamped or stuck in a problem.
Being the voice/contact/hub.
Packagers/Package maintainers, of course. For most issues there's a
patch - we just have to look around. And for the other 5% we can always
ping our specialists. Its cool as you always see what you have
achieved.
I could imagine to care for the qemu/gcc/cross-compilers/base:build
(the "core") - how much time is left to co-maintain the rest i can't
tell.


#7: Jan Engelhardt (jengelh) (2010-07-11 20:12:08) (reply to #6)
Been there, done that. I can tell stories of SPARC. Emulation is slow
-- if it exists at all. Cross-compilers are tiresome and don't help
beyond bootstrap, when ./configure depends on running some target code.
Real hardware is the deal to get things done in a timely manner, as
even a single machine takes time to build factory.

#8: Greg Freemyer (gregfreemyer) (2010-07-11 20:24:08) (reply to #7)
Jan,
Have you read
http://lizards.opensuse.org/2009/06/16/opensusearmgsoc-cross-compilation-speedup/
Makes the performance side of cross compiles appear solved for ARM in OBS.
ie. Acheiving 50% of i586 compile speeds.  Not perfect, but better than
a ARM can likely do natively.


#9: Cristian Rodríguez (elvigia) (2010-07-11 21:18:11) (reply to #7)
that exactly my point, even more, getting the distro compiled is one
thing, but getting it _properly_ compiled is a different story, not to
mention we need hardware to test the actual binaries.
Other than that, cross-compilers may require significant black magic in
case stuff goes wrong.


#10: peter czanik (czanik) (2010-07-13 09:57:15)
Well, cross compilation should not be a problem. MeeGo is completely
built by an OBS instance. And Linaro ( http://www.linaro.org/ ) is also
cross compiled.
Testing: I have an EFIKA MX and a Sheeva Plug, two completely different
ARM based machines, others mentioned Beagle Board, so all three
machines from my original post are covered

#11: Cristian Rodríguez (elvigia) (2010-08-12 20:30:07)
meego is not the full distro, and Im yet to find any decent hardware
(best one seems to the the openRD-
client  http://www.globalscaletechnologies.com/t-openrdcdetails.aspx
(http://www.globalscaletechnologies.com/t-openrdcdetails.aspx)

Dell, IBM and other vendors have said that they will ship ARM servers
2010/2011, but that's vapourware at the moment.


#12: Cristian Rodríguez (elvigia) (2010-09-09 20:35:43)
ARM has announced "Eagle" quad core 2.5ghz and up to 1 TB memory
hardware, so the posibility of getting real hardware to build the whole
distrubution is  bit more realistic. 

#13: 6tr6tr 6tr6tr (6tr6tr) (2010-10-01 20:19:44)
I'd think touchscreen support should go along with this actually.

#15: Stefan Quandt (squan) (2010-11-16 09:18:12) (reply to #13)
I think we will see a lot of attractive (ARM based) tablet devices next
year.
So I really would like to see such devices running openSUSE. Or may be
smeego.
Or better both.  And yes, this essentially would require touchscreen
support.
I'm a bit surprised that  suppport for such devices was not one of the
results of the openSUSE strategy meetings.


#16: Jedi Beeftrix (jedibeeftrix) (2010-11-18 14:14:46) (reply to #15)
"And yes, this essentially would require touchscreen support"
Agreed, in which case this openfate request for multi-touch X-input
patches becomes V important:
https://features.opensuse.org/310758

#14: Sid Boyce (sboyce) (2010-10-08 23:22:45)
I have a BeagleBoard C3. Ruinning the Angstrom distribution makes it
difficult to build from sources. With Ubuntu I have a problem with
recording audio. A openSUSE port would be most welcomed.
I tried Kubuntu, but KDE takes an age to boot, so now I boot with Gnome
but have access to KDE apps.
I can help with testing.

#17: Joseph Mitzen (duncreg) (2011-08-06 22:01:06)
Windows 8 is going to be able to run on ARM, there are swirling rumors
(especially as iOS and OSX begin to converge) that some of Apple's
laptop models will switch to ARM processors, the vast majority of
tablets and virtually all handheld devices are running ARM... if
openSUSE doesn't get an ARM port soon, its chances of taking over the
world are going to be vastly diminished. :-(

#18: Jan Engelhardt (jengelh) (2011-08-06 22:25:00) (reply to #17)
Don't ask what openSUSE can do for you, ask what you can do for
openSUSE.

#19: Philippe Baril Lecavalier (p_barill) (2012-07-30 03:21:25)
I was wondering what's the point of having a Ubuntu port to ARM. But I
recently saw an exciting demonstration on a tablet, with somehow Debian
running on Android natively--neither dual-boot nor virtual machine!
Clearly, there is a need for an ARM build of opensuse.

+ #20: Lukas Krejza (gryffus) (2013-01-02 16:15:37)
+ http://en.opensuse.org/Portal:ARM Should this be marked as done?




--
openSUSE Feature:
https://features.opensuse.org/310070

< Previous Next >
This Thread
  • No further messages