- openSUSE ARM

[opensuse-arm] [PATCH] ARM: fix OMAP3 booting
by Alexander Graf 02 Mar '12

02 Mar '12

When running raw boot mode on OMAP3, it gets confused by x86 boot code. Unfortunately, parted automatically populated new msdos labels with x86 boot code which we need to remove first. So let's remove any boot code there is. This gets raw booting work on Beagleboard-xM for me. Reported-by: Guillaume Gardet <guillaume.gardet(a)free.fr> Signed-off-by: Alexander Graf <agraf(a)suse.de> --- modules/KIWIBoot.pm | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/modules/KIWIBoot.pm b/modules/KIWIBoot.pm index 8b3293e..96929bc 100644 --- a/modules/KIWIBoot.pm +++ b/modules/KIWIBoot.pm @@ -4573,6 +4573,20 @@ sub installBootLoader { $this -> cleanLoop (); return; } + # OMAP3 has issues when leaving x86 boot code in + # the MBR, so better clear that part of the image + $status = qxx ( + "dd if=/dev/zero of=$diskname bs=440 count=1 conv=notrunc 2>&1" + ); + $result = $? >> 8; + if ($result != 0) { + $kiwi -> failed (); + $kiwi -> error ("Couldn't install MLO on $diskname: $status"); + $kiwi -> failed (); + qxx ("umount /mnt 2>&1"); + $this -> cleanLoop (); + return; + } } qxx ("umount /mnt 2>&1"); } -- 1.6.0.2 -- 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] Pandaboard images
by Christian Galeffi 02 Mar '12

02 Mar '12

The new Pandaboard image from http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/ does not boot and there is still the boot.script problem: is missing the following at end of line: ... bootm 0x80000000 0x81600000" gallochri -- 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] An update about fixed and packages being worked on.
by Joop Boonen 27 Feb '12

27 Feb '12

Hi all, MozillaFireFox 10 will be fixed for ARM with the option --disable-neon. I've already tested this patch for MozillaFirefox 9.0 and I'm building MozillaFirefox 9.0.1 in home:worldcitizen:armv7l . What way would be best to communicate so no double work will be done. An overview of who is fixing what. I've also created a bug report for webkit, as this is not an ARM only bug. https://bugs.webkit.org/show_bug.cgi?id=76798 Regards, Joop. -- 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] ASUS EEE TRANSFORMER
by George Bratsos 27 Feb '12

27 Feb '12

Hello all, I am planning to buy an ASUS EEE TRANSFORMER TF101-1B141A 16GB. Will i be able to download and install any openSUSE-arm version??? I am new to arm so i want some general information about how to install it or what i must learn and watch out! Thanks in advance -- George Bratsos Etern4L @Freenode http://en.opensuse.org/User:Etern4L http://amb.opensuse.gr http://own.opensuse.gr http://etern4l.wordpress.com -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 6

[opensuse-arm] ARM and Virtualization
by Michal Hrusecky 24 Feb '12

24 Feb '12

Hi, I know we don't use native builds in obs for security reasons and for not working virtualization (kvm, xen), but I was going through FOSDEM videos and what sounded interesting was OpenVZ presentation and the presenter said that OpenVZ works on ARM already. Do you think that OpenVZ would be enough (regarding security) to connect our ARM devices to the public OBS? Is it worth exploring? Did somebody already tried that? -- Michal Hrusecky <Michal(a)Hrusecky.net> -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

[opensuse-arm] efika handed to dsterba
by Tomas Cech 23 Feb '12

23 Feb '12

Hi, efika.suse.cz was given to David Sterba from Labs, he's focused on fixing filesystem problems. Best regards, Tomas Cech Sleep_Walker

1 0

[opensuse-arm] Outcome of the round table meeting
by Andrew Wafaa 23 Feb '12

23 Feb '12

We had a round table meeting this morning in the SUSE offices in Nuremberg. The intention of the meeting was to try and get some form of milestones agreed, and work out our next moves and find out what tasks etc need to be done. Several decisions were made: 1.) ARMv7 is the focus. This isn't necessarily news, but we just wanted to reiterate the message. Also the ARMv5 builds are going to have their priorities in the OBS lowered to minimise the build power consumption. We're not deleting them, just not focusing on them; if someone *really* wants v5 builds then best you roll your sleeves up and get stuck in, we will provide support, guidance and encouragement. 2.) We are aiming for 12.2 to have full ARM support. So this means we need to freeze in time for 12.2 RC1, so we can not have any build failures. If there are we need to fix them, but some applications are known not to run on ARM, where these are identified we will just use "ExcludeArch: %arm". This needs to be done by 01June2012 at the latest. 3.) To ensure we can make the deadline we need to make sure that all sources are submitted into Factory via the respective devel projects. This means that we have no source overlays in the openSUSE:Factory:ARM repo. Also that all hacks and "fixes" are discussed with maintainers and either incorporated or better fixes are submitted. We will *NOT* have separate sources or patches for the ARM port, everything will have to be in Factory. 4.) We need to have a reference platform that *ALL* developers can use to verify 12.2 will work, this will be the Pandaboard. This does not mean we will not be supporting other devices, like Snowball, Beagleboard or Origen; they will be available but they may not have gone through the same rigorous tests. We will also look at having XFCE as the reference platform Desktop Environment. Now before anyone starts calling for blood, there were some reasons for refernece platform decision: a.) There are sufficient numbers of Pandaboards for developers to use b.) Pandaboard has the best upstream support out of all the devices c.) We already have Kiwi based images for it d.) XFCE is the only DE that builds almost completely and runs at the moment e.) 2D graphics work out of the box on the Pandaboard 5.) openSUSE's ARM port has gone on a diet. The Geeko is now FATless, this means we no longer have a separate FAT partition for the boot file system. All partitions are now ext3 by default, BTRFS is supported but isn't our default. 6.) The Kiwi generated images will use the OEM format rather than the Live Install format. Basically this means that a user will "dd" the image to the target SD card and then the "second boot" process will kick in when a user boots from the card so that they can configure passwords/network/etc and it will repartition to take up the whole of the card. 7.) Bernhard is going to look at integrating ARM support into OpenQA[0]. This means we can get advance notice of breakages etc. prior to releasing images. 8.) We will be triggering a rebuild of the ARM repo to ensure that builds take into account some of the big changes that have happened in Factory (like the Xorg changes), and also to clean out any "fixes" that were applied to the repo. This will most likely be initiated in batches rather than the complete repo, hopefully we can avoid the repo being out of commission for four weeks this way. Another outcome of the meeting was working out some tasks that needed to be completed. There aren't that many tasks and they are open to *EVERYONE* to help out with: I.) We need to keep a closer eye on the package failures. Using Dirk's Build Comparison page[1] will help to isolate failures due to qemu. All qemu bugs/issues need to be passed on to either Alexander Graf (agraf) or Andreas Farber (afarber) for fixing. II.) We need to look at YaST's second stage module and see if that will be of use to the ARM port. III.) We really need to re-work the wiki for the ARM port. It needs to be much more detailed as it hasn't been updated in a while. So that gives us three months or 12 weeks to get our house in order. Regards, Andy 0 = http://openqa.opensuse.org/ 1 = http://www.suse.de/~dmueller/arm-buildservice/ -- 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 0

[opensuse-arm] OpenSUSE ARM and Raspberry Pi
by Alfio Emanuele 22 Feb '12

22 Feb '12

Hi guys. Maybe you've already heard about it, but recently something apparently cool came to my eyes. A group of British folks from the Cambridge University have built a credit-card-sized computer on top of an ARM CPU, called the "Raspberry Pi". The most impressing fact about this device is its price: 25 and 35 $ (respectively model A and B). Here are some spare specs from their website: - ARM 700Mhz Broadcom CPU - 128 and 256 MB RAM (depending on the model) - 1080p30 playback capabilities - HDMI and composite video output - 3,5 mm audio - 1 and 2 USB ports - an ethernet rj45 connector. For further info give a look at their website http://www.raspberrypi.org/ (specs into FAQs). Now, it has started like another OLPC project: a cheap machine for educational purposes, but because of its price, size and everything is great for industrial purposes too (there's someone at broadcom developing a cheap expansion card that can be used to drive motors, sensors and stuff like that - see http://www.raspberrypi.org/archives/500) Some guys at Fedora have been working on their ARM distribution and will be relasing their Raspberry version tomorrow - http://www.raspberrypi.org/archives/676 There also is a working Debian version with basic software such as LXDE a browser and a Python interpreter. Being interested in writing software for these machines and - first of all - in OpenSUSE, I was wondering if we had software able to run on the Pi. I started looking at the ARM opensuse project and, thanks to miska, I discovered that yes - we have some software ready. In particular the Pi processor is an ARM11 (ARMv6), and we have some compatible ARMv5 packages in the repository, but still not enough to have a nearly complete working desktop system. (There isn't any web browser, is there?) Also, it seems there are no enough ARM machines working to the Build Service to serve this project. I'd be glad to know how every thing's going on, how can I help and what can I do to help openSUSE beat Fedo.... I mean, rock all the way. But, principally, if someone else is interested in it. And, just a note: Because of their price, couldn't a couple more Pi take the place of the PandaBoards? Referring to the campaign, http://pledgie.com/campaigns/16098 With the money, ~415€, you could buy like 10 Pi boards plus SD cards and stuff, but this is just a flash idea) Maybe it's just a fool thought, but I sincerely hope to see a lot of geckos on these little machines. An old man once told me: You have to "... foster the success of Linux everywhere. We want Linux to be successful in a wide range of application domains like server, desktop, or development". Thanks and "have a lot of fun", Alfio. -- 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] subscribe
by Bamvor Jian Zhang 17 Feb '12

17 Feb '12

1 0

[opensuse-arm] Reboot on Pandaboard
by Christian Galeffi 14 Feb '12

14 Feb '12

Hi, I' m using the image from http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/ on my Pandaboard, after restart the bootloader no longer find the boot partition. How can I fix this? Thanks, gallochri -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 6

[opensuse-arm] Build problem due to non resolable issue
by Joop Boonen 12 Feb '12

12 Feb '12

Hi, Currently no package is build any more. for standard armv7l. As pcre is depending on grep which again is depending on libpce, "nothing provides libpcre.so.0 needed by grep" How can this be resolved? 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] ro
by Peter Czanik 10 Feb '12

10 Feb '12

Hello, Recently any time I boot my EFIKA, I get many error messages, that / is read only and some services can't be started. Is it specific to EFIKA (the image from Bernhard, which uses the Genesi provided kernel), or generic ARM problem, or something I messed up? I recall reading something on IRC about read only root and updated my machine recently... 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 2

[opensuse-arm] rpmlint issue for ARM OBS armv7l
by Joop Boonen 08 Feb '12

08 Feb '12

Hi All, When I package home:worldcitizen:armv7l xorg-x11-drv-ste I get an rpmlint error: E: xorg-x11-drv-ste 64bit-portability-issue mali_fbdev.c:1177 I think this is incorrect as I there is no error in the compile log, only some warnings, and 64 bit is not an issue for ARM (yet). As it's an error I cant suppress it via an rpmlintrc filter file. 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] [PATCH] arm: use ext2 for booting
by Alexander Graf 06 Feb '12

06 Feb '12

