- openSUSE ARM

Re: [opensuse-arm] efika questions
by Joop Boonen 14 Nov '11

14 Nov '11

On Mon, November 14, 2011 10:09 am, Andrew Wafaa wrote: > On Mon, 2011-11-14 at 09:14 +0100, Joop Boonen wrote: >> I didn't get to this was working on the kernel. Hopefully I can fix this issues with this one soon. I have an usb issue, that I need to fix. ( home:worldcitizen:armv7l kernel-omap4panda ) >> > > I've submitted a patch to the kernel team that builds the following >kernels for 3.1: omap2plus, imx51 and tegra. Let me know if you need >anything from that to help with u-boot etc. u-boot and x-boot are not dependent on the kernel as far as I know. Does this patch give a prompt in the tty's? I've build the terminal according to http://elinux.org/PandaBoard this didn't give a prompt in the tty. For me the only working kernel is the one according to: http://wiki.meego.com/ARM/OMAP4_Panda#kernel > >> After that I'll start working on kiwi. >> >> > >> >> > Hopefully >> >> > the current build will succeed. >> >> > >> >> > If someone wants to help, could someone package u-boot (the arm >> boot >> >> > loader) ? >> >> > I suppose it will be a pre-requirement for the kiwi support. >> >> >> >> U-boot has been build for the pandaboard. I used the meego version as >> a >> >> base. It still needs a bit of tuning. >> >> The package can be found here: home:worldcitizen:armv7l >> >> u-boot-omap4panda >> > >> > please look for a devel project and submit to factory. >> > >> I've submitted both x-loader-omap4panda and u-boot-omap4panda to Base:System . (request id 91227 and request id 91228) >> I've tested both of them on my PandaBoard. >> > > Would it be possible to re-name the packages to fall in line with the kernels being built? For OMAP it is omap2plus, as per the config. This should support all omap2plus devices, including the Beagle and Panda. That's OK. I can rename it. I won't be able to test it on a BeagleBoard. > > Regards, > > Andy > > -- > Andrew Wafaa > IRC: FunkyPenguin > GPG: 0x3A36312F > > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 1

[opensuse-arm] efika questions
by Peter Czanik 14 Nov '11

14 Nov '11

Hello, I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AARM ). As I have an EFIKA MX and helped to get some EFIKAs for developers, my questions relate to it: - what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...) - how are the EFIKAs used? - I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha/ Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA? I'll be an FSF Hungary conference this weekend, and would be nice to demo my smartbook with openSUSE running native :) Bye, CzP -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

9 22

[opensuse-arm] current definitive build success on real arm hw
by Alexander Graf 11 Nov '11

11 Nov '11

