April 2012 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] openSUSE on Pandaboard ES
by endym_linux＠ymail.com 16 Apr '12

16 Apr '12

Hello again! I run the image LimeJeOS-openSUSE-Factory-ARM-panda.armv7l-1.12.1-Build10.1.raw from <http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/> on the new Pandaboard ES. After zypper ref && zypper up the following error occures on boot: ************************************ USB EHCI 1.00 scanning bus for devices... The request port(2) is not configured The request port(2) is not configured 4 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found Waiting for Ethernet connection... done. BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 42 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 42 DHCP client bound to address 192.168.1.116 missing environment variable: pxeuuid missing environment variable: ethaddr missing environment variable: bootfile Retrieving file: pxelinux.cfg/01-2e-60-1a-38-4e-01 Waiting for Ethernet connection... done. Using sms0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.116 Filename 'pxelinux.cfg/01-2e-60-1a-38-4e-01'. Load address: 0x86000000 Loading: EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 Retry count exceeded; starting again Waiting for Ethernet connection... done. EHCI timed out on TD - token=0x88008d80 Using sms0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.116 Filename 'pxelinux.cfg/01-2e-60-1a-38-4e-01'. Load address: 0x86000000 Loading: EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x8008d80 T EHCI timed out on TD - token=0x88008d80 Retry count exceeded; starting again ... ************************************ The boot process is in an endless loop now. Is this a factory problem or is "zypper up" the wrong way? There is also a similar thread for the Beagleboard xM (http://lists.opensuse.org/opensuse-arm/2012-04/msg00006.html). Maybe it's the same issue... Regards, endym -- 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] Multimedia support for ARM (kernel configs)
by Guillaume Gardet 15 Apr '12

15 Apr '12

Hi, Is there any reason to not have enabled multimedia support on ARM (except on default config)? I think it would be nice to enable it (especially V4L support) for ARM boards. I know OMAP have capture and display drivers for V4L. I suppose others (IMX51, Tegra, ...) have similar things. Cheers, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 3

[opensuse-arm] Re: [opensuse-buildservice] [PATCH] [build] Map Debian ARM arches to OBS
by Adrian Schröter 15 Apr '12

15 Apr '12

Am Mittwoch, 28. März 2012, 04:49:01 schrieb Adrian Schröter: > Am Dienstag, 27. März 2012, 22:43:35 schrieb Hector Oron: > > Hello Adrian, > > > > On 27/03/12 22:32, Adrian Schröter wrote: > > > Am Dienstag, 27. März 2012, 20:55:41 schrieb Hector Oron: > > >> Debian ARM arches: > > >> - Debian 'armel', which defaults to ARMv4t (soft) maps to armv[4567]l > > >> - Debian 'armhf', which defaults to ARMv7 (hard-float) maps to armv7hl > > >> > > >> Note Ubuntu 'armel' deprecated after 'precise' release, defaults to ARMv7 > > >> (softfp). So Ubuntu 'armel' should really map armv7l, but its out of scope > > >> for this patch. > > > > > > Hm, doesnt it make sense to map armv7l and armv7hl to armhf ? AFAIK there are no > > > arm cpus on v7 level without hardware fp. > > > > > > On the other hand this is about optimization level here and not hardware capabilities... > > > > As I understand armv7hl is hard-float ABI, hence 'armhf'. > > > > armv7l can be ARMv7/softfp as Ubuntu was doing on their ARM port > > (armel), hence makes sense to me to map armv7l to 'armel'. > > > > OTOH, Debian armel can run on any of those platforms, armv[4567]l, maybe > > armv[4567]el should be added to the list. In other words, if I am > > building armv7l debian packages I would expect them to use 'armel' > > dependencies, while if I am building armv7hl, I would expect to build > > against 'armhf' dependencies. > > > > As a side note, I also see 'armv8el', I think that one comes from MeeGo, > > and it should be deprecated and mapped in the future to aarch64 (64-bit > > ARM architecture). > > That one is pure fantasy and will have nothing in common with real upcomming armv8, I think. > > But also architectures like armv7hl or armhf are fantasy when it comes to the linux > kernel. They are just a hack in the packagemanagement to avoid to handle ABI compatibility > on dependency level. But it makes for example impossible to install static binaries armv7l > on armv7hl and vice versa. Even though it would run on real hardware. > > Or it would be thinkable to have also an entire set of packages with softfp on hardfp and vice > versa. For that reason I selected just "armv7l" for our hardfp optimized distribution. > But I agree that we seems to be special in the arm world with that way (so in worst case > we need to switch to armv7hl as well and need to make armv7l and armv7hl as equivalent to avoid > the describe problems) :/ > > In any case we have the problem now that we can not detect the ABI from the architecture now... > > We can take your patch now, but armhf will not be selected right in our default settings. > > I would be happy, if anyone has a better proposal here. Thinking again on the way to work about it, I think the following is the right approach: 1) Take your patch as is (done) ;) 2) Keep schedulers running on armv7l only, because we have just one pool of systems to build for. The same machines can handle armv7 softfp and hardfp (is this right?, I am no expert in arm hardware) For our openSUSE arm distro: 3) Define default _cpu_target as armv7hl, so we get also .armv7hl.rpm packages 4) Trim our rpm on arm to handle armv7l and armv7hl as equivalent. 5) extend library depend&provides handling with a "(hf)" extension to be able to distinguish between hardfp and softfp packages on the same installation. Note: The last point 5) would make our rpms incompatible with the ones from Fedora. But it is IMHO the only way to handle mixed installations and the fedora way is IMHO technical just wrong. I would be happy to hear some more opinions on this. -- 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