Now that x-loader on OMAP can boot from ext2, let's also teach kiwi about that awesome new capability. This gets rid of the vfat dependency and makes the whole bootstrap a lot cleaner. Signed-off-by: Alexander Graf <agraf(a)suse.de> --- modules/KIWIBoot.pm | 51 +++++++++++++++++++++++++++++++++++++++-------- modules/KIWILinuxRC.sh | 4 +- 2 files changed, 44 insertions(+), 11 deletions(-) diff --git a/modules/KIWIBoot.pm b/modules/KIWIBoot.pm index 88d8d41..21b623c 100644 --- a/modules/KIWIBoot.pm +++ b/modules/KIWIBoot.pm @@ -1711,7 +1711,7 @@ sub setupBootDisk { # setup boot partition type #------------------------------------------ my $partid = 83; - if ($bootloader =~ /syslinux|uboot/) { + if ($bootloader =~ /syslinux/) { $partid = "c"; } elsif ($bootloader eq "yaboot") { $partid = "41"; @@ -2224,7 +2224,7 @@ sub setupBootDisk { if ($lvm) { $boot = $deviceMap{0}; } - if ($bootloader =~ /syslinux|uboot|yaboot/) { + if ($bootloader =~ /syslinux|yaboot/) { $kiwi -> info ("Creating DOS boot filesystem"); if ($bootloader eq "yaboot") { $status = qxx ("/sbin/mkdosfs -F 16 $boot 2>&1"); @@ -3904,8 +3904,8 @@ sub setupBootLoaderConfiguration { print FD 'setenv initrd_high "0xffffffff";'."\n"; print FD 'setenv fdt_high "0xffffffff";'."\n"; print FD 'setenv bootcmd "'; - print FD 'fatload mmc 0:1 0x80000000 boot/linux.vmx; '; - print FD 'fatload mmc 0:1 0x81600000 boot/initrd.uboot; '; + print FD 'ext2load mmc 0:1 0x80000000 boot/linux.vmx; '; + print FD 'ext2load mmc 0:1 0x81600000 boot/initrd.uboot; '; print FD 'bootm 0x80000000 0x81600000";'."\n"; if ($type =~ /^KIWI CD/) { $kiwi -> failed (); @@ -4464,7 +4464,44 @@ sub installBootLoader { # install uboot #------------------------------------------ if ($loader eq "uboot") { - # uboot loader doesn't get installed + if (! $deviceMap) { + $kiwi -> failed (); + $kiwi -> error ("No device map available"); + $kiwi -> failed (); + return; + } + my %deviceMap = %{$deviceMap}; + my $device = $deviceMap{$bootpart+1}; + + #========================================== + # mount boot device... + #------------------------------------------ + $status = qxx ("mount $device /mnt 2>&1"); + $result = $? >> 8; + if ($result != 0) { + $kiwi -> failed (); + $kiwi -> error ("Can't mount boot partition: $status"); + $kiwi -> failed (); + $this -> cleanLoop (); + return; + } + #========================================== + # install MLO as raw + #------------------------------------------ + if (-f "/mnt/boot/MLO") { + $kiwi -> info ("Installing MLO on device: $diskname"); + $status = qxx ("dd if=/mnt/boot/MLO of=$diskname bs=128k count=1 seek=1 conv=notrunc 2>&1"); + $result = $? >> 8; + if ($result != 0) { + $kiwi -> failed (); + $kiwi -> error ("Couldn't install MLO on $diskname: $status"); + $kiwi -> failed (); + qxx ("umount /mnt 2>&1"); + $this -> cleanLoop (); + return; + } + } + qxx ("umount /mnt 2>&1"); } #========================================== # more boot managers to come... @@ -5496,10 +5533,6 @@ sub __getBootSize { if ($gotMB < $minMB) { $gotMB = $minMB; } - # on arm it's required to have a maximum of 64MB for the boot part - if ($arch =~ /arm/) { - $gotMB = 64; - } $kiwi -> loginfo ("Set boot space to: ".$gotMB."M\n"); return $gotMB; } diff --git a/modules/KIWILinuxRC.sh b/modules/KIWILinuxRC.sh index 70e2688..6f37c6f 100644 --- a/modules/KIWILinuxRC.sh +++ b/modules/KIWILinuxRC.sh @@ -1544,8 +1544,8 @@ function setupBootLoaderUBoot { echo "setenv initrd_high \"0xffffffff\";" >> $conf echo "setenv fdt_high \"0xffffffff\";" >> $conf echo -n "setenv bootcmd \"" >> $conf - echo -n "fatload mmc 0:1 0x80000000 $kernel; " >> $conf - echo -n "fatload mmc 0:1 0x81600000 $initrd; " >> $conf + echo -n "ext2load mmc 0:1 0x80000000 $kernel; " >> $conf + echo -n "ext2load mmc 0:1 0x81600000 $initrd; " >> $conf echo "bootm 0x80000000 0x81600000\"" echo -n "setenv bootargs root=$diskByID loader=$loader" >> $conf if [ ! -z "$imageDiskDevice" ];then -- 1.6.0.2 -- 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] Build openjdk6 with a different virtual machine?
by Michal Vyskocil 03 Feb '12

03 Feb '12

Hallo all, please leavy me in a CC as I am not on the list thanks a hard work of Dirk, we are now able to build and run openjdk6 in Factory for arm. The current incarnation use the Zero Assembler port [1]. It means there is no JIT and java runs in interpreted mode only, which is slow. icedtea patchset provide a neat support for build openjdk with different vm, than hotspot (or zero). For arm users I would say there are three choices: * shark - an llvm based experimental JIT * JamVM a state of the art interpreter using dynamic super instructions (a code copying JIT) with quick startup time and low memory usage suitable for embedded and client use, developed by Robert Lougher. This JVM are the default on Ubuntu/ARM systems. JamVM work on armel, armhf, OpenJDK-6 and OpenJDK-7. * CACAO a state of art JIT, developed as a research JVM by the university of Vienna. Working on armel and openjdk-6. See labb.zafena.se/?p=471 for other details I did some basic research what other distributions use: * Fedora recently added a support for arm into rawhide, however they use zero * Debian supports everything (zero, zero/shark, cacao, jamvm) It seems that cacao would be the best choice, as it's mature, has big performance and so. However it does not work with openjdk7, even there is a recent work [2] to make it happen. And what can be worse, the armhf is not supported by CACAO atm and I did not find anything related. As openjdk7 is still not an issue for openSUSE@arm, the armhf might be. So what will be your choice for VM? 1.) CACAO (aka use stable, faster solution) 2.) JamVM (aka we need armhf) 3.) do-not-touch-it Note: I wont follow Debian support everything approach, their rules [3] file scares me as it looks worse than our spec file. [1] http://icedtea.classpath.org/wiki/ZeroSharkFaq [2] http://mips.complang.tuwien.ac.at/hg/cacao/rev/30edcde287d9 [3] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk7/view/head:/rules Best regards Michal Vyskocil

2 1

[opensuse-arm] omap fatless boot
by Alexander Graf 03 Feb '12

03 Feb '12

Hi list, Dirk had an idea a while back. On OMAP we have this pretty sad situation where we need to have /boot be a FAT partition so we can store MLO and u-boot.bin on there. But why do we need FAT there? Let's take a look at the boot process: - built-in ROM boots - built-in ROM searches for MLO in first active FAT partition - built-in ROM starts MLO - MLO searches for u-boot.bin in first(!) FAT partition - MLO boots u-boot So both components have FAT hardcoded in them. Or do they? The built-in ROM actually has an alternative boot mode which is called "raw". If it finds a small header at certain locations of the SD card (offset 0, offset 128kb) it loads MLO from there instead of FAT. Since we always align our partitions on 1MB boundaries, we have 1MB of free space below the first partition! MLO may only be up to 64kb big, so it fits there pretty well. Now to the next problem. MLO uses FAT. But MLO really is x-loader which is a modified version of u-boot. And u-boot can do ext2. So why don't we just take u-boot's ext2 support and throw it into our MLO binary? Well, this whole thing turned out a bit trickier than I anticipated, but eventually I got it rolling. Here's the patch: https://build.opensuse.org/package/view_file?file=0001-add-ext2-support.pat… I also verified that it works at least in an emulator. Since I don't have a beagle board, I couldn't verify if it works on real hardware. But to me the beagle target is mostly important for the emulation bit anyway :). The next target is x-loader for omap4 (panda) which hopefully will be easier to deal with. And once that's ext2'ified, we can remove the whole FAT dependency from our shiny ARM target! Yay! Happy hacking, and see you at fosdem! Alex PS: I also had to fix qemu's raw booting mode, since it wasn't behaving according to spec. So don't try this on qemu-linaro just yet :).-- 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: Wanted: superstar hacker to complete Mono port to armhf
by Alexander Graf 02 Feb '12

02 Feb '12

On 03.02.2012, at 00:11, Hector Oron wrote: > Hello Jo, > > I am forwarding the message to a couple mailing lists which might have > people interested on the Mono porting for ARM hard-float ABI. > > 2012/2/2 Jo Shields <directhex(a)apebox.org>: >> Right now, Mono is available in Debian armhf. This is a hack - what >> we're actually doing is building Mono as an armhf binary, but built to >> emit soft VFP instructions and using calling conventions and ABI for >> armel. This hack works well enough for pure cross-platform code (like >> the C# compiler) to run, but dies in a heap for anything complex. >> >> This situation is a bit on the crappy side of crap. >> >> In order for Mono on armhf not to be a waste of time, a "true" port >> needs to be completed. If I were to make a not-remotely-educated guess, >> I'd say it needs about 550 lines of changes, primarily the addition of >> code to emit the correct instructions feeling the correct registers in >> mono/mini/mini-arm.c plus a couple of tweaks to related headers. >> >> Upstream have also indicated that they're happy to provide guidance and >> pointers on how to implement this port, although they're unable to >> provide the requisite code themselves. >> >> Sadly, unless someone in the community is able to step forward and >> contribute here, it's only a matter of time before the armhf packages >> are rightfully marked RC-buggy, and 100+ packages need to be axed from >> armhf. This would make me sad. Please check our mono arm patches in OBS: https://build.opensuse.org/package/files?package=mono-core&project=openSUSE… While slightly hacky, they enable full armhf support for arm. At least for us it's worked pretty well. Mono is a rather core dependency of a lot of stuff. Alex -- 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] kiwi build
by Alexander Graf 02 Feb '12

02 Feb '12

Hi guys, Great news! Kudos to Adrian for getting some of the OBS internals to work with new kiwi, we have our first ARM image built with kiwi: http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/Lim… It's even using the brand new "tbz" image type, which means that the tarball you see there actually contains another tarball which contains a rootfs to play around with. You can use that with your own kernels, with our kernels, as chroot on your android system. Anything you can imagine! :) There are still some things to straighten out. We have to inject qemu into the target system to be able to build, but we really don't want to keep it around after building is finished. So we have to figure something there :). Also, I'm currently trying to get efika and panda images rolling. So far the initrd creation is missing qemu again, but that should only be a matter of tweaking a few things. And by then we should have kiwi images available for the public! Just in time for FOSDEM! Yay! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 4

[opensuse-arm] X on efika
by Peter Czanik 01 Feb '12

01 Feb '12

Hello, Using Bernhard's efika as a basis image I installed xfce and xorg packages on my machine. But when I try to start X, I get: " (EE) No devices detected. Fatal server error: no screens found " Does anybody have an xorg.conf to get started? 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 3

[opensuse-arm] In which devel project should a kernel reside?
by Joop Boonen 01 Feb '12

01 Feb '12

Hi all, I want to put the Toshiba AC100 kernel (kernel-tegra-ac100) in Factory. I sent a submit request to Base:Kernel but it looks like very few users are in this project. Is this the best devel project for this kernel? Or would it be better if another project would be created. 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 10

[opensuse-arm] OBS armv7l postfix cant resolve rpm-build
by Joop Boonen 29 Jan '12

29 Jan '12

Hi all, Currently postfix and some other packages for armv7l cant be (re)build cause rpm-build cant be resolved. https://build.opensuse.org/package/show?package=rpm&project=openSUSE%3AFact… https://build.opensuse.org/package/show?package=postfix&project=openSUSE%3A… 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] Native ARM builds moved to IBS
by Dirk Müller 28 Jan '12

28 Jan '12

Hi, [This message is only for SUSE employees, sorry. The urls below do not work externally] Native builds moved away from the testing instance to the standard production internal build service, which is an important step in stabilizing the build and making it available for a broader audience. Also kiwi building has been enabled internally, so you can do your own test images for the particular hardware that you play with. please change reiser.suse.de... in your download urls to http://dist.suse.de/ibs/Devel:/Factory:/ARM/standard/ arm is not restricted, so you can setup your own home projects with arm builds for testing purposes. Submitrequests with fixes against this project do work, but please submit to openSUSE:Factory / devel projects like usual instead. kiwi image descriptions can be submitted as you like. Note the repo above is still pretty empty, but it is filling up fast (it is rebuilding from scratch at the moment). If you want to help out with build power, please contact me directly for details on how to do that. Thanks, 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] resizing partition
by Peter Czanik 27 Jan '12

27 Jan '12

Hello, I'm using the EFIKA image from bmwiedemann, and it works great. I'd like to add a few more things. The image is from a 1GB card, I use a 4GB SD card. Is there an easy way to resize the / partition to 3.8GB? Yast2 & gparted did not work... Bye, CzP -- 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] Chance for a meet up or two
by Andrew Wafaa 26 Jan '12

26 Jan '12

Aloha oh wonderous iron pumping Geekos, Sorry for the over enthusiastic opening, my brain is slowly turning to mush. With FOSDEM coming up in a week's time I thought it would be a good idea to see if those that are attending can get together for a bit of a session to iron out issues etc. It wont necessarily be a hugely productive one, as in we may not be able to do any coding etc, but we should at least be able to note some action items etc down. Also I am going to be at the mother ship on the 21st Feb till the 23rd Feb, and was hoping to spend a couple of days hacking/packaging/whatever is needed to get things moving further. I have a Board meeting on the 22nd Feb all day but both 21st & 23rd are free. If those in NUE are able to, it would be great to have as many heads/hands/eyes in a room to pull a rabbit out of the hat. Any one up for either of these? 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