Hi guys, We have a few EFIKA boxes sitting on a disk at SUSE building Factory in parallel to the emulated builds. So we have a list of "known goods" that can be compared to "known failures" with QEMU builds to find QEMU breakages. Alex List of known goods: 844-ksc-pcf CID-keyed-fonts-MOE DirectFB ElectricFence FastCGI GeoIP IPAPGothic ImageMagick JTOpen KhmerOS-fonts LinuxLibertine Mesa Modules MyODBC-unixODBC NetworkManager PTSans-fonts PTSerif-fonts PgTcl PolicyKit PyGreSQL SDL SDL_net Supybot VFlib3 WindowMaker WindowMaker-themes a2ps-h a2ps-perl-ja aaa_base aalib abcde abook accountsservice acct acl adaptec-firmware adns adolc aide alpine alsa alsa-firmware alsa-oss apache2 apparmor-admin_en archivemail arptables asciidoc asclock asio aspell aspell-dictionaries aspell-en astyle asusfan at at-spi atftp atheme atk atkmm atmel-firmware attr aubio audiofile audit audit-visualize augeas autoconf-archive autoconf213 autocutsel autogen avahi avrdude awesfx b43-fwcutter babl bakefile bash bash-completion batctl bb bc bdfresize bff bff4 biabam bibview bing bison bitstream-vera bleachbit blocxx blueprint-cursor-theme blueproximity bluez bluez-firmware bogofilter bonnie bonnie++ books boost boost-jam bootp-DD2 bootsplash-branding-upstream bpg-fonts bpython branding-upstream bridge-utils brlemu brp-check-suse bsd-games bsdtar btrfsprogs buffer build build-compare build-mkbaselibs-sle busybox bwidget byacc byaccj bzip2 bzr cabextract cachefilesd cairo cairomm calamaris calcurse canna canna-yubin cannadic cantarell-fonts ccache ccaudio2 ccgfs ccscript3 cdecl cdk cdparanoia cecilia cedict celt cgdb chasen check check-create-certificate checkbashisms checkinstall checkmedia checkpolicy chkrootkit chmlib chrpath cim-schema cint clamz cloog clucene-core clutter-gtk cm-unicode cmake cmpi-provider-register cntlm collectl color-filesystem colorblind colordiff commoncpp2 compartm compat-openssl097g compat-readline4 compcache compface compiz-manager conntrack-tools convert convmv cook corosync courier-authlib cpio cpupower cpuset cracklib cracklib-dict-full createrepo cronie cryptsetup cscope csindex csync2 ctags ctdb ctemplate culmus cups cups-backends curl cvs cvs2svn cyrus-sasl dante dar darts dash dbench dbh dbsplit-tools dbus-1 dbus-1-glib dbus-1-python dbus-1-x11 dbview dcraw dd_rescue ddclient dds2tar decibel-audio-player dejagnu dejavu delayacct-utils delta deltafs deltarpm desktop-file-utils device-mapper dhcp dhcp-tools dhcpcd diald dialog dicts diffmk diffstat diffutils ding ding-libs dirdiff dirmngr dita djvulibre dmapi dmz-icon-theme-cursors dnsmasq doc-gnu-ko docbook-css-stylesheets docbook-dsssl-stylesheets docbook-simple docbook-tdg docbook-toys docbook-utils docbook-xml-slides docbook-xml-website docbook-xsl-stylesheets docbook5-xsl-stylesheets docbook_3 docbook_4 docbook_5 dos2unix dosfstools dosutils dotconf doxygen dpic drac droid-fonts dssi dtc dummy-release dump duplicity duply dvbsnoop dvd+rw-tools dynamic-wallpapers-11x e2fsprogs e3 eb eblook ebook-tools ebtables eciadsl-usermode ed edict efont-serif-ttf efont-unicode eject elftoaout elfutils emil enca encfs enchant engdic engine_pkcs11 enscript epic epydoc esound ethtool evoldap2-client exempi exif exiftool exim exiv2 exmh expat expect ez-ipupdate f2c facter fail2ban farsifonts fastjar fbset fdupes festival fetchmsttfonts ffado fftw3 fhs fifth-leg-font figlet file filesystem fillets-ng-data fillup findutils finger firescope flac flex-old fltk fluidsynth fondu fontconfig fontforge fonts-thryomanes fortune fping free-ttf-fonts freefont freeglut freeradius-client freetds freetype freetype2 fribidi frink fsarchiver ft2demos ftgl ftp fuse fuseiso fvwm2 fwzs fxload gaa gawk gc gcc gcc46 gconf2 gconfmm gd gdb gdbm gdk-pixbuf gdm gdome2 genromfs gentium getmail ghostscript-cjk ghostscript-library ghostscript-mini giflib gle glew glib-networking glib2 glibmm2 global glusterfs gmetadom gnokii gnome-audio gnome-backgrounds gnome-colors-icon-theme gnome-common gnome-devel-docs gnome-doc-utils gnome-games-extra-data gnome-menus-branding-openSUSE gnome-patch-translation gnome-video-effects gnuchess gnump3d gnutls gobject-introspection gonvert goocanvas1 gos-wallpapers gourmet gperf gpg2 gpgme gpm gpsbabel gramofile graphviz grep groff gsettings-desktop-schemas gsl gssdp gstreamer-0_10 gtk-doc gtk-key-theme-ctrluftw gtk2 gtk2-engines gtk2-themes gtk3 gtk3-metatheme-sonar gtkmm2 gtksourceview18 gtkspell guile gup gupnp gupnp-igd gzip hackbench handedict hanterm-xf haserl hcode hello hercules hg-fast-export hicolor-icon-theme hicolor-icon-theme-branding-openSUSE himeno hmconv hostap-utils hostapd html-dtd htop hunspell hwinfo i2c-tools ibmasm ibmrtpkgs icc-profiles-basiccolor-printing2009 icc-profiles-openicc iceWMCP icecream icewm-lite icewm-themes icu id3lib igerman98 imap imgvtopgm imlib2 indent indic-fonts insserv inst-source-utils intltool iotop ipmitool ipsec-tools iptraf ipvsadm ipw-firmware ipxrip irda irqbalance isight-firmware-tools isns iso-codes iso_ent ispell ispell-bulgarian ispell-hungarian ispell-slovak itcl itstool iw iwatch iwidgets iwl6000-ucode iwl6050-ucode jack jakarta-commons-parent jasper java-binfmt-misc jfbterm jhbuild jhead jing jlfgr john john-wordlists jpackage-utils jpeg8 json-c jtools kakasi kbd kbuild kde4-filesystem kdebase4-session kdedesktopcheck kernel-coverage kernel-source kernel-syms ketchup keyutils killerd kinput2 kio_sysinfo-branding-upstream kiwi-instsource-plugins-openSUSE-11-2 kiwi-instsource-plugins-openSUSE-11-3 kiwi-instsource-plugins-openSUSE-12-1 konkretcmpi krb5 krb5-appl krb5-mini kye ladspa ladspa-devel lash lbdb lcms lcms2 lcov ldapcpplib ldapfuse ldtp lessons4lizards_en libHBAAPI2 libHX libXi6 libaal-1_0-5 libaio libapr-util1 libapr1 libart_lgpl libassuan libavc1394 libbeecrypt6 libbonobo libcanberra libcap libcap-ng libcap1 libcares2 libcddb libcddb-utils libcdio libcdio-mini libcfitsio0 libconfuse0 libcppunit-1_12-0 libcpuset libcryptopp libdaemon libdatrie libdb-4_5 libdb-4_8 libdbi libdiscid libdrm libdvdread libdwarf libebml libedit libeigen2-devel libelf0 libesmtp libetpan libevent libevtlog libexif libexif-gtk libexpat0 libfallocate libfli libgadu libgcal libgcrypt libgee libglade2 libgme libgmm++-devel libgnome-keyring libgnomecanvas libgpg-error libgphoto2 libgsasl libgsm libgssglue libhangul libica-1_3_9 libical libid3tag libidl libidn libiec61883 libieee1284 libimobiledevice libindi libiniparser libiptcdata libjpeg-turbo libkate libksba liblinebreak liblo liblouis liblqr liblrdf libltdl3 libmcrypt libmemcached libmicro-devel libmikmod libmm14 libmng libmnl libmodman libmodplug libmowgli libmpcdec libmpd libmsn libmspack libmtp libmusicbrainz libnet libnetfilter_conntrack libnettle libnfnetlink libnih libnl-1_1 libnl3 libnotify libnova libnscd liboauth libofa libofx libogg liboggz liboop libopenssl0_9_8 libopensync liboping libotf libotr libp11 libpcap libpciaccess0 libpgeasy libplist libpng12 libpng14 libpqxx libproxy libqca2 libqimageblitz4 libqjson libqt4 libraw libraw1394 librcc0 librcd0 libreadline5 libreiserfs libreoffice-converter libreoffice-hyphen libreoffice-templates-de libreoffice-templates-en libreoffice-templat...esentation-layouts libreoffice-thesaurus librpcsecgss librsync libsamplerate libsatsolver libsecprog libselinux libsemanage libsepol libsidplay1 libsigc++12 libsigc++2 libsmi libsndfile libsoup libspectre libssh libssh2_org libstatgrab libstroke libtasn1 libthai libtirpc libtool libtorrent-rasterbar libunistring libunwind liburiparser1 libusb-1_0 libusb-compat libustr libvisual libvorbis libvpd2 libvpx libwebp libwmf libwpd libwpg libwps libxcrypt libxfce4util libxml++ libxml2 libxml2-python libxslt libxslt-python libyajl libzeitgeist libzio libzip limal-devtools link-grammar linkloop linux-atm linux-glibc-devel lirc littlewizard-examples lklug lksctp-tools lmfonts lobster-cyrillic-fonts lockdev logdigest login logrotate logwatch lpsolve lsb lsb-release lsyncd lua lua50 lxde-common-branding-openSUSE lzo m17n-db m17n-lib m4 mailx make malaga meld memcached mhash mobile-broadband-provider-info module-init-tools mozilla-nspr mozilla-nss mpc mpfr mpi-selector mtx mxml mysql-connector-cpp nano nasm ncurses neon net-snmp net6 netcdf netcontrol netpbm nfsidmap nss-mdns nss-shared-helper ntfs-3g_ntfsprogs open-iscsi openCryptoki openais openal-soft openbabel openclipart openjade openldap2 openldap2-client openmotif openobex openslp opensp openssh openssl opie p11-kit pam pam-config pango pangomm patch patterns pciutils pciutils-ids pcre pcsc-lite perl perl-Algorithm-C3 perl-Algorithm-Diff perl-AnyEvent perl-AppConfig perl-Archive-Zip perl-BSD-Resource perl-Bootloader perl-Business-ISBN-Data perl-CGI-FastTemplate perl-CPAN-DistnameInfo perl-Carp-Assert perl-Class-C3-XS perl-Class-Data-Inheritable perl-Class-Factory-Util perl-Class-Inspector perl-Class-Multimethods perl-Class-Singleton perl-Clone perl-Config-General perl-Convert-ASN1 perl-Crypt-CBC perl-Crypt-OpenSSL-Random perl-Crypt-Rijndael perl-Crypt-SmbHash perl-DBI perl-Devel-Cycle perl-Devel-StackTrace perl-Digest-SHA1 perl-Email-Address perl-Email-Date-Format perl-Encode-Locale perl-Error perl-Exporter-Tidy perl-ExtUtils-Depends perl-ExtUtils-F77 perl-ExtUtils-PkgConfig perl-File-MMagic perl-File-Next perl-File-Remove perl-File-Slurp perl-FileHandle-Unget perl-Font-AFM perl-GD perl-GDTextUtil perl-Glib perl-HTML-Tagset perl-HTML-Template perl-HTTP-Date perl-Hook-LexWrap perl-IO-Socket-INET6 perl-IO-Socket-SSL perl-IO-String perl-IO-Stty perl-IO-stringy perl-IPC-Run perl-IPC-Run3 perl-Iterator perl-LWP-MediaTypes perl-List-MoreUtils perl-MIME-Charset perl-MIME-Types perl-MLDBM perl-Mail-Mbox-MessageParser perl-MailTools perl-Math-Round perl-Module-Refresh perl-Net-Daemon perl-Net-HTTP perl-Net-IP perl-Net-SSLeay perl-Net-Server perl-NetAddr-IP perl-NetxAP perl-Number-Compare perl-PadWalker perl-Params-Util perl-Params-Validate perl-Parse-RecDescent perl-PerlIO-via-dynamic perl-Pod-POM perl-Pod-Spell perl-Probe-Perl perl-Readonly perl-Regexp-Common perl-SGMLS perl-Sub-Identify perl-Sub-Name perl-Sub-Uplevel perl-Switch perl-Sys-Hostname-Long perl-Task-Weaken perl-Term-ReadKey perl-Test-LeakTrace perl-Test-Manifest perl-Test-Number-Delta perl-Test-Object perl-Test-Pod perl-Test-Requires perl-Test-Tester perl-Text-Diff perl-Text-Glob perl-Text-Iconv perl-Text-Reform perl-Text-Template perl-Tie-Cache perl-Tie-IxHash perl-TimeDate perl-Tree-DAG_Node perl-Try-Tiny perl-URI perl-Variable-Magic perl-X500-DN perl-XML-Parser perl-XML-RegExp perl-XML-SAX-Base perl-XML-Simple perl-XML-Writer perl-XML-XPath perl-YAML perl-YAML-Syck perl-common-sense perl-gettext perl-libintl-perl perl-libxml-perl php5-pear-Auth_SASL php5-pear-Date php5-pear-File php5-pear-Log php5-pear-Mail php5-pear-Mail_Mime php5-pear-SOAP php5-pear-Services_Weather php5-pear-Text_Figlet php5-pear-XML_SVG php5-pear-channel-horde php5-pear-channel-phpunit physfs pilot-link pixman pkcs11-helper pkg-config plotutils pm-utils podofo polkit polkit-default-privs popt portaudio postfix postgresql-libs pothana2000 powerman ppl ppp procmail procps psmisc psutils pth pulseaudio pwdutils pyrex python python-Babel python-Cython python-Jinja2 python-Louie python-M2Crypto python-MarkupSafe python-MiniMock python-Pygments python-Sphinx python-argparse python-base python-cairo python-cheetah python-configobj python-cssutils python-dateutil python-distribute python-distutils-extra python-django python-docutils python-gobject2 python-gtk python-httplib2 python-lxml python-mutagen python-nose python-numpy python-odfpy python-optcomplete python-pyOpenSSL python-pycurl python-pypdf python-pyserial python-python-openid python-pywbem python-rdflib python-simplejson python-sip python-tz python-unittest2 python-urlgrabber python-versiontools python-xdg python-xlib python-yaml python-zope.interface python3 qhull qscintilla qt3 qt3-extensions qt4-assistant-adp radiotray radvd raptor rasqal re2c recode redland rlog rpcbind rpm rpm-python rpmlint rpmlint-mini rrdtool rsh ruby rubygem-activerecord rubygem-gettext rubygem-locale rubygem-mocha rubygem-rack-1_1 rubygem-rails rubygem-rake rubygem-restility rubygem-test-unit rubygem-webyast-rake-tasks rubygems sablot samba sblim-cmpi-devel sblim-indication_helper sblim-sfcb sblim-sfcc sblim-testsuite sblim-wbemcli scons scrollkeeper sed sendmail sensors sfftobmp sg3_utils sgml-skel sgmltool shared-desktop-ontologies shared-mime-info sharutils slang slib sofia-sip sound-theme-freedesktop soundtouch spandsp speex sqlite2 sqlite3 startup-notification sudo sword sysconfig sysfsutils syslogd systemd systemtap sysvinit t1lib t1utils tcl tcllib tcpd tcsh termcap tftp tidy tiff tinyxml tix tk tolua++ trang translation-update-upstream transmageddon trousers turpial uClibc udev unixODBC unoconv unsermake unzip update-alternatives update-desktop-files usbmuxd usbutils utempter util-linux uuid vacation vala valgrind vboxgtk vcdimager vigra vim vobject w3m wavpack wbxml2 wdiff wget wireless-regdb wireless-tools wodim wordcut wordnet words wvstreams xaw3d xbase xclass xdg-menu xdg-user-dirs xdg-utils xerces-c xfce4-dev-tools xfsprogs xhtml-dtd xinetd xkeyboard-config xli xmlcharent xmlto xorg-x11 xorg-x11-fonts xorg-x11-fonts-devel xorg-x11-libICE xorg-x11-libSM xorg-x11-libX11 xorg-x11-libXau xorg-x11-libXdmcp xorg-x11-libXext xorg-x11-libXfixes xorg-x11-libXmu xorg-x11-libXp xorg-x11-libXpm xorg-x11-libXprintUtil xorg-x11-libXrender xorg-x11-libXt xorg-x11-libXv xorg-x11-libfontenc xorg-x11-libs xorg-x11-libxcb xorg-x11-libxkbfile xorg-x11-proto-devel xorg-x11-server xorg-x11-util-devel xorg-x11-xtrans-devel xosd xz yasm yast2-all-packages yast2-branding-openSUSE yast2-core yast2-devtools yast2-libyui yast2-ncurses yast2-perl-bindings yast2-testsuite yast2-trans yast2-trans-allpacks yast2-trans-stats yast2-xml yast2-ycp-ui-bindings yelp-tools yelp-xsl zeitgeist zenity zeromq zip zlib zvbi zziplib -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] GMP build issue (make check) for armv7l
by Joop Boonen 07 Nov '11