3 2

[opensuse-arm] efika networking
by Peter Czanik 15 Apr '12

15 Apr '12

Hello, After yesterdays updates, networking does not work any more on the EFIKA. I still use the old Genesi kernel, as it arrived in the EFIKA image (2.6.31.14.26-efikamx) from http://lizards.opensuse.org/2012/01/21/opensuse-arm-image/ The non working wifi is definitely related to udev, there were related e-mails on the factory list also for x86, that firmware for Intel wifi can't be loaded either. But Ethernet on the smart top also does not work: it receives an initial IP address from the DHCP server, but after that there is no networking, even the DHCP server can't be reached again. Networking from Ubuntu works fine fine on the same machines. Any idea how to fix this? 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] Unable to login on Beagleboard xM with latest image
by Guillaume Gardet 15 Apr '12

15 Apr '12

I tried a zypper dup today but it broke my board (unable to boot since kernel file name in /boot did not match anymore and no initrd was present.) So, I wanted to boot the latest raw image but trying to log in with root/linux but I get this error: *************************************************************** linux login: root Password: Permissions on the password database may be too restrictive *************************************************************** I looked at the /etc/shadow file which seems strange to me: *************************************************************** Event # Greg Bailey <gbailey&lxpro.com> February 2002 biolink-auth 3411/tcp # BioLink Authenteon server biolink-auth 3411/udp # BioLink Authenteon server # BioLink Support <reginfo&biolinkusa.com> February 2002 xmlblaster 3412/tcp # xmlBlaster xmlblaste *************************************************************** Replaced by my /etc/shadow from my running PC and I am able to login (with the password from my PC of course). Could you please fix it ? Guillaume -- 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] Runtime linker path for ARM v7 hard-float
by Steve McIntyre 11 Apr '12

11 Apr '12

Hey guys, There's been a *lot* of discussion about this in the last few days on the cross-distro list (and elsewhere), but I've not noticed anybody from opensuse joining in. It's very important for sane cross-distro compatibility that we agree on the location of the runtime linker. We're trying to organise a conf call to get this sorted *now* before anybody releases a stable arm-hf distro. Who from the opensuse team would like to join in? If you can join us on irc, freenode #linaro-armhf to help schedule a call ASAP that would be lovely. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs -- 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] omap2plus - Update config for 3.4-rc2 + misc improvements/fixes
by Guillaume Gardet 10 Apr '12