4 3

[opensuse-arm] OBS ARM resolving issue (rpm cant be build).
by Joop Boonen 26 Jan '12

26 Jan '12

Hi all, I see that rpm cant be build because of "nothing provides lua51-devel". https://build.opensuse.org/package/show?package=rpm&project=openSUSE%3AFact… The lua51-devel package has been build. https://build.opensuse.org/package/show?package=lua51&project=openSUSE%3AFa… 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

Fwd: Re: [opensuse-arm] Re: FOSDEM talk
by Andreas Färber 25 Jan '12

25 Jan '12

Michal, Most of these issues still apply to the second draft. :/ Andreas -------- Original-Nachricht -------- Betreff: Re: [opensuse-arm] Re: FOSDEM talk Datum: Tue, 24 Jan 2012 12:04:42 +0100 Von: Andreas Färber <afaerber(a)suse.de> Organisation: SUSE LINUX Products GmbH An: Michal Hrusecky <michal(a)hrusecky.net> Am 24.01.2012 11:19, schrieb Michal Hrusecky: > Ok, so here is[1] the first draft of slides about what I want to speak > about. I want to mention HP Project Moonshot[2] as well, but haven't > found suitable image so far, so it will be included later. What I wanted > to ask for is some feedback especially what am I missing (especially in > troubles section) or what I have wrong. > > Generally any feedback appreciated. > > [1] http://dl.dropbox.com/u/8023816/chameleon.pdf > [2] http://h17007.www1.hp.com/us/en/iss/110111.aspx Page numbering seems inconsistent. p.7: ARM @ openSUSE p.7: several people spent p.8: fixes go p.10: QEMU p.11: QEMU; some packages run p.12: hopes up for ARM support to be ready for...? p.13: PandaBoard vs. Panda Board on p.6 Regards, 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

2 1

[opensuse-arm] FOSDEM talk
by Michal Hrusecky 25 Jan '12

25 Jan '12

Hi, so I went to the mailing list and got slot reserved in the CrossDistribution Devroom for the openSUSE on ARM talk. According to the current schedule it looks like it will be on Sunday: 10:30-11:00 Michal Hrusecky: openSUSE on ARM 11:00-12:00 Adrian Schröter: OBS Cross Build I'm going to prepare some slides, hopefully soon and will post it here for comments. Although I'm listed in schedule, it definitely doesn't mean that I want to steal all the attention. IIRC there is plenty of space on stage :-D My intentions are to make openSUSE ARM port more famous, hopefully attract more people and do some good introduction for Adrians talk :-D -- Michal Hrusecky <Michal(a)Hrusecky.net> -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 11

[opensuse-arm] Re: [opensuse-factory] 12.2 roadmap
by Joop Boonen 24 Jan '12

24 Jan '12

Hi Andreas, Andrew, On Tue, January 24, 2012 3:43 pm, Andreas Jaeger wrote: > On 01/24/2012 10:47 AM, Joop Boonen wrote: >> Hi, >> >> On Fri, January 20, 2012 3:31 pm, Stephan Kulow wrote: >>> Hi, >>> >>> I wait now for> 24 hours for www.suse.de to sync out my >>> directory and it won't happen. >>> >>> So I synced it to my private web page for you to review: >>> >>> http://stephan.kulow.org/opensuse_12.2/ >>> >>> 9.2 - Milestone 1 >>> 8.3 - Milestone 2 >>> 5.4 - Milestone 3 >>> 26.4 - Milestone 4 >>> 24.5 - Beta 1 >>> 14.6 - RC 1 >>> 28.6 - RC 2 >>> 6.7 - GM >>> 11.7 - 12.2 >>> >> What are the current plans for the ARM distro. Will we also follow this? >> I hope we will. > > If you make it, I'm more than happy. But let's not delay 12.2 overall > because of ARM - we can make a separate announcement if needed. > > So, please discuss with the ARM team and decide whether you want to join > in... Andrew, do know what the current planning is? Andreas, do you know, if it would be an option to have a 12.2-unstable or 12.2-testing release at the end. So we have a more stable release for people who want to experiment with openSUSE on ARM. I'm still working on fixing ARM packages. So I hope they consider me joined in. > > Andreas > -- > Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 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] [ANN] armStoneA8 and Embedded World 2012
by Andreas Färber 16 Jan '12

16 Jan '12

Hi everyone, German company F&S Elektronik Systeme GmbH has announced the "armStoneA8" [1], a Cortex-A8 based board with Linux BSP, for upcoming Embedded World [2]. It sounds similar to the Beagle Board. What's interesting is that from Jan 30 to Feb 5 it will be sold for an introductory price of 49 EUR (probably plus 19% VAT). On a related matter, this year's Embedded World Conference keynote (Feb 28 13:00 in Nürnberg) will be held by ARM Ltd.'s CTO Mike Muller [3]. Regards, Andreas [1] http://www.fs-net.de/cms/index.php?id=71&L=1&tx_ttnews[tt_news]=97&tx_ttnew… [2] http://www.embedded-world.de/ [3] http://www.embedded-world.eu/program/speakers.html?speakerid=23003 -- 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

1 0

[opensuse-arm] FOSDEM
by Michal Hrusecky 11 Jan '12

11 Jan '12

Hi, I guess everybody is looking forward to the FOSDEM, we are all trying to prepare our gadgets to work the best with openSUSE to show off at the booth. But what we can do more. I'm suggesting submitting a talk to the distro miniconference (they are short of talks anyway) and speak about the progress and the current status of openSUSE @ ARM. I don't mind submitting it, preparing it and doing it (I gave some talk about it on our last release party, so I a little something ready already). But as most of the work was done by the others, I feel that it would be unfair to go ahead and submit it as my talk and then just speak about you guys without even discussing it with you first. So what are your opinions? btw. I think it is quite wide topic and FOSDEM is developers conference after all, so it might be worth even multiple sessions, I'm sure there are some low-level OBS/qemu stuff that were hit on the way to the current state... If there will be no ideas or more qualified proposals, I will just submit general talk proposal, speak about how we do stuff, where are we and how we are progressing... Current list of proposals is I believe here: http://barbershop.grep.be/~wouter/fosdem/2012/talk_proposals.txt There is ARM BoF, but I think we still can present openSUSE progress separately ;-) -- Michal Hrusecky <Michal(a)Hrusecky.net> -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 4

[opensuse-arm] OBS ARM build discussion I would like to start
by Joop Boonen 02 Jan '12

02 Jan '12

Hi all, Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu. Because qemu is much slower them native ARM builds the external build is way behind. So for people outside of suse.com it's not really possible to fix packages as you don't know if the current status is still valid. I would like to know how the people in charge of OBS think about this? Can the current situation be changed or is this due to a security policy? Can we help to solve this issue? If so what are the problems we are facing and which security should be met? Did I leave something out or is something now correct? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 5

[opensuse-arm] "dead lock" between autoyast2 and yast2-schema
by Joop Boonen 28 Dec '11

28 Dec '11

All, Currently there is a "dead lock" between package autoyast2 and yast2-schema (for the openSUSE:Factory:ARM build). The thing is that autoyast2 Requires yast2-schema. Because of this yast2-schema is blocked. I got around this by removing the autoyast2 requirement. Until yast2-schema has been build. When this package was build I added the Requirement again. I wonder if there is a better "mechanism" in OBS that solves such "lock issue" automatically? Otherwise someone has to handle this by hand. 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] yast2-all-packages patch
by Joop Boonen 24 Dec '11

24 Dec '11

Hello YaST development, I understood that all YaST changers aren't handled via the build server? Can the attached patch please be applied to yast2-all-packages. It now has the line: %ifnarch ia64 ppc ppc64 s390 s390x %arm Wouldn't it be better to replace it by: %ifarch %ix86 x86_64 In the patch it's in the syntax as currently is in the spec file. Regards, Joop.

1 1

[opensuse-arm] yast2-country patch in openSUSE:Factory:ARM needed
by Joop Boonen 24 Dec '11

24 Dec '11

Dear all, Can someone please apply the attached patch to: openSUSE:Factory:ARM yast2-country It's quite urgent as this one should build yast2 . The problem is that I cant create a submit request against openSUSE:Factory:ARM, this package is a unique openSUSE:Factory:ARM version. Regards, Joop.

1 0

[opensuse-arm] yast2-country patch in openSUSE:Factory:ARM urgently needed
by Joop Boonen 24 Dec '11

24 Dec '11

Dear all, Can someone please apply the attached patch to: openSUSE:Factory:ARM yast2-country It's quite urgent as this one should build yast2 . Regards, Joop.

1 0

[opensuse-arm] Factory:ARM Status
by Dirk Müller 20 Dec '11

20 Dec '11

Hi, I worked this afternoon a bit more on build failures and various other package build issues. Meanwhile we have over 4200 packages that have succeeded building, which is almost the complete distribution. We're so far missing all dependencies behind libwebkit* as it fails to build for both a compiler bug and then running out of memory during linking later. We have worked around both issues in libQtWebKit, which succeeds to build, and the same fixes could be applied to libwebkit. Volunteers are welcome :-) Some other packages are failing due to general Factory brokenness, like yast2 and its dependencies. Hopefully this will cleanup automatically, but to avoid running into non-arm-specific issues, I've written a script to ignore build errors that also happen on openSUSE:Factory. I guess I need to polish that a bit more and make it pretty print a webpage that people can refer to (not yet done). Third, I merged the bits we still need into gcc46 and submitted this to the devel project. Luckly it got accepted today, so while the overlay is still there, it hopefully can be removed completely as soon as that version hits Factory. Looking forward to that! Also, I noticed that some of the packages were branched for reasons that are no longer current, so I deleted them. Most prominent example is glibc. Note this triggers some rebuilds. to have a clean native build, I've triggered a complete rebuild in the internal copy of openSUSE:Factory:ARM that builds on native hardware (not on OBS). Hopefully we then find issues that we would otherwise also run into at some point in the future in OBS. OBS is currently far too slow to handle a complete rebuild, so I try to let it minimally rebuild only. I've also updated hwinfo(1) to work better with native and with qemu, and it is now good enough to pass yast2-hardware-detection testsuite, which means that we're one step closer to having yast2 building. 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] kiwi arm build
by Joop Boonen 20 Dec '11

20 Dec '11

Hi, I have been checking out the kiwi build (kiwi --debug --build suse-SLE12-JeOS --destdir /var/tmp/arm_JeoS.raw) on openSUSE. Most of it is OK. I've added a patch. It's also build in home:worldcitizen:armv7l kiwi . There are still a few issues in some packages (u-boot). I'm sending in a submit request for this. The kernel-omap2plus doesn't seem to support omapfb yet. I've also tested with the linaro Android 4.0 kernel. This one is OK it also has the omapfb and can be used with The kiwi patch is attached, it are basically configuration and spec file changes. Marcus can you please apply this one if you agree with it? Regards, Joop.

2 1

[opensuse-arm] New repos pushed out, debug packages seperated
by Adrian Schröter 19 Dec '11

19 Dec '11

JFYI, the new armv5 and v7 repos the OBS pushed out yesterday are using a new OBS feature. All the *-debug* packages are in their own repo beside the "standard" one. This is to reduce the meta data a lot in the standard repo, so not everybody has to download the large meta data amount. On the other hand, you have to add another repo now if you need -debug packages. bye adrian -- 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] Java related package build on ARM
by Dirk Müller 15 Dec '11

15 Dec '11

Hi, after we have bootstrapped java-1_6_0-openjdk, now most of the stuff is blocked by "ant-junit" (subpackage of ant-antlr). That one fails to build due to running OOM during building javadocs. I've quickly checked, and it seems building javadocs is not really necessary, as the tarball has already javadocs included. So we could skip that step, which already helps. It seems the spec file had a %build_javadocs define that is not really functional anymore (ant distribution includes ant javadocs, which is run unconditional, so the spec file actually builds javadocs twice I think). The alternative solution, which seems to work as well and reduces build differences is this small patch: --- build.xml +++ build.xml @@ -1358,7 +1358,7 @@ <target name="-javadocs.do" if="jdk1.5+" unless="javadoc.notrequired"> <mkdir dir="${build.javadocs}"/> <javadoc useexternalfile="yes" - maxmemory="1000M" + maxmemory="512M" destdir="${build.javadocs}" author="true" version="true" which finishes building javadocs target successfully after a chewing for 160 minutes under qemu (53 minutes on native hardware). Currently I went for this solution (patch is only applied on %arm), any comments, ideas appreciated. I guess it would help overall build speed by only building "ant jars " and maybe "ant test-jars" and not also javadocs? Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 6