07 Nov '11

Hi All, I'm busy checking out why make test fails for gmp. <quote> make check-TESTS make[4]: Entering directory `/usr/src/packages/BUILD/gmp-5.0.2/tests/cxx' terminate called after throwing an instance of 'std::invalid_argument' terminate called recursively qemu: uncaught target signal 6 (Aborted) - core dumped /bin/sh: line 5: 333 Aborted ${dir}$tst FAIL: t-assign PASS: t-binary PASS: t-cast terminate called after throwing an instance of 'std::invalid_argument' terminate called recursively qemu: uncaught target signal 6 (Aborted) - core dumped /bin/sh: line 5: 390 Aborted ${dir}$tst FAIL: t-constr PASS: t-headers PASS: t-istream PASS: t-locale PASS: t-misc PASS: t-ops PASS: t-ostream PASS: t-prec terminate called after throwing an instance of 'std::length_error' terminate called recursively qemu: uncaught target signal 6 (Aborted) - core dumped /bin/sh: line 5: 536 Aborted ${dir}$tst FAIL: t-rand PASS: t-ternary PASS: t-unary ==================================== 3 of 14 tests failed Please report to gmp-bugs(a)gmplib.org ==================================== </quote> What I see is the following. For some reason there seems to be an exception handling issue for openSuSE arm. If I look for instance in the t-assign.cc // operator=(const char *) with invalid { try { const char *a = "abc"; mpz_class b; b = a; ASSERT_ALWAYS (0); /* should not be reached */ } catch (invalid_argument) { } } All code is fine. An exception has correctly been generated. But for some reason the try/catch doesn't catch the exception. Even if I change the "} catch (invalid_argument) {" to "} catch (...) {" it doesn't. I saw such an exception also in zypper when I didn't do a refresh I also saw something like terminate called after throwing an instance of '*File*NotExist*' or something like that. So I don't think it's a gmp but an exception handling problem. I don't know yet where the exceptions are handled. By which package. I'm checking this out now. If someone knows please let me know. Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 3

[opensuse-arm] Got Xorg openSuSE armv7l running by means of xorg-x11-drv-omapfb
by Joop Boonen 01 Nov '11

01 Nov '11

Hi all, I've just got Xorg openSuSE armv7l running by means of xorg-x11-drv-omapfb. The package can be found in home:worldcitizen:armv7l I did a submit request to X11:XOrg #89848 . I've borrowed it from MeeGo. OpenSuSE arm7l looks already promising. zypper, network are all fine. A problem with udev exists. It might be that kernel 2.6.35 and the current udev 173 are not compatible. Because of the udev issue I don't have any keyboard and mouse when running WindowMaker. I will later add configuration files. I needed to disable the following files in: /etc/init.d/ boot.udev boot.rootfsck boot.dmraid As prevented the system to boot. I wonder when we'll have a hardfp openGL ES driver for the PandaBoard. Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] new qemu deployment in openSUSE:Factory:ARM and Base:build:arm
by Adrian Schröter 28 Oct '11

28 Oct '11