10 Apr '12

Hi, I sent a patch to opensuse-kernel: http://lists.opensuse.org/opensuse-kernel/2012-04/msg00027.html to update config for omap2plus for 3.4-rc2 and some improvements/fixes: * Add TWL4030 and TWL6030 USB support * Add Multimedia support * Disable egalax touchscreen to fix compilation error Is someone able to ack the patch, please? Regards, Guillaume -- 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] iMX51 - Update config for 3.4-rc2 + enable Multimedia support
by Guillaume Gardet 10 Apr '12

10 Apr '12

Please find in attachment a patch for the iMX51 config. I took the config from kernel-source/config/armv7l/imx51 and I added Multimedia support via menuconfig. It compiles (uImage + modules) but I haven't tested it since I have no iMX51 board. Regards, Guillaume

1 0

[opensuse-arm] DSP on OMAP3
by Guillaume Gardet 10 Apr '12

10 Apr '12

Hi, I can get the DSP working on OMAP3 (BB xM) with the latest beagle raw image (10.7). Install needed packages and load needed drivers: zypper in dsp-tools tidsp-binaries modprobe mailbox_mach modprobe bridgedriver base_img=/lib/dsp/baseimage.dof Then you can try some dsp tools: dsp-probe which returns: *** device: /codec device: /mixer device: /acdn device: /eteedn device: /mmmdn task: DASFTASK_TI task: SYNCCLOCK_TI task: dummy *** dsp-test which returns: *** copied 1000 times successfully *** I have not tested gstreamer DSP plugin yet but I will keep you up-to-date once done! I have 1 question related to module loading. Why mailbox_mach and bridgedriver are not loaded on boot? Do we need some udev rules? Cheers, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 1

Re: [opensuse-arm] build failure due to ldd error?
by Guillaume Gardet 09 Apr '12

09 Apr '12

Le 07/04/2012 00:34, Tomas Cech a écrit : > Hi, > > First, thanks for your answer. > > On Fri, Apr 06, 2012 at 11:17:26AM +0200, Guillaume Gardet wrote: >> Hi, >> >> Le 05/04/2012 22:51, Tomas Cech a écrit : >>> Hi, >>> >>> I enabled compilation of E17 for armv7l and got strange error: >>> >>> /usr/bin/edje_cc: error while loading shared libraries: >>> /usr/lib/liblua-5.1.so: unexpected reloc type 0x03 >>> >>> Full log is accessible with: >>> >>> osc rbl X11:Enlightenment:Nightly emotion openSUSE_Factory_ARM armv7l >>> >>> I believe that this doesn't seem to be packager issue... Any ideas? >>> >>> Best regards, >>> >>> Tomas Cech >>> >> >> I think the liblua you are using was compiled without -fPIC option. > > I added -fPIC to CFLAGS, but the problem is the same. > >> Can you try liblua from openSUSE:Factory:ARM? Or recompile liblua with -fPIC option? > > Unfortunatelly no, E17 still depends on lua 5.1 as there were API > changes... Acording to: osc rbl X11:Enlightenment:Nightly lua51 openSUSE_Factory_ARM armv7l RPM lit reports: ******************************************************************************** lua51-libs.armv7l: W: shlib-with-non-pic-code /usr/lib/liblua-5.1.so The listed shared libraries contain object code that was compiled without -fPIC. All object code in shared libraries should be recompiled separately from the static libraries with the -fPIC option. Another common mistake that causes this problem is linking with ``gcc -Wl,-shared'' instead of ``gcc -shared''. ******************************************************************************** So something get wrong. maybe try to do CFLAGS+=-fPIC instead of CFLAGS=-fPIC or use MYCFLAGS. Have a look at the following links for used option and maybe patches for lua: https://build.opensuse.org/package/view_file?file=lua.spec&package=lua&proj… http://git.buildroot.net/buildroot/tree/package/lua Regards, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0