[opensuse-arm] low-cost EOMA-PCMCIA CPU Card initiative (allwinner cortex a8)
by Luke Kenneth Casson Leighton 14 Dec '11

14 Dec '11

folks, hi, apologies for the wide distribution of this message, reasons will become clear: please do subscribe to arm-netbooks(a)lists.phcomp.co.uk and respond there (subscription required) rather than to all these lists. the short version of the story is that Rhombus Tech (a CIC company - not a not-for-profit or a Ltd Company) is now taking preorder committments - pledges - to buy EOMA-PCMCIA-compliant CPU cards using a low-cost but feature-rich ARM Cortex A8 CPU called the Allwinner A10. http://http://rhombus-tech.net//allwinner_a10/orders/ some bullet-points: * this initiative is similar to the openpandora, the openmoko, ben nanonote etc. except that the lessons have been learned from these projects, to keep it very very simple, low-risk and modular, but still functional and useful (to Software Libre Developers) as a module. the goal is also different in that the plan is to leverage mass-volume pricing and opportunities, to the direct benefit of the Software (Libre) Community. more info on http://rhombus-tech.net main page. * the A10 has (at least) HDMI, SATA-II, 10/100 Ethernet, takes up to 1gb of 800mhz DDR3 RAM, has a superb 32-bit-wide 8-way concurrent DMA-driven NAND Flash interface, MALI 400MP 3D Graphics, does 2160p (2x 1080p) Video, has 4 SD 3.0 Ultra-High-Speed interfaces, 2x 24-pin RGB/TTL LCD interfaces, IDE (PATA)... i'm repeating what's on the rhombus tech web site so will stop here (link below) * the price of the allwinner CPU is so low in mass-volume ($USD 7) that in mass-volume (100k pricing) a PCB that is comparable to the raspberrypi would only be $USD 15 instead of $25, yet the A10 would be 3x faster processing speed (the rbpi's CPU is only a 700mhz ARM11 yet is more expensive). * the CPU card will be able to operate as a stand-alone (USB-OTG powered) computer, with HDMI output, boot from Micro-SD, and stereo headphones/mic, yet due to EOMA-PCMCIA compliance it will plug into a wide range of future devices. * unlike the beagleboard, origen, IMX53QSB etc. this is not a SoC-fabless-semiconductor-company-driven or a Linaro-driven initiative, it is a commercial initiative with an absolute top priority focus on GPL compliance and involving Software (Libre) Developers every step of the way, hence the reason for using a CIC not a Ltd Company. * GPL Kernel Source code has been obtained from allwinner: RHT has the full support of allwinner's Board of Directors, and the Reference Platform source code is available on alioth.debian.org. * as the primary focus of this initiative is, at this stage, to invite Software (Libre) Developers to be involved, it has not been widely announced. this is therefore the 1st reason why these lists are specifically being contacted. * as the CPU cards are designed to be in legacy PCMCIA form-factor, motherboards and devices such as tablets, laptops, plug computers, NAS boxes, IPTVs, are all possible, including embedded and other industrial purposes. the only other thing is that we are actively seeking "Admins" for the Rhombus Tech web site, from a wide range of different communities. the responsibilities are very small - they're a bit like those of slashdot meta-moderation. primarily we need people to be able to vet sponsorship for receipt of developer boards, using the profits raised by the CIC, for the direct strategic benefit of the Software (Libre) Community. this is similar in effect to the beagleboard sponsorship programme, but unlike the beagleboard sponsorship programme, if sufficient profits are raised by the CIC it will be possible for Admins to decide to donate boards taking up the entire years' remaining profits in one go, to worthwhile causes. clearly, to find such people it is necessary to reach an appropriate audience, hence the 2nd reason why this message is going specifically to ARM lists in each of the major gnu/linux distros. there are at present 4 people who have agreed to be Admins, including phil hands, alain williams, wookey and james vasile, each in "unofficial" capacities with no relation to any other duties or roles that they fulfil. ideally we could do with one or two more from each of the other gnu/linux distros. lastly: there *is* the possibility of adapting something like the beaglebone, which would, if the AM3357 was used, mean that the resultant hardware could potentially be FSF-Hardware-Endorsed: if this is something of interest to you please do speak up (on the arm-netbook(a)lists.phcomp.co.uk list) or likewise if you would prefer any other "Open Schematics" board such as IMX53QSB, pandaboard etc. to be adapted please do say so. ok i'll leave it at that. it's worth repeating - discussion please contact me either privately, directly, or subscribe to arm-netbook(a)lists.phcomp.co.uk, list instructions below. many thanks. links here: EOMA-PCMCIA spec: http://www.elinux.org/Embedded_Open_Modular_Architecture/PCMCIA allwinner page: http://http://rhombus-tech.net//allwinner_a10/ preorders page: http://http://rhombus-tech.net//allwinner_a10/orders/ accidental slashdot article: http://goo.gl/M7YQH rhombus-tech web site: http://rhombus-tech.net arm-netbooks: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook beaglebone idea: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/001155.html am335x page: http://rhombus-tech.net/am335x -- 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] Workaround for bash breakage
by Dirk Müller 14 Dec '11

14 Dec '11

Hi, I've added a bash overlay in openSUSE:Factory:ARM which reverts this change: ------------------------------------------------------------------- Fri Nov 18 12:03:56 UTC 2011 - werner(a)suse.de - Enforce bind references to global function symbols to the definition within libreadline As that solves the issue with bash not really being able to handle backspace and other things, which makes arm based Factory installations somewhat useable again. I believe this avoids that "stdout" symbol is bound to the same instance in bash and libreadline, which seems to cause the issue. I don't really know why yet, so I have not yet submitted this back to Werner. JFYI 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] Extended "Native build" farm by pandaboards
by Dirk Müller 06 Dec '11

06 Dec '11

Hi, Just a short status update.. Over the last few days, we've been extending the internal copy (that does not build inside qemu but natively) with additional pandaboards in addition to the EfikaMX based hosts. Currently I'm reasonably positive that we can get the remaining packages that currently fail emulated build to be build on native hardware, and hopefully within the near future make the native build platform available to the outside as well. Below the picture from my desk :-) Greetings, Dirk

1 0

[opensuse-arm] ARM status
by Alexander Graf 03 Dec '11

03 Dec '11

Hi guys, It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :). *** We can successfully build ~3500 out of ~4700 Factory packages! *** Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :). Also, there are a couple of things we have now that weren't there before: * Lots of qemu fixes to get stuff building * Kernel rpms so we can generate kernels for the following flavors: default, tegra, omap2plus (Pandaboard), imx51 (EFIKA MX) * Build fixes for a number of packages (otherwise we wouldn't get 3.5k!) * U-boot package for pandaboard (thanks Joop!) * Probably a lot of stuff I can't remember atm. If you have worked on something and want to add it to the list, please reply to this mail so we have more overview :). So what is still missing from here? Well, these are the pieces I'm tracking right now: * Kiwi support (Marcus is on it!) * Kernel testing and making-it-work [1] * Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages * hwinfo probably needs some love for ARM * yast2 could use some love as well :) * X drivers are probably still missing * Fixing broken packages, there are still a few that are not broken because of exception handling :) [1] To handle exceptions we need to be able to unwind state at certain points in the code. This unwinding requires special tables which are different on ARM than on any other platform out there. Now the problem is that even a program as simple as: #include <stdio.h> int main(int argc, char **argv) { try { throw -1; } catch (int) { fprintf(stderr, "We caught an exception of type int\n"); } } fails to execute on our current builds. Thus gmp and gcj don't build properly and everything depending on Java just doesn't even get built. I'm trying to reproduce this with Linaro's gcc to maybe get some help from them. Once we have that, the kernel might end up working and we should have an almost-completely-built distro (no guarantees for actually working code). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 19

Re: [opensuse-arm] ARM status
by Joop Boonen 29 Nov '11

29 Nov '11

On Sun, November 27, 2011 8:35 pm, Alexander Graf wrote: > > On 27.11.2011, at 20:17, Tomas Cech wrote: > >> On Thu, Nov 24, 2011 at 04:53:36PM +0100, Alexander Graf wrote: >>> Hi guys, >>> >>> It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :). >>> >>> *** We can successfully build ~3500 out of ~4700 Factory packages! *** >>> >> >> I'm still not able to find, where is the right project with armv7l failing packages, could somebody send link? >> >> This one >> https://build.opensuse.org/project/monitor?commit=Filter%3A&failed=1&pkgnam… (which can be found on http://en.opensuse.org/Portal:ARM) doesn't show any armv7l packages... > > Ah, sorry, I fixed the link on the wiki now :). Basically your portal to any interesting information is at > > https://build.opensuse.org/project/show?project=openSUSE:Factory:ARM > >> >>> Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :). >> >> If it is worth of effort, I can set up that new Efika MX as OBS worker (if someone help me - prusnak or miska probably already have >> experience with this). I would just disable it when I'm trying to fix or test something. > > Yes, please :). Adrian probably has a pretty clear idea on what's required to get this rolling. > >> >>> So what is still missing from here? Well, these are the pieces I'm tracking right now: >>> >>> * Kiwi support (Marcus is on it!) >>> * Kernel testing and making-it-work [1] >> >> I think/hope that I can help a bit here. > > I got the pandaboard kernel reasonably well working now, so if you could tackle the i.MX51 one, I would very much appreciate it :). > >> >>> * Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages >>> * hwinfo probably needs some love for ARM >>> * yast2 could use some love as well :) >>> * X drivers are probably still missing >>> * Fixing broken packages, there are still a few that are not broken because of exception handling :) >> And with this hopefully too. > > There are a couple of generic broken ones thanks to the recent ncurses changes in factory. I'm still puzzled why bash doesn't compile anymore for example - it's definitely related to the curses change. I assume this is the problem, see buildlog ( https://build.opensuse.org/package/rawlog?arch=armv7l&package=bash&project=… and https://build.opensuse.org/package/rawlog?arch=armv5el&package=bash&project…) : <armv5el> checking whether gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2 -L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2 needs -traditional... no checking for tgetent... no checking for tgetent in -ltermcap... no checking for tgetent in -ltinfo... no checking for tgetent in -lcurses... no checking for tgetent in -lncurses... yes checking which library has the termcap functions... using libncurses </armv5el> <armv7l> checking whether gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2 -L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2 needs -traditional... no checking for tgetent... no checking for tgetent in -ltermcap... yes checking which library has the termcap functions... using libtermcap </armv7l> > > Then there are a number of packages that complain in thumb mode "swp" instructions. However, swp is not guaranteed by the armv7 architecture anymore, so if there's old thumb code somewhere which gets triggered by our build, you see those swp errors. The easy fix is to just disable thumb for that package. Just check texlive-bin on how that works :). > > > Alex > > 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 4

[opensuse-arm] [PATCH] Add support for ST-Ericsson U8500 NovaThor
by Andrew Wafaa 24 Nov '11

24 Nov '11

Attached patch provides support for ST-Ericsson's U8500 NovaThor as found in the Snowball board. It compiles and builds fine, but I have yet to run it (awaiting receipt of board). Regards, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F

3 5

[opensuse-arm] Re: [PATCH] Re: [opensuse-kernel] arm config
by Alexander Graf 24 Nov '11

24 Nov '11