JFYI, we do use the qemu from openSUSE:Tools project in openSUSE:Factory:ARM via some aggregate&ExportFilter trick now. That means we don't need to deploy new worker images anymore for a qemu upgrade. The qemu version in openSUSE:Tools is currently not frozen, that means changes in Virtualization or openSUSE:Factory project will have direct effects. We can change this if needed. bye adrian PS: this is still considered a hack and not a clean solution, because it still requires identical architectures via the build hosts. A cleaner solution will be implemented later when working on worker capabilities. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] iproute2 package exists. :)
by Joop Boonen 28 Oct '11

28 Oct '11

Hi All, I see iproute2 has been build. I'm going to checkout how far I can get with JeOS, this weekend. A small remark. There is a unresolvable issue with iproute2 now. nothing provides perl = 5.14.1 needed by sgmltool If I check this out it looks like it;s not correct. OBS issue? https://build.opensuse.org/package/show?package=iproute2&project=openSUSE%3… https://build.opensuse.org/package/show?package=perl&project=openSUSE%3AFac… https://build.opensuse.org/package/show?package=sgmltool&project=openSUSE%3… Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

Re: [opensuse-ppc] Re: [opensuse-arm] [ml-admin] Merging the architecture lists to opensuse-arch
by Joop Boonen 27 Oct '11

27 Oct '11

On Thu, October 27, 2011 2:41 pm, Karl Eichwalder wrote: > Larry Stotler <larrystotler(a)gmail.com> writes: > >>> Meantime a merged list seems to me to be the wrong way to go: keep lists >>> that are active or might reasonably be expected to become so and kill the >>> others, effectively merging into -project and -factory. >> >> Is it really that big of a deal to leave it be and see what happens? Not really sure why it's so necessary to consider something dead when it may rise up again unexpectedly. > > Agreed. These arch lists are fine. Problematic are those general purpose lists such as -factory, -marketing, -project, etc. But as long as we do not create more of them, we can stand it. (I'm subscribe to -factory only, though.) When we are at it, is it an option to add opensuse-mips? > > -- > Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation MaxfeldstraÃe 5 > 90409 NÃ¼rnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix ImendÃ¶rffer, HRB 16746 (AG NÃ¼rnberg) > -- > To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org > > Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

Re: [opensuse-ppc] Re: [opensuse-arm] [ml-admin] Merging the architecture lists to opensuse-arch
by Joop Boonen 27 Oct '11

27 Oct '11

On Thu, October 27, 2011 2:41 pm, Karl Eichwalder wrote: > Larry Stotler <larrystotler(a)gmail.com> writes: > >>> Meantime a merged list seems to me to be the wrong way to go: keep >>> lists >>> that are active or might reasonably be expected to become so and kill >>> the >>> others, effectively merging into -project and -factory. >> >> Is it really that big of a deal to leave it be and see what happens? >> Not really sure why it's so necessary to consider something dead when >> it may rise up again unexpectedly. > > Agreed. These arch lists are fine. Problematic are those general > purpose lists such as -factory, -marketing, -project, etc. But as long > as we do not create more of them, we can stand it. (I'm subscribe to > -factory only, though.) When we are at it, is it an option to add opensuse-mips? > > -- > Karl Eichwalder SUSE LINUX Products GmbH > R&D / Documentation MaxfeldstraÃe 5 > 90409 NÃ¼rnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix ImendÃ¶rffer, HRB 16746 (AG > NÃ¼rnberg) > -- > To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org > > Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

Re: [opensuse-ppc] Re: [opensuse-arm] [ml-admin] Merging the architecture lists to opensuse-arch
by Joop Boonen 27 Oct '11

27 Oct '11

On Thu, October 27, 2011 9:44 am, Richard (MQ) wrote: > On 26/10/11 19:19, Joop Boonen wrote: >> On Wed, October 26, 2011 3:25 pm, Andreas Färber wrote: >>> Hi, >>> >>> Am 26.10.2011 15:04, schrieb Henne Vogelsang: >>>> On 26.10.2011 14:58, Adrian Schröter wrote: >>>>> Am Mittwoch, 26. Oktober 2011, 14:29:57 schrieb Henne Vogelsang: >>>>>> >>>>>> we are currently trying to reduce the amount of communication >>>>>> channels >>>>>> we provide. Because of this I would like to merge the 4 architecture >>>>>> lists into one list called opensuse-arch. >>>>>> >>>>>> If nobody objects until the 15th of November 12:00 UTC I will merge >>>>>> the >>>>>> lists. You don't have to do anything except rewriting your filter if >>>>>> you >>>>>> use one. >>>>> >>>>> I would definitive unsubscribe from such a list if the majority of >>>>> mails is >>>>> not interessting for me. >>>> >>>> The ppc, amd64 and ia64 lists didn't have any traffic in 2010 and >>>> 2011. >>>> I would like to have some point for people to go for non x86 >>>> architecture specific stuff. >>> >>> There was some recent activity to revive ppc openSUSE, so if arm stays >>> ppc should probably stay as well. >>> amd64 is mainstream now, so that's different I guess. >>> >> >> I agree. >> >> I think it's best to have separate mailing lists for different >> architectures. >> >> I think traffic wise it also safes bandwidth. Only people that are >> interested in a specific mailing list will get this mail and not >> traffic >> they don't want. >> >> The ppc mailing list will be very interesting again when the AmigaOne >> X1000 and Netbook will be released. >> http://en.wikipedia.org/wiki/AmigaOne_X1000 >> http://eab.abime.net/showthread.php?p=781936 >> If this ends up in an active mailing list where also ARM resides it's >> difficult to filter, I'm subscribed to both. > > If / when the AmigaOne X1000 arrives there will certainly be a new PPC > platform, but whether we can persuade the community to re-start the PPC > version of openSuSE Linux is another matter entirely. FWIW, the argument > for dropping it a few years back was that the usage had dwindled to > insignificant numbers (ISTR around 20 downloads / month) - I couldn't > really argue with that. > > My expectation is that there won't be another official PPC version at > all, though maybe we'll have enough momentum for an unofficial one - in > which case retention of this list will be vindicated. It all depends on > whether the machine is ever launched - time will tell. > > Meantime a merged list seems to me to be the wrong way to go: keep lists > that are active or might reasonably be expected to become so and kill > the others, effectively merging into -project and -factory. Why not be the distro that also invites people who want to try other distro's? If you look at other distro's they are more inviting for people who want to try other distro's. http://lists.debian.org/ports.html https://admin.fedoraproject.org/mailman/listinfo Why not even add a opensuse-mips mailing-list for people in for instance China who would like to work on a Loongson/Godson port. I think this will pull more hardware gurus to our distro. I think our current limiting approach set us behind other distro's on supported archs. This is something we see now in the arm port. This might happen again when another important architecture would appear. I think we should get rid of the opensuse-amd86 mailing-list as it's x86. One other thing I also don't understand is. WE currently build all ppc packages as Factory. Why don't we also build a the iso's for the current version, with the extra label unstable (so 12.1-unstable-ppc). Now a newbie that is interested in openSuSE on his old Mac won't be able to install openSuSE ppc due to the lack of a DVD. And therefor will move on to another distro. > > -- > Cheers > Richard (MQ) > -- > To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org > > Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] rootfs
by Bernhard Schuster 27 Oct '11

27 Oct '11

Can anybody point me to a (alpha,beta) rootfs, howto create such or what to fix in order to move forward towards it? I already read all openSuSE and ARM related pages but I did not stumble upon anything. I am especially interested in armv7hl for a BB-xM. Regards Bernhard Schuster -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

6 12

[opensuse-arm] [ml-admin] Merging the architecture lists to opensuse-arch
by Henne Vogelsang 27 Oct '11

27 Oct '11