On 22.11.2011, at 15:47, Andrew Wafaa wrote: > On Mon, 2011-11-14 at 11:54 +0100, Adrian Schröter wrote: >> Am Montag, 14. November 2011, 10:19:54 schrieb Andrew Wafaa: >>> On Mon, 2011-11-14 at 11:03 +0100, Michal Marek wrote: >>>> On 14.11.2011 10:26, Adrian Schröter wrote: >>>>> Am Montag, 14. November 2011, 10:06:14 schrieb Michal Marek: >>>>>> On 14.11.2011 09:08, Adrian Schröter wrote: >>>>>>> - initial armv7l default kernel config, everything >>>>>>> enable except >>>>>>> the non compiling modules - makeing arm configs again >>>>>>> armvX >>>>>>> specific >>>>>> >>>>>> If the configs are to be placed under config/armvX, then you're >>>>>> missing a change to rpm/arch-symbols. >>>>> >>>>> No, I did not miss it, I reverted it. >>>> >>>> Not in the patch you posted. And you additionally need to modify >>>> ./rpm/arch-symbols --list to list all the arm families. >> >> sorry, missed this in my local git. Fixed version attached. >> >>>>> There is no way to have a single config for armv5 and armv7 IMHO. >>> >>> Correct. It may be possible when armv8 is released in a couple of years, >>> but having spoken in depth with Linaro who are trying to clean up this >>> area, they said it is a slow and often painful process but they are >>> making some progress. >>> >>>>>> Also, are you talking to Andrew, who has >>>>>> been working on more or less the same lately? >>>>> >>>>> I had contact but never saw any patch. AFAIK he only works on >>>>> specific kernels for specific hardware (which would also be armvX >>>>> specific), while this kernel is supposed to be as near as possible >>>>> to the standard SUSE kernel.> >>>> The latest patch he posted is at >>>> http://lists.opensuse.org/opensuse-kernel/2011-11/msg00024.html. >>> >>> Are you saying you want %arm = armv7l or are you saying something else? >> >> %arm is "armv5tel armv7l armv8l ...." >> >>> At present I have all the arm configs in config/arm/, which would build >>> on armv7l. Should we add any armv5 devices they would also live in >>> there. I'm not sure that the -default kernel would actually run on any >>> hardware, so it would be isolated to qemu really wouldn't it? >> >> I think we need to split this again into >> >> config/armv5tel >> config/armv7l >> config/armv8l >> >> what allows us to have a kernel packages with same name but different config. >> > > I've rebased my patch according to Adrian's request to have a separate > armv* config. All build fine, although I haven't tested - still trying > to workout how best to do this, any hints? Thanks, I applied your and Adrian's patches and sat down to refine configs so they actually build properly. We now have 4 flavors: - default (QEMU?) - imx51 (EFIKA) - tegra2 - omap (pandaboard) I have verified that I could barely boot the omap kernel on a pandaboard. I did however get the weird kernel messages I sent out to the ARM list earlier. But that's a separate issue - at least we have something to base on now. So if you have an ARMv7 box and you want to have openSUSE running on it, please check if the kernels actually work for you. I'm pretty sure we did some config pieces wrong at random points :) Also, we have a new build requirement for ARM: mkimage. There is a package on its way to Factory called u-boot-tools which contains mkimage. We need this to convert the zImages to uImages which u-boot can boot off of. But since it's covered by %if %arm we should be fine until it actually hits Factory :). 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] ARM kernel on pandaboard
by Alexander Graf 23 Nov '11

23 Nov '11