Hey, we are currently trying to reduce the amount of communication channels we provide. Because of this I would like to merge the 4 architecture lists into one list called opensuse-arch. If nobody objects until the 15th of November 12:00 UTC I will merge the lists. You don't have to do anything except rewriting your filter if you use one. Thanks in advance for your consideration. Henne -- Mailing List Admin http://lists.opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

6 7

Re: [opensuse-arm] [ml-admin] Merging the architecture lists to opensuse-arch
by Joop Boonen 26 Oct '11

26 Oct '11

On Wed, October 26, 2011 3:25 pm, Andreas Färber wrote: > Hi, > > Am 26.10.2011 15:04, schrieb Henne Vogelsang: >> On 26.10.2011 14:58, Adrian Schröter wrote: >>> Am Mittwoch, 26. Oktober 2011, 14:29:57 schrieb Henne Vogelsang: >>>> >>>> we are currently trying to reduce the amount of communication channels we provide. Because of this I would like to merge the 4 architecture lists into one list called opensuse-arch. >>>> >>>> If nobody objects until the 15th of November 12:00 UTC I will merge the >>>> lists. You don't have to do anything except rewriting your filter if you >>>> use one. >>> >>> I would definitive unsubscribe from such a list if the majority of mails is >>> not interessting for me. >> >> The ppc, amd64 and ia64 lists didn't have any traffic in 2010 and 2011. I would like to have some point for people to go for non x86 >> architecture specific stuff. > > There was some recent activity to revive ppc openSUSE, so if arm stays ppc should probably stay as well. > amd64 is mainstream now, so that's different I guess. > I agree. I think it's best to have separate mailing lists for different architectures. I think traffic wise it also safes bandwidth. Only people that are interested in a specific mailing list will get this mail and not traffic they don't want. The ppc mailing list will be very interesting again when the AmigaOne X1000 and Netbook will be released. http://en.wikipedia.org/wiki/AmigaOne_X1000 http://eab.abime.net/showthread.php?p=781936 If this ends up in an active mailing list where also ARM resides it's difficult to filter, I'm subscribed to both. > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- > To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org > Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] Re: [opensuse-ppc] [ml-admin] Merging the architecture lists to opensuse-arch
by Joop Boonen 26 Oct '11

26 Oct '11

On Wed, October 26, 2011 2:29 pm, Henne Vogelsang wrote: > Hey, > > we are currently trying to reduce the amount of communication channels we provide. Because of this I would like to merge the 4 architecture lists into one list called opensuse-arch. > > If nobody objects until the 15th of November 12:00 UTC I will merge the lists. You don't have to do anything except rewriting your filter if you use one. > Wouldn't it be best to leave the arm mailing list as is until the arm port has been completed? > Thanks in advance for your consideration. > > Henne > > -- > Mailing List Admin > http://lists.opensuse.org > -- > To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org > > Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] request/sugestion to work together to get hardfp/OSS ARM GPU drivers and/or to get documentation
by Joop Boonen 23 Oct '11

23 Oct '11

Hi all, Most of the (ARM) distros are currently working on or in the transition to hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any hardfp drivers yet. To be able to have a ARM hardfp compiled X Window desktop system/notebook with 3D support we need hardfp compiled drivers. I was thinking it might be more efficient is all Linux distro's work together to get these drivers as it's equally important for all distro that wants to move to a hardfp distro. What do you all think, who wants to work together to get full hardfp support for as most as possible ARM SOC GPUs? It would be great if we can in the end even have OSS drivers. Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

[opensuse-arm] request/sugestion to work together to get hardfp/OSS ARM GPU drivers and/or to get documentation
by Joop Boonen 22 Oct '11

22 Oct '11

Hi all, Most of the (ARM) distros are currently working on or in the transition to hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any hardfp drivers yet. To be able to have a ARM hardfp compiled X Window desktop system/notebook with 3D support we need hardfp compiled drivers. I was thinking it might be more efficient is all Linux distro's work together to get these drivers as it's equally important for all distro that wants to move to a hardfp distro. What do you all think, who wants to work together to get full hardfp support for as most as possible ARM SOC GPUs? It would be great if we can in the end even have OSS drivers. And to have a good relationship with the GPU designers (for ARM SOCs) and hardware producers. If you know other distro's that are working on an ARM port or people that might want to help, an you please forward the email to them? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] [Fwd: RE: sgx540 linux drivers]
by Joop Boonen 19 Oct '11

19 Oct '11

Hi All, I'm investigating which GPU drivers are most compatible with GPL. Below you can see the answer I got from Imagination Technologies about the SGX540 driver, earlier on. Regards, Joop. Hi Joop, Yes, that is correct in most of the cases. There are parts that need to be customised for the platform like display drivers, memory configurations, etc. Regards Carlos. -----Original Message----- From: Joop Boonen [mailto:joop_boonen@*.*] Sent: 28 June 2011 10:16 To: Carlos Sarria Cc: IMGKL - DevTech Subject: RE: sgx540 linux drivers Hi Carlos, For my understanding. Does this mean that sgx540 drivers aren't generic drivers, that can be used for any ARM SOC that uses this GPU like the Samsung Hummingbird for instance? Regards, Joop. On Mon, June 27, 2011 5:07 pm, Carlos Sarria wrote: > Hi Joop, > > To release drivers for TI's platforms is not our responsibility and > MeeGo project on PandaBoard is completely unofficial. I doubt TI will > support it, although it will depend on the level of adoption of that > OS and whether TI sees any business opportunity on it. > > Best regards > > Carlos. > ------------------------------------------------------------------- > Carlos Sarria > Developer Technology Manager > Imagination Technologies Ltd. > Tel: +44 (0)1923 * > mail: *(a)imgtec.com > http://www.imgtec.com/ http://www.powervrinsider.com/ > > > > -----Original Message----- > From: Joop Boonen [mailto:joop_boonen@*.*] > Sent: 27 June 2011 11:37 > To: IMGKL - DevTech > Subject: sgx540 linux drivers > > Dear Madam, Sir, > > I'm using MeeGo on my Pandaboard. There aren't any sgx540/OMAP4430 > Linux drivers/source tar-ball available. > Do you know if/when they will be available? > > Thank you for your time. > > Regards, > > Joop. > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] [Fwd: Re: FW: Mali400 GL ES OSS drivers (502137)]
by Joop Boonen 19 Oct '11

19 Oct '11

Hi All, I'm investigating which GPU drivers are most compatible with GPL. Below you can see the answer I got from ARM about the Mali driver. As you can see the GL ES part isn't and probably won't be open sourced in the near future. Regards, Joop. [From Herve Lebreton - ARM Technical Support] Hello joop, > I'm very happy that you opened up the 2D part of the Mali drivers. The kernel driver was GPLed in order to comply with Android requirements. > I understood that the GL ES drivers for the Mali GPU are not open > source. > I've read they are in the Mali DDK. > I wonder who is allowed to use the DDK and if it's opensource? If not > are > there any plans to opensource the DDK? The DDK in user space is not open source and we have no plans to change this at the moment. Only ARM/Mali licensee have full access to the DDK source code so the normal procedure is that if you have any queries you should contact your SOC designer/ARM licensee (Depending on the request they may push it to ARM). Hope this helps. Regards, Hervé. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] No more armv7hl anymore in openSUSE:Factory:ARM ?
by Joop Boonen 18 Oct '11

18 Oct '11

All, I don't see the armv7hl build anymore in openSUSE:Factory:ARM. I hope it doesn't mean that we won't build armv7hl anymore? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 5

Re: [opensuse-arm] injecting arm packages
by Ulrich Hecht 17 Oct '11

17 Oct '11

On Monday 17 October 2011, Andreas Färber wrote: > I had spotted one source of errors last week: qemu-arm was being built > without libattr.a, so some xattr-related features were disabled, > resulting in lots of unsupported syscall messages. > > A new libattr-devel-static package is now in Factory and we need the > qemu package to depend on it. Don't know on what condition to choose > between libattr-devel and libattr-devel-static build dependency now. > Any help appreciated. AFAIK the QEMU system emulators don't use libattr, so it should be sufficient to have a build dependency on libattr-devel-static. CU Uli -- SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

Re: [opensuse-arm] injecting arm packages
by Adrian Schröter 17 Oct '11

17 Oct '11

Am Sonntag, 16. Oktober 2011, 20:29:38 schrieb Andrew Wafaa: > Michal has also been able to build gtk2 on native hardware too. I injected gtk2 a while ago. I am currently injecting a texlive build from Alexander. > Could we add > these to the list of packages to inject? When building with Qemu gtk2 > repeatedly causes a segfault and fails to build. At some point we need to fix the build or we can not ever make an ARM distribution release. No matter what the reason of this failure is. bye adrian > Regards, > > Andy > > -- > Sorry for top posting > > Andrew Wafaa > IRC: FunkyPenguin > GPG: 0x3A36312F > > On 16 Oct 2011 19:49, "Alexander Graf" <agraf(a)suse.de> wrote: > > Hi Adrian, > > > > We have a couple of pretty core packages that I can build just fine with > > native hardware, but did not manage to build with QEMU yet (namely, > > texlive-bin and yast2-core). However, since I can build them just fine > > on > > hardware, I can easily produce working rpms. > > > > Can we inject those rpms into the repository and with that at least > > continue building something we can then later on base a worker image on > > so we can then build everything natively? > > > > > > Alex > > > > -- > > To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org > > To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de

3 3

[opensuse-arm] injecting arm packages
by Alexander Graf 16 Oct '11

16 Oct '11

Hi Adrian, We have a couple of pretty core packages that I can build just fine with native hardware, but did not manage to build with QEMU yet (namely, texlive-bin and yast2-core). However, since I can build them just fine on hardware, I can easily produce working rpms. Can we inject those rpms into the repository and with that at least continue building something we can then later on base a worker image on so we can then build everything natively? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] iproute2 build without pdf documentation for once, as texlive-latex is broken?
by Joop Boonen 14 Oct '11

14 Oct '11

I have a request. iproute2 is a crucial package to install sysconfig. iproute is not build because of an issue with texlive-latex. This package is needed to generate the pdf files. (make pdf) I don't know if it's allowed for once to build this package just once without documentation in openSUSE:Factory:ARM, so openSuSE ARM can be tested with sysconfig? Can the "patch" please be applied once, in openSUSE:Factory:ARM, and rolled back after the package has been build and published? <diff> osc diff Index: iproute2.spec =================================================================== --- iproute2.spec (revision 86ae9170e809de093551e2286d24a5ba) +++ iproute2.spec (working copy) @@ -41,7 +41,8 @@ BuildRequires: libpng-devel libtiff-devel pkgconfig >= 0.19 BuildRequires: xorg-x11-devel xz %if 0%{?suse_version} -BuildRequires: ghostscript-x11 sgmltool texlive-latex +BuildRequires: ghostscript-x11 sgmltool +#BuildRequires: ghostscript-x11 sgmltool texlive-latex %endif %if 0%{?fedora} || 0%{?rhel} BuildRequires: ghostscript linuxdoc-tools sgml-common tetex-dvips tetex-latex @@ -94,7 +95,7 @@ xtlibdir="$(pkg-config xtables --variable=xtlibdir)"; make %{?_smp_mflags} LIBDIR=%_libdir CCOPTS="-D_GNU_SOURCE %optflags -Wstrict-prototypes -fPIC -DXT_LIB_DIR=\\\"$xtlibdir\\\"" cd doc -make pdf +#make pdf %install install -d %buildroot/{etc/,sbin/,usr/{sbin,share/man/man{3,8}}} @@ -125,8 +126,8 @@ %files doc %defattr(-,root,root) -%doc doc/api-ip6-flowlabels.pdf doc/arpd.pdf doc/ip-cref.pdf -%doc doc/ip-tunnels.pdf doc/nstat.pdf doc/rtstat.pdf doc/ss.pdf +#%doc doc/api-ip6-flowlabels.pdf doc/arpd.pdf doc/ip-cref.pdf +#%doc doc/ip-tunnels.pdf doc/nstat.pdf doc/rtstat.pdf doc/ss.pdf %doc ChangeLog examples/ ip/ifcfg ip/routef ip/routel %files -n libnetlink-devel </diff> Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 3

[opensuse-arm] openSUSE got hardware!
by Dirk Müller 14 Oct '11

14 Oct '11

Hi, What a nice surprise, we got a set of genesi Efika MX today: http://www.suse.de/~dmueller/efikamx/efikamx2.jpeg These are two standalone computer, and two smartbook/netbook like laptops. We've already set them up and just started package building on it. They're not yet connected to the external build service, this will come over the next weeks when Adrian is back. Thanks a lot! Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] Getting the correct kernel
by Andrew Wafaa 13 Oct '11

13 Oct '11

I know one of the reasons we chose a single target for hardware was to make the job of getting the right kernel and associated modules somewhat easier. Now (un)fortunately, we have some kind sponsors of hardware Genesi with the Efika MX and Pandaboard.org with the PandaBoard. How difficult would it be to have a single kernel that supports both these devices? I've had a sniff on the web and have found a kernel repo for EfikaMX[0] and PandaBoard[1], there is also the Linaro kernel[2] which I believe supports them; nice to have would be the BeagleBoard too. I believe they should all be supported in upstream but I can't say for certain, saying that though I believe the EfikaMX needs the siihdmi driver pushing upstream for the 3.x kernel. I have a contact to push about this and will chase him up later today. Regards, Andy 0=http://gitorious.org/efikamx/linux-kernel 1=http://gitorious.org/pandaboard/kernel-mainline 2=http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git;a=summary -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 4

[opensuse-arm] debian for native builds
by Peter Czanik 13 Oct '11

13 Oct '11

Hello, How can I use Debian for native builds? I have the Debian ARM HF running on my EFIKA smartbook. It also has "osc" installed, but when I try to build something, it complains, that build is not available. Bye, CzP -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] hwinfo of the PandaBoard booted with openSuSE ARM
by Joop Boonen 12 Oct '11

12 Oct '11

Hi all, For who are interested. This is the hwinfo , /proc/cpuinfo and /proc/meminfo output of the PandaBoard booted with openSuSE ARM. Regards, Joop.

1 0

[opensuse-arm] Just got the openSuSE ARM port running on the Pandaboard
by Joop Boonen 12 Oct '11

12 Oct '11

Hi All, I just got a basic openSuSE ARM port, OBS build armv7hl packages openSuSE packages, running on the Pandaboard. I used mic2, the script that is used for MeeGo. I had to patch 2 things one for the password and one as not all packages are available yet. Otherwise the mic2 build would stop because of a raise. I used these MeeGO panda instructions: http://wiki.meego.com/ARM/OMAP4_Panda I used a adapted Panda.ks.in and Panda.sh file, I've attached these files. MLO & u-boot was build according to: http://elinux.org/Panda_How_to_MLO_%26_u-boot I've attached all files. Regards, Joop. I've also posted 2 videos on you-tube: http://www.youtube.com/watch?v=bf5zKT2gWKs http://www.youtube.com/watch?v=FMziSoonpTU

1 0

[opensuse-arm] All JeOS packages according kiwi (suse-11.4-JeOS)
by Joop Boonen 10 Oct '11

10 Oct '11

Hi all, This are all packages that have been installed for kiwi image template suse-11.4-JeOS . These packages except grub and pciutils will also be needed for a basic arm install. It might be best to focus on fixing these packages first? So we can get a running machine faster and start testing on the Pandaboard. What do you all think? Regards, Joop.

5 7

[opensuse-arm] ipfire port to ARM
by Bill Merriam 08 Oct '11

08 Oct '11