Hi guys, I just tried to boot a 3.2 opensuse kernel based on Andrew's omap2plus kernel config on a pandaboard and got something that partially works. Please see below for the details. The thing that makes me the most curious is the unwind message that is thrown all over the place. Does anyone know what's going on there? Alex PANDA # bootm 0x80300000 ## Booting image at 80300000 ... Image Name: Linux-3.2.0-rc2-0-omap2plus Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3358448 Bytes = 3.2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. d instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] PERCPU: Embedded 8 pages/cpu @c0fbc000 s10208 r8192 d14368 u32768 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 117602 [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rw mem=463M console=ttyO2,115200n8 earlyprintk [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] Memory: 463MB = 463MB total [ 0.000000] Memory: 457544k/457544k available, 16568k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xdd000000 - 0xf8000000 ( 432 MB) [ 0.000000] lowmem : 0xc0000000 - 0xdcf00000 ( 463 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc05e7e60 (6016 kB) [ 0.000000] .init : 0xc05e8000 - 0xc06347e0 ( 306 kB) [ 0.000000] .data : 0xc0636000 - 0xc06bd2d0 ( 541 kB) [ 0.000000] .bss : 0xc06bd2f4 - 0xc0c13dc0 (5467 kB) [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] Hierarchical RCU implementation. [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandl000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] NR_IRQS:410 [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.000000] unwind: Unhandled instruction fc [ 0.000000] unwind: Unhandled instruction fc [ 0.000976] Calibrating delay loop... [ 0.007751] unwind: Unhandled instruction fc [ 0.007781] unwind: Unhandled instruction fc [ 0.007843] unwind: Unhandled instruction fc [ 0.007904] unwind: Unhandled instruction fc [ 0.062408] 2007.19 BogoMIPS (lpj=7839744) [ 0.062469] pid_max: default: 32768 minimum: 301 [ 0.062561] unwind: Unhandled instruction fc [ 0.062561] unwind: Unhandled instruction fc [ 0.062622] unwind: Unhandled instruction fc [ 0.063079] unwind: Unhandled instruction fc [ 0.063110] unwind: Unhandled instruction fc [ 0.063110] unwind: Unhandled instruction fc [ 0.063293] Security Framework initialized [ 0.063568] Mount-cache hash table entries: 512 [ 0.063781] unwind: Unhandled instruction fc [ 0.063812] unwind: Unhandled instruction fc [ 0.063842] unwind: Unhandled instruction fc [ 0.063903] unwind: Unhandled instruction fc [ 0.063995] unwind: Unhandled instruction fc [ 0.063995] unwind: Unhandled instruction fc [ 0.064025] unwind: Unhandled instruction fc [ 0.064056] unwind: Unhandled instruction fc [ 0.064147] unwind: Unhandled instruction fc [ 0.064147] unwind: Unhandled instruction fc [ 0.064178] unwind: Unhandled instruction fc [ 0.064178] unwind: Unhandled instruction fc [ 0.064208] unwind: Unhandled instruction fc [ 0.064208] unwind: Unhandled instruction fc [ 0.064270] unwind: Unhandled instruction fc [ 0.064300] unwind: Unhandled instruction fc [ 0.064300] unwind: Unhandled instruction fc [ 0.064331] unwind: Unhandled instruction fc [ 0.064331] unwind: Unhandled instruction fc [ 0.064392] unwind: Unhandled instruction fc [ 0.064422] unwind: Unhandled instruction fc [ 0.064422] unwind: Unhandled instruction fc [ 0.064453] unwind: Unhandled instruction fc [ 0.064544] unwind: Unhandled instruction fc [ 0.064575] unwind: Unhandled instruction fc [ 0.064575] unwind: Unhandled instruction fc [ 0.064605] unwind: Unhandled instruction fc [ 0.064636] unwind: Unhandled instruction fc [ 0.064666] unwind: Unhandled instruction fc [ 0.064697] unwind: Unhandled instruction fc [ 0.064697] unwind: Unhandled instruction fc [ 0.064727] unwind: Unhandled instruction fc [ 0.064758] unwind: Unhandled instruction fc [ 0.064758] unwind: Unhandled instruction fc [ 0.064788] unwind: Unhandled instruction fc [ 0.064819] unwind: Unhandled instruction fc [ 0.064849] unwind: Unhandled instruction fc [ 0.064849] unwind: Unhandled instruction fc [ 0.064849] unwind: Unhandled instruction fc [ 0.064880] unwind: Unhandled instruction fc [ 0.064910] unwind: Unhandled instruction fc [ 0.064910] unwind: Unhandled instruction fc [ 0.064941] unwind: Unhandled instruction fc [ 0.064941] unwind: Unhandled instruction fc [ 0.064971] unwind: Unhandled instruction fc [ 0.064971] unwind: Unhandled instruction fc [ 0.065032] unwind: Unhandled instruction fc [ 0.065155] unwind: Unhandled instruction fc [ 0.065185] unwind: Unhandled instruction fc [ 0.065185] unwind: Unhandled instruction fc [ 0.065216] unwind: Unhandled instruction fc [ 0.065246] unwind: Unhandled instruction fc [ 0.065246] unwind: Unhandled instruction fc [ 0.065277] unwind: Unhandled instruction fc [ 0.065277] unwind: Unhandled instruction fc [ 0.065307] unwind: Unhandled instruction fc [ 0.065338] unwind: Unhandled instruction fc [ 0.065399] unwind: Unhandled instruction fc [ 0.065429] unwind: Unhandled instruction fc [ 0.065460] unwind: Unhandled instruction fc [ 0.065460] unwind: Unhandled instruction fc [ 0.065490] unwind: Unhandled instruction fc [ 0.065490] unwind: Unhandled instruction fc [ 0.065612] unwind: Unhandled instruction fc [ 0.065612] unwind: Unhandled instruction fc [ 0.065643] unwind: Unhandled instruction fc [ 0.065673] unwind: Unhandled instruction fc [ 0.065673] unwind: Unhandled instruction fc [ 0.065887] unwind: Unhandled instruction fc [ 0.065917] unwind: Unhandled instruction fc [ 0.066040] unwind: Unhandled instruction fc [ 0.066070] unwind: Unhandled instruction fc [ 0.066101] unwind: Unhandled instruction fc [ 0.066101] unwind: Unhandled instruction fc [ 0.066162] unwind: Unhandled instruction fc [ 0.066223] unwind: Unhandled instruction fc [ 0.066253] unwind: Unhandled instruction fc [ 0.066284] unwind: Unhandled instruction fc [ 0.066345] unwind: Unhandled instruction fc [ 0.066345] unwind: Unhandled instruction fc [ 0.066375] unwind: Unhandled instruction fc [ 0.066375] unwind: Unhandled instruction fc [ 0.066406] unwind: Unhandled instruction fc [ 0.066467] unwind: Unhandled instruction fc [ 0.066467] unwind: Unhandled instruction fc [ 0.066528] unwind: Unhandled instruction fc [ 0.066558] unwind: Unhandled instruction fc [ 0.066558] unwind: Unhandled instruction fc [ 0.066589] unwind: Unhandled instruction fc [ 0.066864] unwind: Unhandled instruction fc [ 0.066894] unwind: Unhandled instruction fc [ 0.066925] unwind: Unhandled instruction fc [ 0.066955] unwind: Unhandled instruction fc [ 0.066986] unwind: Unhandled instruction fc [ 0.067047] unwind: Unhandled instruction fc [ 0.067077] unwind: Unhandled instruction fc [ 0.067108] unwind: Unhandled instruction fc [ 0.067138] unwind: Unhandled instruction fc [ 0.067260] unwind: Unhandled instruction fc [ 0.067260] unwind: Unhandled instruction fc [ 0.067291] unwind: Unhandled instruction fc [ 0.067321] unwind: Unhandled instruction fc [ 0.067321] unwind: Unhandled instruction fc [ 0.067382] unwind: Unhandled instruction fc [ 0.067413] unwind: Unhandled instruction fc [ 0.067901] unwind: Unhandled instruction fc [ 0.067932] unwind: Unhandled instruction fc [ 0.067932] unwind: Unhandled instruction fc [ 0.067962] unwind: Unhandled instruction fc [ 0.068023] unwind: Unhandled instruction fc [ 0.068084] unwind: Unhandled instruction fc [ 0.068115] unwind: Unhandled instruction fc [ 0.068145] unwind: Unhandled instruction fc [ 0.068176] unwind: Unhandled instruction fc [ 0.068206] unwind: Unhandled instruction fc [ 0.068298] unwind: Unhandled instruction fc [ 0.068328] unwind: Unhandled instruction fc [ 0.068359] unwind: Unhandled instruction fc [ 0.068359] unwind: Unhandled instruction fc [ 0.068420] unwind: Unhandled instruction fc [ 0.068450] unwind: Unhandled instruction fc [ 0.068481] unwind: Unhandled instruction fc [ 0.068542] unwind: Unhandled instruction fc [ 0.068572] unwind: Unhandled instruction fc [ 0.068572] unwind: Unhandled instruction fc [ 0.068634] unwind: Unhandled instruction fc [ 0.068725] unwind: Unhandled instruction fc [ 0.068756] unwind: Unhandled instruction fc [ 0.068756] unwind: Unhandled instruction fc [ 0.068786] unwind: Unhandled instruction fc [ 0.068878] unwind: Unhandled instruction fc [ 0.068878] unwind: Unhandled instruction fc [ 0.068908] unwind: Unhandled instruction fc [ 0.068939] unwind: Unhandled instruction fc [ 0.068969] unwind: Unhandled instruction fc [ 0.069000] unwind: Unhandled instruction fc [ 0.069030] unwind: Unhandled instruction fc [ 0.069183] unwind: Unhandled instruction fc [ 0.069183] unwind: Unhandled instruction fc [ 0.069396] unwind: Unhandled instruction fc [ 0.069458] unwind: Unhandled instruction fc [ 0.069488] unwind: Unhandled instruction fc [ 0.069488] unwind: Unhandled instruction fc [ 0.069519] unwind: Unhandled instruction fc [ 0.069641] CPU: Testing write buffer coherency: [ 0.069702] unwind: Unhandled instruction fc [ 0.069732] unwind: Unhandled instruction fc [ 0.069732] unwind: Unhandled instruction fc [ 0.069763] unwind: Unhandled instruction fc [ 0.069793] unwind: Unhandled instruction fc [ 0.069793] unwind: Unhandled instruction fc [ 0.069854] unwind: Unhandled instruction fc [ 0.069854] unwind: Unhandled instruction fc [ 0.069885] unwind: Unhandled instruction fc [ 0.069946] ok [ 0.070098] unwind: Unhandled instruction fc [ 0.070129] unwind: Unhandled instruction fc [ 0.070159] unwind: Unhandled instruction fc [ 0.070220] unwind: Unhandled instruction fc [ 0.070404] unwind: Unhandled instruction fc [ 0.070434] unwind: Unhandled instruction fc [ 0.070434] unwind: Unhandled instruction fc [ 0.070556] unwind: Unhandled instruction fc [ 0.070617] unwind: Unhandled instruction fc [ 0.070648] unwind: Unhandled instruction fc [ 0.070678] unwind: Unhandled instruction fc [ 0.070739] unwind: Unhandled instruction fc [ 0.071014] unwind: Unhandled instruction fc [ 0.071105] unwind: Unhandled instruction fc [ 0.071136] unwind: Unhandled instruction fc [ 0.071136] unwind: Unhandled instruction fc [ 0.071197] unwind: Unhandled instruction fc [ 0.071258] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.071350] Calibrating local timer... 491.31MHz. [ 0.117370] L310 cache controller enabled [ 0.117401] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B [ 0.117492] unwind: Unhandled instruction fc [ 0.117492] unwind: Unhandled instruction fc [ 0.117492] unwind: Unhandled instruction fc [ 0.117553] unwind: Unhandled instruction fc [ 0.117706] unwind: Unhandled instruction fc [ 0.117736] unwind: Unhandled instruction fc [ 0.117828] unwind: Unhandled instruction fc [ 0.117858] unwind: Unhandled instruction fc [ 0.117858] unwind: Unhandled instruction fc [ 0.118011] unwind: Unhandled instruction fc [ 0.118194] unwind: Unhandled instruction fc [ 0.118194] unwind: Unhandled instruction fc [ 0.118194] unwind: Unhandled instruction fc [ 0.118377] unwind: Unhandled instruction fc [ 0.118469] unwind: Unhandled instruction fc [ 0.118469] unwind: Unhandled instruction fc [ 0.118469] unwind: Unhandled instruction fc [ 0.118499] unwind: Unhandled instruction fc [ 0.118499] unwind: Unhandled instruction fc [ 0.118530] unwind: Unhandled instruction fc [ 0.118530] unwind: Unhandled instruction fc [ 0.118530] unwind: Unhandled instruction fc [ 0.118560] unwind: Unhandled instruction fc [ 0.118560] unwind: Unhandled instruction fc [ 0.118591] unwind: Unhandled instruction fc [ 0.118682] unwind: Unhandled instruction fc [ 0.118713] unwind: Unhandled instruction fc [ 0.118713] unwind: Unhandled instruction fc [ 0.118743] unwind: Unhandled instruction fc [ 0.118774] unwind: Unhandled instruction fc [ 0.118865] unwind: Unhandled instruction fc [ 0.118896] unwind: Unhandled instruction fc [ 0.118896] unwind: Unhandled instruction fc [ 0.118927] unwind: Unhandled instruction fc [ 0.118957] unwind: Unhandled instruction fc [ 0.119415] unwind: Unhandled instruction fc [ 0.119445] unwind: Unhandled instruction fc [ 0.119445] unwind: Unhandled instruction fc [ 0.119476] unwind: Unhandled instruction fc [ 0.119476] unwind: Unhandled instruction fc [ 0.119506] unwind: Unhandled instruction fc [ 0.119537] unwind: Unhandled instruction fc [ 0.119598] unwind: Unhandled instruction fc [ 0.119628] unwind: Unhandled instruction fc [ 0.119628] unwind: Unhandled instruction fc [ 0.119628] unwind: Unhandled instruction fc [ 0.119659] unwind: Unhandled instruction fc [ 0.119659] unwind: Unhandled instruction fc [ 0.120239] CPU1: Booted secondary processor [ 0.185913] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.185943] CPU1: Unknown IPI message 0x1 [ 0.185974] unwind: Unhandled instruction fc [ 0.185974] unwind: Unhandled instruction fc [ 0.185974] unwind: Unhandled instruction fc [ 0.186004] unwind: Unhandled instruction fc [ 0.186035] unwind: Unhandled instruction fc [ 0.186065] unwind: Unhandled instruction fc [ 0.186065] Brought up 2 CPUs [ 0.186096] SMP: Total of 2 processors activated (3972.37 BogoMIPS). [ 0.186096] unwind: Unhandled instruction fc [ 0.186096] unwind: Unhandled instruction fc [ 0.186126] unwind: Unhandled instruction fc [ 0.186126] unwind: Unhandled instruction fc [ 0.186157] unwind: Unhandled instruction fc [ 0.186187] unwind: Unhandled instruction fc [ 0.186218] unwind: Unhandled instruction fc [ 0.186248] unwind: Unhandled instruction fc [ 0.186279] unwind: Unhandled instruction fc [ 0.186309] unwind: Unhandled instruction fc [ 0.186309] unwind: Unhandled instruction fc [ 0.186370] unwind: Unhandled instruction fc [ 0.186370] unwind: Unhandled instruction fc [ 0.186401] unwind: Unhandled instruction fc [ 0.186401] unwind: Unhandled instruction fc [ 0.186676] unwind: Unhandled instruction fc [ 0.186676] unwind: Unhandled instruction fc [ 0.186767] unwind: Unhandled instruction fc [ 0.186767] unwind: Unhandled instruction fc [ 0.186798] unwind: Unhandled instruction fc [ 0.186798] unwind: Unhandled instruction fc [ 0.186828] unwind: Unhandled instruction fc [ 0.186859] unwind: Unhandled instruction fc [ 0.186889] unwind: Unhandled instruction fc [ 0.186889] unwind: Unhandled instruction fc [ 0.186889] unwind: Unhandled instruction fc [ 0.186920] unwind: Unhandled instruction fc [ 0.186950] unwind: Unhandled instruction fc [ 0.186950] unwind: Unhandled instruction fc [ 0.187011] unwind: Unhandled instruction fc [ 0.187011] unwind: Unhandled instruction fc [ 0.187011] unwind: Unhandled instruction fc [ 0.187042] unwind: Unhandled instruction fc [ 0.187042] unwind: Unhandled instruction fc [ 0.187072] unwind: Unhandled instruction fc [ 0.187072] unwind: Unhandled instruction fc [ 0.187164] unwind: Unhandled instruction fc [ 0.187194] unwind: Unhandled instruction fc [ 0.187225] unwind: Unhandled instruction fc [ 0.187225] unwind: Unhandled instruction fc [ 0.187286] unwind: Unhandled instruction fc [ 0.187286] unwind: Unhandled instruction fc [ 0.187316] unwind: Unhandled instruction fc [ 0.187316] unwind: Unhandled instruction fc [ 0.187316] unwind: Unhandled instruction fc [ 0.187347] unwind: Unhandled instruction fc [ 0.187347] unwind: Unhandled instruction fc [ 0.187377] unwind: Unhandled instruction fc [ 0.187408] unwind: Unhandled instruction fc [ 0.187408] unwind: Unhandled instruction fc [ 0.187408] unwind: Unhandled instruction fc [ 0.187438] unwind: Unhandled instruction fc [ 0.187438] unwind: Unhandled instruction fc [ 0.187469] unwind: Unhandled instruction fc [ 0.193725] unwind: Unhandled instruction fc [ 0.193756] unwind: Unhandled instruction fc [ 0.193756] unwind: Unhandled instruction fc [ 0.193756] unwind: Unhandled instruction fc [ 0.193786] unwind: Unhandled instruction fc [ 0.194030] unwind: Unhandled instruction fc [ 0.194030] unwind: Unhandled instruction fc [ 0.194274] omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck. [ 0.197387] omap_hwmod: dmm: _wait_target_disable failed [ 0.199920] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.202453] omap_hwmod: l3_instr: _wait_target_disable failed [ 0.204986] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.207519] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.210083] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.212615] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.215148] omap_hwmod: l4_per: _wait_target_disable failed [ 0.218200] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.220733] omap_hwmod: dma_system: _wait_target_disable failed [ 0.223327] omap_hwmod: dss_core: _wait_target_disable failed [ 0.225891] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.228424] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.230957] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.233489] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.236053] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.238586] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.242309] omap_hwmod: mailbox: _wait_target_disable failed [ 0.244903] omap_hwmod: mcpdm: cannot be enabled (3) [ 0.247650] omap_hwmod: spinlock: _wait_target_disable failed [ 0.249023] unwind: Unhandled instruction fc [ 0.249023] unwind: Unhandled instruction fc [ 0.249023] unwind: Unhandled instruction fc [ 0.249114] unwind: Unhandled instruction fc [ 0.249145] unwind: Unhandled instruction fc [ 0.249206] unwind: Unhandled instruction fc [ 0.249206] unwind: Unhandled instruction fc [ 0.249206] unwind: Unhandled instruction fc [ 0.249298] unwind: Unhandled instruction fc [ 0.249298] unwind: Unhandled instruction fc [ 0.249298] unwind: Unhandled instruction fc [ 0.249389] unwind: Unhandled instruction fc [ 0.249511] unwind: Unhandled instruction fc [ 0.249542] unwind: Unhandled instruction fc [ 0.249542] unwind: Unhandled instruction fc [ 0.249542] unwind: Unhandled instruction fc [ 0.249572] unwind: Unhandled instruction fc [ 0.249572] unwind: Unhandled instruction fc [ 0.249572] unwind: Unhandled instruction fc [ 0.249603] unwind: Unhandled instruction fc [ 0.249603] unwind: Unhandled instruction fc [ 0.249603] unwind: Unhandled instruction fc [ 0.249633] unwind: Unhandled instruction fc [ 0.249664] unwind: Unhandled instruction fc [ 0.249664] unwind: Unhandled instruction fc [ 0.249664] unwind: Unhandled instruction fc [ 0.249694] unwind: Unhandled instruction fc [ 0.249694] unwind: Unhandled instruction fc [ 0.249725] unwind: Unhandled instruction fc [ 0.249755] unwind: Unhandled instruction fc [ 0.249786] unwind: Unhandled instruction fc [ 0.249786] unwind: Unhandled instruction fc [ 0.249816] unwind: Unhandled instruction fc [ 0.249847] unwind: Unhandled instruction fc [ 0.249847] unwind: Unhandled instruction fc [ 0.249877] unwind: Unhandled instruction fc [ 0.249877] unwind: Unhandled instruction fc [ 0.249877] unwind: Unhandled instruction fc [ 0.249908] unwind: Unhandled instruction fc [ 0.249908] unwind: Unhandled instruction fc [ 0.249938] unwind: Unhandled instruction fc [ 0.249938] unwind: Unhandled instruction fc [ 0.249938] unwind: Unhandled instruction fc [ 0.249969] unwind: Unhandled instruction fc [ 0.249969] unwind: Unhandled instruction fc [ 0.249999] unwind: Unhandled instruction fc [ 0.249999] unwind: Unhandled instruction fc [ 0.250030] unwind: Unhandled instruction fc [ 0.250061] unwind: Unhandled instruction fc [ 0.250061] unwind: Unhandled instruction fc [ 0.250061] unwind: Unhandled instruction fc [ 0.250061] unwind: Unhandled instruction fc [ 0.250091] unwind: Unhandled instruction fc [ 0.250091] unwind: Unhandled instruction fc [ 0.250122] unwind: Unhandled instruction fc [ 0.250122] unwind: Unhandled instruction fc [ 0.250152] unwind: Unhandled instruction fc [ 0.250183] unwind: Unhandled instruction fc [ 0.250213] unwind: Unhandled instruction fc [ 0.250213] unwind: Unhandled instruction fc [ 0.250244] unwind: Unhandled instruction fc [ 0.250244] unwind: Unhandled instruction fc [ 0.250274] unwind: Unhandled instruction fc [ 0.250274] unwind: Unhandled instruction fc [ 0.250274] unwind: Unhandled instruction fc [ 0.250305] unwind: Unhandled instruction fc [ 0.250305] unwind: Unhandled instruction fc [ 0.250305] unwind: Unhandled instruction fc [ 0.250366] unwind: Unhandled instruction fc [ 0.250366] unwind: Unhandled instruction fc [ 0.250396] unwind: Unhandled instruction fc [ 0.250396] unwind: Unhandled instruction fc [ 0.250396] unwind: Unhandled instruction fc [ 0.250427] unwind: Unhandled instruction fc [ 0.250427] unwind: Unhandled instruction fc [ 0.250427] unwind: Unhandled instruction fc [ 0.250457] unwind: Unhandled instruction fc [ 0.250488] unwind: Unhandled instruction fc [ 0.250488] unwind: Unhandled instruction fc [ 0.250518] unwind: Unhandled instruction fc [ 0.250518] unwind: Unhandled instruction fc [ 0.250518] unwind: Unhandled instruction fc [ 0.250549] unwind: Unhandled instruction fc [ 0.250549] unwind: Unhandled instruction fc [ 0.250579] unwind: Unhandled instruction fc [ 0.250579] unwind: Unhandled instruction fc [ 0.250579] unwind: Unhandled instruction fc [ 0.250610] unwind: Unhandled instruction fc [ 0.250610] unwind: Unhandled instruction fc [ 0.250640] unwind: Unhandled instruction fc [ 0.250640] unwind: Unhandled instruction fc [ 0.250640] unwind: Unhandled instruction fc [ 0.250671] unwind: Unhandled instruction fc [ 0.250671] unwind: Unhandled instruction fc [ 0.250701] unwind: Unhandled instruction fc [ 0.250762] unwind: Unhandled instruction fc [ 0.250793] unwind: Unhandled instruction fc [ 0.250793] unwind: Unhandled instruction fc [ 0.250854] unwind: Unhandled instruction fc [ 0.250854] unwind: Unhandled instruction fc [ 0.250885] unwind: Unhandled instruction fc [ 0.250885] unwind: Unhandled instruction fc [ 0.251098] unwind: Unhandled instruction fc [ 0.251098] unwind: Unhandled instruction fc [ 0.251129] unwind: Unhandled instruction fc [ 0.251129] unwind: Unhandled instruction fc [ 0.251190] unwind: Unhandled instruction fc [ 0.251190] unwind: Unhandled instruction fc [ 0.251220] unwind: Unhandled instruction fc [ 0.251220] unwind: Unhandled instruction fc [ 0.251251] unwind: Unhandled instruction fc [ 0.251281] unwind: Unhandled instruction fc [ 0.251281] unwind: Unhandled instruction fc [ 0.251281] unwind: Unhandled instruction fc [ 0.251312] unwind: Unhandled instruction fc [ 0.251312] unwind: Unhandled instruction fc [ 0.251342] unwind: Unhandled instruction fc [ 0.251342] unwind: Unhandled instruction fc [ 0.251373] unwind: Unhandled instruction fc [ 0.251373] unwind: Unhandled instruction fc [ 0.251403] unwind: Unhandled instruction fc [ 0.251403] unwind: Unhandled instruction fc [ 0.251403] unwind: Unhandled instruction fc [ 0.251434] unwind: Unhandled instruction fc [ 0.251434] unwind: Unhandled instruction fc [ 0.251464] unwind: Unhandled instruction fc [ 0.251464] unwind: Unhandled instruction fc [ 0.251495] unwind: Unhandled instruction fc [ 0.251495] unwind: Unhandled instruction fc [ 0.251556] unwind: Unhandled instruction fc [ 0.251586] unwind: Unhandled instruction fc [ 0.251617] unwind: Unhandled instruction fc [ 0.251647] unwind: Unhandled instruction fc [ 0.251647] unwind: Unhandled instruction fc [ 0.251678] unwind: Unhandled instruction fc [ 0.251708] unwind: Unhandled instruction fc [ 0.251861] unwind: Unhandled instruction fc [ 0.251892] unwind: Unhandled instruction fc [ 0.251892] unwind: Unhandled instruction fc [ 0.251922] unwind: Unhandled instruction fc [ 0.251922] unwind: Unhandled instruction fc [ 0.251922] unwind: Unhandled instruction fc [ 0.251953] unwind: Unhandled instruction fc [ 0.251953] unwind: Unhandled instruction fc [ 0.251983] unwind: Unhandled instruction fc [ 0.251983] unwind: Unhandled instruction fc [ 0.251983] print_constraints: dummy: [ 0.252014] unwind: Unhandled instruction fc [ 0.252014] unwind: Unhandled instruction fc [ 0.252105] unwind: Unhandled instruction fc [ 0.252166] unwind: Unhandled instruction fc [ 0.252166] unwind: Unhandled instruction fc [ 0.252532] unwind: Unhandled instruction fc [ 0.252532] unwind: Unhandled instruction fc [ 0.252563] unwind: Unhandled instruction fc [ 0.252563] unwind: Unhandled instruction fc [ 0.252593] unwind: Unhandled instruction fc [ 0.252624] unwind: Unhandled instruction fc [ 0.252624] unwind: Unhandled instruction fc [ 0.252655] unwind: Unhandled instruction fc [ 0.252655] unwind: Unhandled instruction fc [ 0.252685] unwind: Unhandled instruction fc [ 0.252716] unwind: Unhandled instruction fc [ 0.252716] unwind: Unhandled instruction fc [ 0.252716] unwind: Unhandled instruction fc [ 0.252746] unwind: Unhandled instruction fc [ 0.252746] unwind: Unhandled instruction fc [ 0.252746] unwind: Unhandled instruction fc [ 0.252838] unwind: Unhandled instruction fc [ 0.252838] unwind: Unhandled instruction fc [ 0.252868] unwind: Unhandled instruction fc [ 0.252899] unwind: Unhandled instruction fc [ 0.252929] unwind: Unhandled instruction fc [ 0.252929] unwind: Unhandled instruction fc [ 0.252929] unwind: Unhandled instruction fc [ 0.252960] unwind: Unhandled instruction fc [ 0.252960] NET: Registered protocol family 16 [ 0.252990] unwind: Unhandled instruction fc [ 0.253021] unwind: Unhandled instruction fc [ 0.253021] unwind: Unhandled instruction fc [ 0.253082] unwind: Unhandled instruction fc [ 0.253112] unwind: Unhandled instruction fc [ 0.253387] unwind: Unhandled instruction fc [ 0.253417] unwind: Unhandled instruction fc [ 0.253509] GPMC revision 6.0 [ 0.253540] unwind: Unhandled instruction fc [ 0.253540] unwind: Unhandled instruction fc [ 0.253540] unwind: Unhandled instruction fc [ 0.253570] unwind: Unhandled instruction fc [ 0.253570] unwind: Unhandled instruction fc [ 0.253570] unwind: Unhandled instruction fc [ 0.254516] unwind: Unhandled instruction fc [ 0.254882] unwind: Unhandled instruction fc [ 0.257507] unwind: Unhandled instruction fc [ 0.257568] unwind: Unhandled instruction fc [ 0.257568] unwind: Unhandled instruction fc [ 0.257598] unwind: Unhandled instruction fc [ 0.257598] unwind: Unhandled instruction fc [ 0.257629] unwind: Unhandled instruction fc [ 0.257843] unwind: Unhandled instruction fc [ 0.257995] unwind: Unhandled instruction fc [ 0.258056] unwind: Unhandled instruction fc [ 0.258056] unwind: Unhandled instruction fc [ 0.258087] unwind: Unhandled instruction fc [ 0.258087] unwind: Unhandled instruction fc [ 0.258087] unwind: Unhandled instruction fc [ 0.258117] unwind: Unhandled instruction fc [ 0.258117] unwind: Unhandled instruction fc [ 0.258117] unwind: Unhandled instruction fc [ 0.258148] unwind: Unhandled instruction fc [ 0.258178] unwind: Unhandled instruction fc [ 0.258209] unwind: Unhandled instruction fc [ 0.258209] unwind: Unhandled instruction fc [ 0.258239] unwind: Unhandled instruction fc [ 0.258239] unwind: Unhandled instruction fc [ 0.258300] unwind: Unhandled instruction fc [ 0.258331] unwind: Unhandled instruction fc [ 0.258361] unwind: Unhandled instruction fc [ 0.258361] unwind: Unhandled instruction fc [ 0.258392] unwind: Unhandled instruction fc [ 0.258453] unwind: Unhandled instruction fc [ 0.258453] unwind: Unhandled instruction fc [ 0.258636] unwind: Unhandled instruction fc [ 0.258666] unwind: Unhandled instruction fc [ 0.258697] unwind: Unhandled instruction fc [ 0.258697] unwind: Unhandled instruction fc [ 0.258697] unwind: Unhandled instruction fc [ 0.258728] unwind: Unhandled instruction fc [ 0.258758] unwind: Unhandled instruction fc [ 0.258758] unwind: Unhandled instruction fc [ 0.258789] unwind: Unhandled instruction fc [ 0.258972] unwind: Unhandled instruction fc [ 0.259002] OMAP GPIO hardware version 0.1 [ 0.259033] unwind: Unhandled instruction fc [ 0.259643] unwind: Unhandled instruction fc [ 0.262054] unwind: Unhandled instruction fc [ 0.263061] unwind: Unhandled instruction fc [ 0.263183] unwind: Unhandled instruction fc [ 0.263183] unwind: Unhandled instruction fc [ 0.263214] unwind: Unhandled instruction fc [ 0.263214] unwind: Unhandled instruction fc [ 0.264190] unwind: Unhandled instruction fc [ 0.264190] unwind: Unhandled instruction fc [ 0.264221] unwind: Unhandled instruction fc [ 0.264221] unwind: Unhandled instruction fc [ 0.264495] unwind: Unhandled instruction fc [ 0.264495] unwind: Unhandled instruction fc [ 0.264495] unwind: Unhandled instruction fc [ 0.264526] unwind: Unhandled instruction fc [ 0.264526] unwind: Unhandled instruction fc [ 0.264556] unwind: Unhandled instruction fc [ 0.264556] unwind: Unhandled instruction fc [ 0.264587] unwind: Unhandled instruction fc [ 0.264587] unwind: Unhandled instruction fc [ 0.264862] unwind: Unhandled instruction fc [ 0.264862] unwind: Unhandled instruction fc [ 0.264892] unwind: Unhandled instruction fc [ 0.264923] unwind: Unhandled instruction fc [ 0.264923] unwind: Unhandled instruction fc [ 0.265197] omap_mux_init: Add partition: #1: core, flags: 2 [ 0.265502] unwind: Unhandled instruction fc [ 0.265502] unwind: Unhandled instruction fc [ 0.265533] unwind: Unhandled instruction fc [ 0.266662] omap_mux_init: Add partition: #2: wkup, flags: 2 [ 0.266784] error setting wl12xx data [ 0.266815] unwind: Unhandled instruction fc [ 0.266845] unwind: Unhandled instruction fc [ 0.266845] unwind: Unhandled instruction fc [ 0.266876] unwind: Unhandled instruction fc [ 0.266876] unwind: Unhandled instruction fc [ 0.266876] unwind: Unhandled instruction fc [ 0.269195] unwind: Unhandled instruction fc [ 0.269683] unwind: Unhandled instruction fc [ 0.269744] unwind: Unhandled instruction fc [ 0.270019] unwind: Unhandled instruction fc [ 0.270050] unwind: Unhandled instruction fc [ 0.272644] unwind: Unhandled instruction fc [ 0.272674] unwind: Unhandled instruction fc [ 0.273101] unwind: Unhandled instruction fc [ 0.277008] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [ 0.277038] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.277343] unwind: Unhandled instruction fc [ 0.285156] unwind: Unhandled instruction fc [ 0.285247] unwind: Unhandled instruction fc [ 0.285797] unwind: Unhandled instruction fc [ 0.285980] unwind: Unhandled instruction fc [ 0.287445] unwind: Unhandled instruction fc [ 0.287475] unwind: Unhandled instruction fc [ 0.287567] OMAP DMA hardware revision 0.0 [ 0.288146] unwind: Unhandled instruction fc [ 0.288177] unwind: Unhandled instruction fc [ 0.288177] unwind: Unhandled instruction fc [ 0.290161] unwind: Unhandled instruction fc [ 0.290191] unwind: Unhandled instruction fc [ 0.290191] unwind: Unhandled instruction fc [ 0.313110] unwind: Unhandled instruction fc [ 0.313690] unwind: Unhandled instruction fc [ 0.313690] unwind: Unhandled instruction fc [ 0.313690] unwind: Unhandled instruction fc [ 0.313720] unwind: Unhandled instruction fc [ 0.313873] unwind: Unhandled instruction fc [ 0.313873] unwind: Unhandled instruction fc [ 0.314147] unwind: Unhandled instruction fc [ 0.314147] unwind: Unhandled instruction fc [ 0.314147] unwind: Unhandled instruction fc [ 0.314208] unwind: Unhandled instruction fc [ 0.314208] unwind: Unhandled instruction fc [ 0.314239] unwind: Unhandled instruction fc [ 0.314270] bio: create slab <bio-0> at 0 [ 0.314880] unwind: Unhandled instruction fc [ 0.314880] unwind: Unhandled instruction fc [ 0.314880] unwind: Unhandled instruction fc [ 0.314880] unwind: Unhandled instruction fc [ 0.315338] unwind: Unhandled instruction fc [ 0.315368] unwind: Unhandled instruction fc [ 0.315368] unwind: Unhandled instruction fc [ 0.316467] unwind: Unhandled instruction fc [ 0.316894] unwind: Unhandled instruction fc [ 0.316925] print_constraints: vwl1271: 1800 mV [ 0.319488] SCSI subsystem initialized [ 0.319702] unwind: Unhandled instruction fc [ 0.319732] unwind: Unhandled instruction fc [ 0.319854] unwind: Unhandled instruction fc [ 0.319915] unwind: Unhandled instruction fc [ 0.319976] unwind: Unhandled instruction fc [ 0.320007] unwind: Unhandled instruction fc [ 0.320037] unwind: Unhandled instruction fc [ 0.320068] unwind: Unhandled instruction fc [ 0.320129] unwind: Unhandled instruction fc [ 0.320129] unwind: Unhandled instruction fc [ 0.320312] unwind: Unhandled instruction fc [ 0.320343] unwind: Unhandled instruction fc [ 0.320373] unwind: Unhandled instruction fc [ 0.320373] unwind: Unhandled instruction fc [ 0.320373] unwind: Unhandled instruction fc [ 0.320404] unwind: Unhandled instruction fc [ 0.320404] unwind: Unhandled instruction fc [ 0.320434] unwind: Unhandled instruction fc [ 0.320434] unwind: Unhandled instruction fc [ 0.320434] unwind: Unhandled instruction fc [ 0.323028] usbcore: registered new interface driver usbfs [ 0.323516] usbcore: registered new interface driver hub [ 0.323669] unwind: Unhandled instruction fc [ 0.323699] unwind: Unhandled instruction fc [ 0.323822] usbcore: registered new device driver usb [ 0.324798] unwind: Unhandled instruction fc [ 0.330810] unwind: Unhandled instruction fc [ 0.338256] unwind: Unhandled instruction fc [ 0.338256] unwind: Unhandled instruction fc [ 0.338256] unwind: Unhandled instruction fc [ 0.338287] unwind: Unhandled instruction fc [ 0.338348] unwind: Unhandled instruction fc [ 0.338470] unwind: Unhandled instruction fc [ 0.338531] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz [ 0.338562] unwind: Unhandled instruction fc [ 0.338562] unwind: Unhandled instruction fc [ 0.338623] unwind: Unhandled instruction fc [ 0.338623] unwind: Unhandled instruction fc [ 0.339019] unwind: Unhandled instruction fc [ 0.339019] unwind: Unhandled instruction fc [ 0.339050] unwind: Unhandled instruction fc [ 0.339050] unwind: Unhandled instruction fc [ 0.339080] unwind: Unhandled instruction fc [ 0.339111] unwind: Unhandled instruction fc [ 0.339111] unwind: Unhandled instruction fc [ 0.339141] unwind: Unhandled instruction fc [ 0.339141] unwind: Unhandled instruction fc [ 0.339172] unwind: Unhandled instruction fc [ 0.339202] unwind: Unhandled instruction fc [ 0.339263] unwind: Unhandled instruction fc [ 0.339294] unwind: Unhandled instruction fc [ 0.339324] unwind: Unhandled instruction fc [ 0.339355] unwind: Unhandled instruction fc [ 0.339385] unwind: Unhandled instruction fc [ 0.339416] unwind: Unhandled instruction fc [ 0.339569] unwind: Unhandled instruction fc [ 0.339721] unwind: Unhandled instruction fc [ 0.339721] unwind: Unhandled instruction fc [ 0.340881] Skipping twl internal clock init and using bootloader value (unknown osc rate) [ 0.340911] unwind: Unhandled instruction fc [ 0.340911] unwind: Unhandled instruction fc [ 0.340911] unwind: Unhandled instruction fc [ 0.340942] unwind: Unhandled instruction fc [ 0.340972] unwind: Unhandled instruction fc [ 0.340972] unwind: Unhandled instruction fc [ 0.340972] unwind: Unhandled instruction fc [ 0.340972] unwind: Unhandled instruction fc [ 0.341003] unwind: Unhandled instruction fc [ 0.341033] unwind: Unhandled instruction fc [ 0.341033] unwind: Unhandled instruction fc [ 0.341064] unwind: Unhandled instruction fc [ 0.341064] unwind: Unhandled instruction fc [ 0.341156] unwind: Unhandled instruction fc [ 0.341156] unwind: Unhandled instruction fc [ 0.341156] unwind: Unhandled instruction fc [ 0.341217] unwind: Unhandled instruction fc [ 0.341705] twl6030: PIH (irq 39) chaining IRQs 368..387 [ 0.341766] unwind: Unhandled instruction fc [ 0.341766] unwind: Unhandled instruction fc [ 0.341796] unwind: Unhandled instruction fc [ 0.341949] unwind: Unhandled instruction fc [ 0.343170] machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint [ 0.343200] unwind: Unhandled instruction fc [ 0.343231] unwind: Unhandled instruction fc [ 0.343231] unwind: Unhandled instruction fc [ 0.343261] unwind: Unhandled instruction fc [ 0.343261] unwind: Unhandled instruction fc [ 0.343292] unwind: Unhandled instruction fc [ 0.343292] unwind: Unhandled instruction fc [ 0.343292] unwind: Unhandled instruction fc [ 0.343322] unwind: Unhandled instruction fc [ 0.343353] unwind: Unhandled instruction fc [ 0.343353] unwind: Unhandled instruction fc [ 0.343353] unwind: Unhandled instruction fc [ 0.343353] unwind: Unhandled instruction fc [ 0.343383] unwind: Unhandled instruction fc [ 0.343383] unwind: Unhandled instruction fc [ 0.343414] unwind: Unhandled instruction fc [ 0.343414] unwind: Unhandled instruction fc [ 0.343444] unwind: Unhandled instruction fc [ 0.343444] unwind: Unhandled instruction fc [ 0.343444] unwind: Unhandled instruction fc [ 0.343475] unwind: Unhandled instruction fc [ 0.343566] unwind: Unhandled instruction fc [ 0.343566] unwind: Unhandled instruction fc [ 0.343566] unwind: Unhandled instruction fc [ 0.343597] unwind: Unhandled instruction fc [ 0.343627] unwind: Unhandled instruction fc [ 0.343627] unwind: Unhandled instruction fc [ 0.343627] unwind: Unhandled instruction fc [ 0.343627] unwind: Unhandled instruction fc [ 0.343658] unwind: Unhandled instruction fc [ 0.343658] unwind: Unhandled instruction fc [ 0.343688] unwind: Unhandled instruction fc [ 0.343688] unwind: Unhandled instruction fc [ 0.343719] unwind: Unhandled instruction fc [ 0.343719] unwind: Unhandled instruction fc [ 0.343719] unwind: Unhandled instruction fc [ 0.343749] unwind: Unhandled instruction fc [ 0.343749] unwind: Unhandled instruction fc [ 0.343780] unwind: Unhandled instruction fc [ 0.344024] twl_reg twl_reg.46: can't register VUSB, -22 [ 0.344024] unwind: Unhandled instruction fc [ 0.344055] twl_reg: probe of twl_reg.46 failed with error -22 [ 0.344787] unwind: Unhandled instruction fc [ 0.344970] print_constraints: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby [ 0.346038] print_constraints: VPP: 1800 <--> 2500 mV at 1900 mV normal standby [ 0.347259] print_constraints: VCXIO: 1800 mV normal standby [ 0.348083] print_constraints: VDAC: 1800 mV normal standby [ 0.348571] unwind: Unhandled instruction fc [ 0.348602] unwind: Unhandled instruction fc [ 0.349090] print_constraints: VAUX2_6030: 1200 <--> 2800 mV at 1800 mV normal standby [ 0.349670] unwind: Unhandled instruction fc [ 0.350128] print_constraints: VAUX3_6030: 1000 <--> 3000 mV at 1200 mV normal standby [ 0.350616] unwind: Unhandled instruction fc [ 0.350952] print_constraints: CLK32KG: [ 0.351745] print_constraints: VANA: 2100 mV normal standby [ 0.351898] unwind: Unhandled instruction fc [ 0.361175] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz [ 0.376373] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz [ 0.391601] omap_i2c omap_i2c.4: bus 4 rev2.4.0 at 400 kHz [ 0.393493] unwind: Unhandled instruction fc [ 0.393524] unwind: Unhandled instruction fc [ 0.393585] unwind: Unhandled instruction fc [ 0.393615] unwind: Unhandled instruction fc [ 0.393646] unwind: Unhandled instruction fc [ 0.393676] unwind: Unhandled instruction fc [ 0.393707] unwind: Unhandled instruction fc [ 0.393737] unwind: Unhandled instruction fc [ 0.393768] unwind: Unhandled instruction fc [ 0.393768] unwind: Unhandled instruction fc [ 0.393798] unwind: Unhandled instruction fc [ 0.393798] unwind: Unhandled instruction fc [ 0.393829] unwind: Unhandled instruction fc [ 0.393951] unwind: Unhandled instruction fc [ 0.394165] unwind: Unhandled instruction fc [ 0.394195] unwind: Unhandled instruction fc [ 0.394195] unwind: Unhandled instruction fc [ 0.394256] unwind: Unhandled instruction fc [ 0.394317] unwind: Unhandled instruction fc [ 0.394317] unwind: Unhandled instruction fc [ 0.394500] unwind: Unhandled instruction fc [ 0.394561] unwind: Unhandled instruction fc [ 0.394561] unwind: Unhandled instruction fc [ 0.394592] unwind: Unhandled instruction fc [ 0.394592] unwind: Unhandled instruction fc [ 0.394622] unwind: Unhandled instruction fc [ 0.395050] unwind: Unhandled instruction fc [ 0.395080] unwind: Unhandled instruction fc [ 0.395080] unwind: Unhandled instruction fc [ 0.395111] unwind: Unhandled instruction fc [ 0.395202] unwind: Unhandled instruction fc [ 0.395202] unwind: Unhandled instruction fc [ 0.395202] unwind: Unhandled instruction fc [ 0.395233] unwind: Unhandled instruction fc [ 0.395263] unwind: Unhandled instruction fc [ 0.395294] unwind: Unhandled instruction fc [ 0.395355] Switching to clocksource 32k_counter [...] -- 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] u-boot package
by Alexander Graf 23 Nov '11