It looks like you guys are doing very well with the port and probably don't need help but I decided to tell you about this distro that just did an ARM port. ipfire is based on Linux From Scratch, do they don't use RPM. Their announcement is here. http://www.ipfire.org/news/ipfire-2.11-available-on-arm The mailing list where they talk about the port is here. http://lists.ipfire.org/pipermail/sig-arm/ Their GIT repository with the ARM patches is here. I suppose we could shamelessly look at how they did it. http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/a… Since they started with a different software base I don't think the patches would be directly usable but if somebody is having trouble with a particular package you could look to see how they did it. I think we would thank them if we did that. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] dietlibc status
by Tim Serong 06 Oct '11

06 Oct '11

Hi All, I spent some time with dietlibc on the weekend. Here's the story: * The attached patch is necessary to fix the immediate build error (doesn't recognize armv7a as a known architecture). * If you apply this patch, later, the build fails with: gcc -D__dietlibc__ -I. -isystem include -fmessage-length=0 -march=armv7-a -mtune=cortex-a9 -mlittle-endian -mfpu=vfpv3-d16 -mfloat-abi=hard -mthumb -mabi=aapcs-linux -Os -Wall -fstack-protector -g -fno-strict-aliasing -c arm/__longjmp.S -o bin-arm/__longjmp.o arm/__longjmp.S: Assembler messages: arm/__longjmp.S:9: Error: selected processor does not support ARM mode `lfm f4,4,[ip],#48' Apparently, FPU vfpv3-d16 doesn't include the lfm opcode (nor sfm, used in setjmp). I am unfortunately grossly unqualified to have an opinion on this, or to (re)implement a correct setjmp/longjmp. * I suspected an upgrade to dietlibc 0.32 may be good/useful (see changelog at http://www.fefe.de/dietlibc/changes-0.32.txt, it mentions some ARM fixes), but AFACIT even upgrading to 0.32 does not fix the above lfm/sfm opcode issue. * Unless other packages depend on it, I'm somewhat tempted to suggest dropping dietlibc if suitable fixes can't be located. The last upstream release was in 2009, and there's mention of it having "numerous unfixed bugs" on the busybox web site (http://busybox.net/FAQ.html#libc) Regards, Tim -- Tim Serong Senior Clustering Engineer SUSE tserong(a)suse.com

3 4

Re: [opensuse-arm] Can openSUSE:Factory:ARM please be published
by Joop Boonen 04 Oct '11

04 Oct '11

On Sun, October 2, 2011 5:28 pm, Dirk Müller wrote: > On Sunday 02 October 2011, Joop Boonen wrote: > >> Can openSUSE:Factory:ARM please be published? >> If it's not allowed to publish it on download.opensuse.org can it please be published like the powerpc packages? arm.opensuse.org? > > As I don't know why it was disabled, I've enabled publishing of > openSUSE:Factory:ARM now. It looks like there is an issue publishing armv7hl packages (http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/armv7hl/) Packages are in state: "State needs recalculations, former state was: The repository state is being calculated right now" > > Greetings, > Dirk Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

2 1

[opensuse-arm] Cleaning up architecture mess ...
by Adrian Schröter 04 Oct '11

04 Oct '11

Hi, this my plan to cleanup the current mess with the architectures for ARM: * drop armv7hl scheduler and run only armv7el (armv7l would make more sense but to stay compatible with former OBS releases). * change target to produce armv7l.rpm's. The build flags and used hardware floating point switches will remain to be active. * adapt rpm to accept the not existing armv7hl architecture packages to stay compatible with Fedora and MeeGo. Reason behind this is that we currently mix ABI compatibilities and hardware features in the machine string. armv7l hardware should always be able to execute hard float binaries. When the ABI is not compatible this should be expressed by package dependencies. Any comments on this ? thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de

3 3

[opensuse-arm] xorg-x11-driver-video request to split-up
by Joop Boonen 03 Oct '11

03 Oct '11

Hi, Currently this package doesn't build for ARM as of broken code for the xgi driver. I wonder if it would be an idea to slit the package up into different rpm packages, for each driver one rpm package. Basically the same was MeeGo does. The advantage is that it'll safe space. What is important for ARM. I think that chance that an ARM system will be connected to a XGI card is next to nothing. So this driver doesn't need to be maintained for ARM, I think. What do you think about this? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

[opensuse-arm] xorg-x11-driver-video request to split-up
by Joop Boonen 03 Oct '11

03 Oct '11

Hi, Currently this package doesn't build for ARM as of broken code for the xgi driver. I wonder if it would be an idea to slit the package up into different rpm packages, for each driver one rpm package. Basically the same was MeeGo does. The advantage is that it'll safe space. What is important for ARM. I think that chance that an ARM system will be connected to a XGI card is next to nothing. So this driver doesn't need to be maintained for ARM, I think. What do you think about this? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

Re: [opensuse-arm] Can openSUSE:Factory:ARM please be published
by Joop Boonen 03 Oct '11

03 Oct '11

On Sun, October 2, 2011 5:28 pm, Dirk Müller wrote: > On Sunday 02 October 2011, Joop Boonen wrote: > >> Can openSUSE:Factory:ARM please be published? >> If it's not allowed to publish it on download.opensuse.org can it please >> be published like the powerpc packages? arm.opensuse.org? > > As I don't know why it was disabled, I've enabled publishing of > openSUSE:Factory:ARM now. It looks like there is an issue publishing armv7hl packages (http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/armv7hl/) Packages are in state: "State needs recalculations, former state was: The repository state is being calculated right now" > > Greetings, > Dirk Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

[opensuse-arm] Can openSUSE:Factory:ARM please be published
by Joop Boonen 02 Oct '11

02 Oct '11

All, Can openSUSE:Factory:ARM please be published? If it's not allowed to publish it on download.opensuse.org can it please be published like the powerpc packages? arm.opensuse.org? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

3 2

[opensuse-arm] Growing some openSUSE ARMs
by Andrew Wafaa 30 Sep '11

30 Sep '11

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(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

17 26

[opensuse-arm] Target ARM Hardware
by Andrew Wafaa 30 Sep '11

30 Sep '11

This is a hot topic, and one that seems to generate the most noise. I've had a discussion with several people about target hardware, and I've also looked at what our peers are doing and saying. At the same time I've been trying to see what options we have for getting some sponsorship for hardware. There were three devices in the running, all are classed as development boards - so no case or external prettyness (beauty comes from within anyway): TI PandaBoard [0] Samsung Origen [1] ST Ericsson Snowball [2] After discussing, the preferred nominee is the PandaBoard. Several factors led to this decision, it has an integrated wired network connection; is well supported by the incumbant distros; widely used within the wider ARM open source community; and it has Pandas (OK only in name but still!) So if you want to prep and get some hardware, then go for the PandaBoard (as soon as the Cortex A15 is released, we'll be looking at them). Yes, I know it's a developer board and not an end user product. Unfortunately there aren't actually that many end user products that you can sensibly use for development at the moment. Sure, there's the TrimSlice[3] the DreamPlug[4] and a few others, but after consulting someone that is far more knowledgable and aware of the wider landscape we went with their recommendations. Oh and things are moving pretty fast folk!! \o/ 0 = http://www.pandaboard.org/ 1 = http://www.origenboard.org/ 2 = http://www.igloocommunity.org/ 3 = http://trimslice.com/ 4 = http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

2 1

[opensuse-arm] Marvell Dreamplug D2 available for purchase
by Bill Merriam 29 Sep '11

29 Sep '11

Here is Marvell's description of the processor: The Marvell ARMADA 510 is a high-performance, highly integrated, low-power system-on-chip (SoC) with an ARM v6/v7-compliant superscalar processor core, hardware graphics processing unit, video decoding acceleration hardware and a broad range of peripherals. Targeted for smartbooks, thin clients, mobile internet devices (MIDs) and tablet devices, this high-performance SoC answers the need for fast processing and a rich multimedia user experience, in a low-power design that offers quick Internet browsing, software compatibility, HD video, 3D graphics and high-speed connectivity. Marvell’s ARMADA 510 (88AP510) SoC gives developers a fully integrated design that provides end users with the portability and similar battery life experience of a smartphone, along with the multimedia, software and browser performance of a PC. The D2 is not a board, is a complete system with case, power supply etc. It lists for US$250 which seems reasonable. It comes with Ubuntu 10.04 installed. Everything is open source, including graphics. Marvell maintains the kernel patches but I think they are upstream. Here are some links: http://plugcomputer.org/development-kits/d2plug.html http://www.marvell.com/application-processors/armada-500/index.jsp https://www.globalscaletechnologies.com/t-d2plugdetails.aspx Anybody have any thoughts about using this as a target platform? Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

Re: [opensuse-arm] bootstrapping current Factory for ARM
by Joop Boonen 26 Sep '11

26 Sep '11

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<dmueller(a)suse.de> 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(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

2 1

[opensuse-arm] bootstrapping current Factory for ARM
by Dirk Müller 26 Sep '11

26 Sep '11

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(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

7 7

Re: [opensuse-project] Re: [opensuse-arm] Growing some openSUSE ARMs
by Joop Boonen 23 Sep '11

23 Sep '11

On Fri, September 23, 2011 9:16 pm, Jan-Simon Möller wrote: > <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 ?! ;) That'll be one mean machine. (Certainly the upcoming Transformer 2 (TF201 ?) with the Tegra Kal El) I have looked into the Tegra2. I've read this story in connection with hardfp. http://www.slashgear.com/meego-tegra-2-drivers-could-end-android-monopoly-o… http://www.meegoexperts.com/2011/07/nvidia-meego-battle-ground/ This looks quite promising. I don't know when these drivers will be available I couldn't find any information yet. > Best, > Jan-Simon Just some information as people are looking into hardware. The trimslice might also be an option as you'll get 45% off as a developer, I don't know if it's still valid. http://trimslice.com/web/dev-kit IMHO the advantage it that there are a lot of Tegra devices Tablets etc. The disadvantage is IMHO that the driver is closed source. I don't know if the nouveau project could change this? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

Re: [opensuse-arm] Re: [opensuse-factory] Growing some openSUSE ARMs
by Joop Boonen 22 Sep '11

22 Sep '11

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(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

Re: [opensuse-arm] Re: Growing some openSUSE ARMs
by Joop Boonen 22 Sep '11

22 Sep '11

On Thu, September 22, 2011 5:41 pm, Guillaume Gardet wrote: > > > Le 22/09/2011 16:56, Greg KH a écrit : >> 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? :) > > 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(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

Re: [opensuse-arm] Re: Growing some openSUSE ARMs
by Joop Boonen 22 Sep '11

22 Sep '11

On Thu, September 22, 2011 5:22 pm, Alexander Graf wrote: > > Am 22.09.2011 um 17:13 schrieb Pavol Rusnak <prusnak(a)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-g… 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(a)opensuse.org > For additional commands, e-mail: opensuse-arm+help(a)opensuse.org > Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

RE: [opensuse-arm] Re: Growing some openSUSE ARMs
by J.Witvliet＠mindef.nl 22 Sep '11

22 Sep '11

From: Greg KH [mailto:gregkh@suse.de] Sent: Thursday, September 22, 2011 4:57 PM To: Andrew Wafaa Cc: openSUSE ARM ML; openSUSE Project ML; openSUSE Factory ML Subject: [opensuse-arm] Re: Growing some openSUSE ARMs 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 -----Original Message----- HP has some small general purpose ARM-boxes. See: http://h18000.www1.hp.com/products/quickspecs/13500_na/13500_na.HTML They are around $100,-- ______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

3 2

RE: [opensuse-arm] timeline?
by J.Witvliet＠mindef.nl 29 Aug '11

29 Aug '11

-----Original Message----- From: Bill Merriam [mailto:lists@billmerriam.com] Sent: Saturday, August 27, 2011 9:58 PM To: opensuse-arm(a)opensuse.org Subject: Re: [opensuse-arm] timeline? Hans, I too (and others) have wondered about this. The recently approved openSUSE strategy said, I think, that mobile devices are not a goal for openSUSE. You and I know that most mobile devices use ARM processors but there are a few desktop class devices that do also. More ARM desktop and server devices are expected in the near future. Ubuntu has announced that they intend to support ARM servers. They are current testing using Pandaboards. In the mean time I believe the openSUSE project's response to your question is "Thank you for volunteering". That have said a port to ARM is welcome but they can provide only general assistance. The Linaro foundation has links to development hardware. http://www.linaro.org/low-cost-development-boards Compulab is offering discounts on their Trimslice desktops is you can convince them you will use it to port an open source project to ARM. http://trimslice.com/web/dev-kit Marvell has a number of development kits available for purchase. Most of them are ARM5 processors but the not-yet-available D2plug is an ARM7 processor. http://plugcomputer.org/development-kits/ As you know the OBS can build ARM packages. openSUSE uses kiwi to turn those packages in to deploy-able images. I don't think it has been tested on ARM but it is written in PERL and should be easy to port. So there you go. Talk your employer into buying a few development kits. Install another distribution on it. Port kiwi to that and try to build an openSUSE image for it. In days, weeks, months or years you will have a working openSUSE distribution. I am sure you win a t-shirt for that :). Bill -----Original Message----- Tnx for the reply Bill, Yeah, I think I can understand their strategy. For the end-user-market, there is little love to gain employing a full arm-based distro: few people will be willing to play with their phone this way. OTOH, seeing the rising popularity of tablets, we are at the starting point of a fast rising market share. And for larger organizations/companies, using those ultra-thin clients, could be an answer to rising maintenance costs for desktops/laptops. I got people who are fed-up with picking up their laptop from their locker in the morning, and putting them back in the evening. A cheap (sub $100) thin-client would be ideal: -all identical configured -no hardware maintenance : just replace faulty one's If (...) SuSE could produce a bootable thinclient, it could promote business for their remote desktops on SLES. Regarding hardware, I already got a couple of HP's and Athena boxes. They were given to my team with a note "see what you can do with them". Indeed I noticed the presence of ARM packages on the OBS, but I've got no idea how much is already there. I mean for a thinclient, you need networking (net-boot), simple X-server and remote desktopclient. (actually I wonder how the builders ever tested their packages.) As for kiwi, afaicr you can do a cross-build (at least I managed to create a bootable 32-system, created on a 64-bit build environment). But here also: I can not determine if everything kiwi needs is there. Perhaps I should ask Andreas Schaeffer on/or the kiwi-list. Kind regards, Hans ______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0

[opensuse-arm] timeline?
by J.Witvliet＠mindef.nl 27 Aug '11

27 Aug '11

Hi all, Is there any rough idea if/when something bootable will be available? Point is, people want to replace desktops with HP-thinclients, And the (VIA) HP T5550 is more than double the price of the (ARM) HP T5335. For a dozen or so that should not matter, but for serious (3+ digits) numbers.... Furthermore some of us here would like to see a tablet running Linux. Personally, I would rather see SuSE on it, but is that realistic? I noticed that on the OBS, under "Ports" there is a 11.2/crosscompiled/arm7 tree Any progress been made towards a more-or-less full distro? Hans (hoping it gets through...) ______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

2 1

[opensuse-arm] openSUSE arm status?
by Guillaume Gardet 05 Jul '11

05 Jul '11

Hi, I did not find answers to my question on the web so I will ask here. What is the status of openSUSE for ARM? Is there repositories and/or images, so that we can boot openSUSE on ARM boards? I have a beagleboard xM, so if I can help, let me know! :) Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-arm+help(a)opensuse.org

1 0