23 Nov '11

Hi guys, To build a kernel on ARM we need the u-boot tool "mkimage". Looking through OBS I spotted that Joop had already created packages for this and even got them successfully submitted to Base:System. Great! However, to make use of them in the kernel rpm I need them to be in Factory :). Could you guys please settle on the maintainership of the u-boot packages and submit them to Factory so that I can continue to build on them? Thanks, Alex -- 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] openSUSE:Factory:ARM standard armv7l isn't published anymore
by Joop Boonen 22 Nov '11

22 Nov '11

Hi all, It looks like openSUSE:Factory:ARM standard armv7l isn't published any more. The latest update was around November 3 2011. 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] texinfo breakage
by Alexander Graf 22 Nov '11

22 Nov '11

Hi guys, Looking at the texinfo build log I stumbled over the following difference between the x86 and the arm build: ###### x86 ###### checking for tgetent in -lncurses... yes checking for library with termcap variables... checking ncurses/termcap.h usability... yes checking ncurses/termcap.h presence... yes checking for ncurses/termcap.h... yes ###### ARM ###### checking for tgetent in -lncurses... no checking for tgetent in -lcurses... no checking for tgetent in -ltermlib... no checking for tgetent in -ltermcap... no checking for tgetent in -lterminfo... no configure: WARNING: probably need a terminal library, one of: ncurses curses termlib termcap terminfo checking for library with termcap variables... The build failure in the ARM package seems to be related: terminal.o: In function `terminal_goto_xy': /home/abuild/rpmbuild/BUILD/texinfo-4.13/info/terminal.c:235: undefined reference to `tgoto' If anyone is searching for a (potential) low hanging fruit, I hope this is one :). It is not an emulation bug btw - the native build fails the exact same way. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 2

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

[opensuse-arm] rpm build running on Pandaboard
by Joop Boonen 27 Jun '11

27 Jun '11

Hi all, For people who want to test a rpm distro build build on the Pandaboard. Using these instructions: http://wiki.meego.com/ARM/OMAP4_Panda 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] Linaro and Samsung roll out Exynos 4210-based Origen development board for $199
by Joop Boonen 31 May '11

31 May '11

Hi All, I just read Samsung will roll out a development board with their Exynos 4210 SOC. http://www.engadget.com/2011/05/29/linaro-and-samsung-roll-out-exynos-4210-… 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] openSuSE and ARM
by Joop Boonen 20 May '11

20 May '11

Hi All, It's great that the opensuse-arm mailing list has been created. The best options to use are: The Pandaboard (Dual Core Cortex A9 TI OMAP4430): http://www.pandaboard.org/ The Beagleboard (Cortex A8 TI OMAP3530): http://beagleboard.org/ Or more the Toshiba AC100 (Dual Core Cortex A9 Tegra 2)(which will be more complicated). http://geizhals.at/eu/?cat=nb12&asd=on&asuch=AC100 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