- openSUSE ARM

[opensuse-arm] Bad kernel-omap2plus package ?
by Guillaume Gardet 17 Apr '12

17 Apr '12

Hi, I installed the latest raw image for BeagleBoard xM and then "zypper refresh && zypper up" and I get a lot of warnings (check attachment). Especially for kernel installation: ******************************************************************************** Installing: kernel-omap2plus-3.3.0-1.1 [done] Additional rpm output: WARNING: /etc/depmod.d/00-system.conf line 1: ignoring bad line starting with '4683/tcp' WARNING: /etc/depmod.d/00-system.conf line 2: ignoring bad line starting with 'spike' WARNING: /etc/depmod.d/00-system.conf line 4: ignoring bad line starting with 'rfid-rp1' WARNING: /etc/depmod.d/00-system.conf line 5: ignoring bad line starting with 'rfid-rp1' WARNING: /etc/depmod.d/00-system.conf line 7: ignoring bad line starting with 'autopac' WARNING: /etc/depmod.d/00-system.conf line 8: ignoring bad line starting with 'autopac' WARNING: kernel image for 3.3.0-1-omap2plus not found! ******************************************************************************** And a ls /boot show this: ******************************************************************************** -rw-r--r-- 1 root root 1,3K 20 mars 11:52 boot.readme -rw-r--r-- 1 root root 697 1 janv. 2000 boot.scr -rw-r--r-- 1 root root 625 1 janv. 2000 boot.script -rw-r--r-- 1 root root 81K 22 mars 12:50 config-3.3.0-1-omap2plus drwxr-xr-x 2 root root 1,0K 1 janv. 2000 grub lrwxrwxrwx 1 root root 24 23 févr. 02:11 initrd -> initrd-3.3.0-1-omap2plus -rw-r--r-- 1 root root 22M 13 mars 14:50 initrd.uboot -rw-r--r-- 1 root root 3,9M 13 mars 14:50 linux.vmx drwx------ 2 root root 12K 13 mars 14:50 lost+found -rwxr-xr-x 1 root root 29K 1 mars 00:37 MLO -rw-r--r-- 1 root root 73K 22 mars 13:43 symvers-3.3.0-1-omap2plus.gz -rw-r--r-- 1 root root 234 22 mars 13:43 sysctl.conf-3.3.0-1-omap2plus -rw-r--r-- 1 root root 1,9M 22 mars 13:32 System.map-3.3.0-1-omap2plus -rw-r--r-- 1 root root 331K 1 mars 11:27 u-boot.bin lrwxrwxrwx 1 root root 24 23 févr. 02:11 uImage -> uImage-3.3.0-1-omap2plus -rw-r--r-- 1 root root 4,0M 22 mars 13:43 uImage-3.3.0-1-omap2plus -rw-r--r-- 1 root root 4,9M 22 mars 13:37 vmlinux-3.3.0-1-omap2plus.gz ******************************************************************************** So, no initrd (except a broken link and the initrd.u-boot). Moreover, when I try to boot, u-boot is still looking for uImage-3.2.0-2-omap2plus which is no more here. (same for initrd). So I think something is broken somewhere! Guillaume

3 9

[opensuse-arm] Rebuild trigger request for openSUSE:Factory:ARM gdk-pixbuf
by Joop Boonen 17 Apr '12

17 Apr '12

Hi all, Can the package openSUSE:Factory:ARM gdk-pixbuf please be rebuild, as this package isn't up to date any more. package libtiff-devel where this package depends on has been rebuild. 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] Fwd: ARM hard-float linker path - consensus
by Andreas Jaeger 16 Apr '12

16 Apr '12

FYI, Adrian asked me to participate in the call and here's the result. Once we have a glibc patch, let's fix both gcc and glibc - and add a compatibility symlink for now until rebuilding of the whole distro succeeded... Andreas -------- Original Message -------- Subject: ARM hard-float linker path - consensus Date: Fri, 13 Apr 2012 18:37:11 +0100 From: Steve McIntyre <steve.mcintyre(a)linaro.org> To: cross-distro(a)lists.linaro.org CC: gcc-patches(a)gcc.gnu.org, libc-ports(a)sourceware.org Hi folks, As promised, here's minutes from the call we had this afternoon. Spoiler: the result we've agreed is /lib/ld-linux-armhf.so.3 And here's a transcription of the minutes from https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 ======================================== Meeting: 13th April 2012, 15:00 UTC Agenda ------ * Debian/Ubuntu have so far built using /lib/arm-linux-gnueabihf/ld-linux.so.3 * Some other distros (Fedora, OpenSUSE) are still using /lib/ld-linux.so.3 option which matches the older soft-float ABI * Some people are proposing /libhf/ld-linux.so.3 or /libhfp/ld-linux.so.3 (multilib) * Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to x86_64, libs still in /lib, from Michael Hope) * What should we do as a community? Present ------- Name Affiliations Steve McIntyre ARM, Debian, Linaro Wookey ARM, Debian, Linaro Richard Earnshaw ARM, gcc Jeff Law Fedora, Red Hat, gcc, glibc Jon Masters Fedora, Red Hat Andrew Haley Fedora, Red Hat, gcc Andreas Jaeger SUSE, openSUSE, glibc Carlos O'Donnell Mentor, gcc Steve Langasek Canonical, Ubuntu, Debian Dann Frazier Canonical, Ubuntu, Debian Adam Conrad Canonical, Ubuntu, Debian Matthias Klose Canonical, Ubuntu, Debian Mike Frysinger Gentoo Dennis Gilmore Fedora, Red Hat Discussion ---------- We started with a couple of questions up front to establish the grounds for discussion: * We believed that decision makers were present for all the important parties, i.e. all the arm hard-float distros, plus toolchain developers. This meant that a decision taken at the meeting could be implemented without needing further arguments/negotiations. * All the people present understood the importance of cross-distro binary compatibility, and they all wanted it. This led to agreement that we needed to agree on a standard path for the runtime linker for ARM hard-float Linux binaries. Debian and Ubuntu had so far been using the "multi-arch" path of /lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others had proposed alternative paths such as /libhf/ld-linux.so.3 or /libhfp/ld-linux.so.3 (multilib) or /lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these were found to be universally acceptable. Two parties were likely to be soon affected by an agreement here: 1. Ubuntu 12.04 (releasing with armhf in ~2 weeks) Adam/Steve L agreed that all efforts would be put in to switch the compilers in Ubuntu to a new path before release. Default things like gcc would be correct, but less common tools might still be targetting the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They could be fixed in the longer term and would not stop progress here. 2. Mentor (Codebench due for release in ~1 week) Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3 for hard-float binaries for some time and it was too late to change that for this upcoming release. Next release due in October. Suggested and accepted that this should be mentioned in release notes: if people want to use Codebench on some systems (Debian/Ubuntu and derivatives), they'll need to tweak their system setup. He may be able to do the linker change and rebuild in a point release in a few weeks. It was briefly suggested that the soft-float linker should be renamed away from /lib/ld-linux.so.3 as well at this time, but that idea was quickly shot down. Proposal #1: /lib/ld-armhf.so.3 (not generally liked) Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered an acceptable compromise by all) No need to go any further. Conclusion ---------- All the people in the meeting agreed: the new runtime linker path for ARM hard-float Linux binaries was to be /lib/ld-linux-armhf.so.3 ACTION: People at the meeting to present this decision to their companies / communities and get the appropriate changes made. Further discussion ------------------ General unhappiness with the mess that led to this meeting. Future planning needs to be better between the various groups for the next time we have a new CPU/ABI/whatever. ACTION: Jon Masters to talk to the Linux Foundation about setting up a forum for such discussions. In the meantime, strong consensus to use the cross-distro(a)lists.linaro.org mailing list for any more conversations now we have people in contact. ACTION: Steve McIntyre to write up the minutes and circulate. Include an updated linker path patch for gcc to match the decision made here. More discussion about triplets and naming, but nothing came of it in the end. Distro folks have already decided what they're using and have patched various software to build appropriately. Richard wants to move gcc's config.guess to use arm-linux-gnueabihf; no strong objections to that. Linker path patch for gcc ------------------------- Adapted from earlier work by Dann Frazier <dann.frazier(a)canonical.com> and Michael Hope <michael.hope(a)linaro.org> 2012-04-13 Steve McIntyre <steve.mcintyre(a)linaro.org> * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define. (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path. diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h index 80bd825..8c9d2e7 100644 --- a/gcc/config/arm/linux-eabi.h +++ b/gcc/config/arm/linux-eabi.h @@ -62,7 +62,11 @@ /* Use ld-linux.so.3 so that it will be possible to run "classic" GNU/Linux binaries on an EABI system. */ #undef GLIBC_DYNAMIC_LINKER -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3" +#define GLIBC_DYNAMIC_LINKER \ + "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ + %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}" /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to use the GNU/Linux version, not the generic BPABI version. */ Post-meeting on IRC ------------------- Suggested that Richard should push the change into gcc trunk ASAP. Steve McIntyre agreed to work on that with Richard. Also suggested that we want to get a patch into glibc too to change the installation path for ARM hard-float. Andrew agreed to push glibc upstream for that. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs _______________________________________________ cross-distro mailing list cross-distro(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro -- 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 -- 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] Beaglebaord xM - USB is broken
by Guillaume Gardet 16 Apr '12

16 Apr '12

Hi, I tried the latest beagle raw image (10.7) and USB is broken (so no Ethernet which is connected on USB internally, no USB stick). USB errors I get: (output of "dmesg | grep -i usb") ******************************************************************************** [ 0.092529] usbhs_omap: alias fck already exists [ 0.107055] usbcore: registered new interface driver usbfs [ 0.107177] usbcore: registered new interface driver hub [ 0.107391] usbcore: registered new device driver usb [ 0.171813] usbhs_omap usbhs_omap: xclk60mhsp1_ck set parentfailed error:-22 [ 0.171813] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 [ 1.666625] usbcore: registered new interface driver asix [ 1.672393] usbcore: registered new interface driver cdc_ether [ 1.678619] usbcore: registered new interface driver smsc95xx [ 1.684722] usbcore: registered new interface driver net1080 [ 1.690734] usbcore: registered new interface driver cdc_subset [ 1.697021] usbcore: registered new interface driver zaurus [ 1.702972] usbcore: registered new interface driver cdc_ncm [ 1.709228] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.716278] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.729431] drivers/usb/core/inode.c: creating file 'devices' [ 1.729461] drivers/usb/core/inode.c: creating file '001' [ 1.729766] ohci-omap3 ohci-omap3.0: new USB bus registered, assigned bus number 1 [ 1.821533] usb usb1: default language 0x0409 [ 1.821594] usb usb1: udev 1, busnum 1, minor = 0 [ 1.821594] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [ 1.828765] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 1.836334] usb usb1: Product: OMAP3 OHCI Host Controller [ 1.841979] usb usb1: Manufacturer: Linux 3.3.0-omap2plus+ ohci_hcd [ 1.848571] usb usb1: SerialNumber: ohci-omap3.0 [ 1.853973] usb usb1: usb_probe_device [ 1.854003] usb usb1: configuration #1 chosen from 1 choice [ 1.854034] usb usb1: adding 1-0:1.0 (config #1, interface 0) [ 1.854217] hub 1-0:1.0: usb_probe_interface [ 1.854217] hub 1-0:1.0: usb_probe_interface - got id [ 1.854248] hub 1-0:1.0: USB hub found [ 1.862457] hub 1-0:1.0: no power switching (usb 1.0) [ 1.862945] drivers/usb/core/inode.c: creating file '001' [ 1.863220] usbcore: registered new interface driver cdc_wdm [ 1.869201] Initializing USB Mass Storage driver... [ 1.874481] usbcore: registered new interface driver usb-storage [ 1.880767] USB Mass Storage support registered. [ 1.885742] usbcore: registered new interface driver libusual [ 1.891876] usbcore: registered new interface driver usbtest [ 2.173339] usbcore: registered new interface driver usbhid [ 2.179229] usbhid: USB HID core driver ******************************************************************************** Previous USB related dmesg (beagle raw image 10.6): ******************************************************************************** [ 0.074829] usbcore: registered new interface driver usbfs [ 0.074981] usbcore: registered new interface driver hub [ 0.075195] usbcore: registered new device driver usb [ 3.407592] usbcore: registered new interface driver asix [ 3.413391] usbcore: registered new interface driver cdc_ether [ 3.419616] usbcore: registered new interface driver smsc95xx [ 3.425720] usbcore: registered new interface driver net1080 [ 3.431701] usbcore: registered new interface driver cdc_subset [ 3.437988] usbcore: registered new interface driver zaurus [ 3.447296] usbcore: registered new interface driver cdc_ncm [ 3.453613] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 5.478576] /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.2.0/linux-3.2/drivers/usb/core/inode.c: creating file 'devices' [ 5.478607] /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.2.0/linux-3.2/drivers/usb/core/inode.c: creating file '001' [ 5.479034] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [ 5.503753] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [ 5.509948] usb usb1: default language 0x0409 [ 5.510009] usb usb1: udev 1, busnum 1, minor = 0 [ 5.510009] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 5.517150] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 5.524749] usb usb1: Product: OMAP-EHCI Host Controller [ 5.530334] usb usb1: Manufacturer: Linux 3.2.0-2-omap2plus ehci_hcd [ 5.536987] usb usb1: SerialNumber: ehci-omap.0 [ 5.542297] usb usb1: usb_probe_device [ 5.542297] usb usb1: configuration #1 chosen from 1 choice [ 5.542358] usb usb1: adding 1-0:1.0 (config #1, interface 0) [ 5.542541] hub 1-0:1.0: usb_probe_interface [ 5.542572] hub 1-0:1.0: usb_probe_interface - got id [ 5.542572] hub 1-0:1.0: USB hub found [ 5.551300] /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.2.0/linux-3.2/drivers/usb/core/inode.c: creating file '001' [ 5.581848] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 5.594787] /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.2.0/linux-3.2/drivers/usb/core/inode.c: creating file '002' [ 5.595123] ohci-omap3 ohci-omap3.0: new USB bus registered, assigned bus number 2 [ 5.685668] usb usb2: default language 0x0409 [ 5.685699] usb usb2: udev 1, busnum 2, minor = 128 [ 5.685729] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [ 5.692871] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 5.700439] usb usb2: Product: OMAP3 OHCI Host Controller [ 5.706115] usb usb2: Manufacturer: Linux 3.2.0-2-omap2plus ohci_hcd [ 5.712799] usb usb2: SerialNumber: ohci-omap3.0 [ 5.718170] usb usb2: usb_probe_device [ 5.718170] usb usb2: configuration #1 chosen from 1 choice [ 5.718231] usb usb2: adding 2-0:1.0 (config #1, interface 0) [ 5.718414] hub 2-0:1.0: usb_probe_interface [ 5.718414] hub 2-0:1.0: usb_probe_interface - got id [ 5.718444] hub 2-0:1.0: USB hub found [ 5.726654] hub 2-0:1.0: no power switching (usb 1.0) [ 5.727142] /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.2.0/linux-3.2/drivers/usb/core/inode.c: creating file '001' [ 5.727478] usbcore: registered new interface driver cdc_wdm [ 5.733459] Initializing USB Mass Storage driver... [ 5.738739] usbcore: registered new interface driver usb-storage [ 5.745056] USB Mass Storage support registered. [ 5.750030] usbcore: registered new interface driver libusual [ 5.756195] usbcore: registered new interface driver usbtest [ 5.902160] usb 1-2: new high-speed USB device number 2 using ehci-omap [ 6.061004] usbcore: registered new interface driver usbhid [ 6.066894] usbhid: USB HID core driver [ 6.142974] usb 1-2: udev 2, busnum 1, minor = 1 [ 6.143035] usb 1-2: New USB device found, idVendor=0424, idProduct=9514 [ 6.150115] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.158172] usb 1-2: usb_probe_device [ 6.158203] usb 1-2: configuration #1 chosen from 1 choice [ 6.158477] usb 1-2: adding 1-2:1.0 (config #1, interface 0) [ 6.158691] hub 1-2:1.0: usb_probe_interface [ 6.158691] hub 1-2:1.0: usb_probe_interface - got id [ 6.158721] hub 1-2:1.0: USB hub found [ 6.189483] /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.2.0/linux-3.2/drivers/usb/core/inode.c: creating file '002' [ 6.386688] usb 1-2: link qh256-0001/c24aa4e0 start 1 [1/0 us] [ 6.472656] usb 1-2.1: new high-speed USB device number 3 using ehci-omap [ 6.598022] usb 1-2.1: udev 3, busnum 1, minor = 2 [ 6.598052] usb 1-2.1: New USB device found, idVendor=0424, idProduct=ec00 [ 6.605316] usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.628997] usb 1-2.1: usb_probe_device [ 6.629028] usb 1-2.1: configuration #1 chosen from 1 choice [ 6.631408] usb 1-2.1: adding 1-2.1:1.0 (config #1, interface 0) [ 6.631622] smsc95xx 1-2.1:1.0: usb_probe_interface [ 6.631652] smsc95xx 1-2.1:1.0: usb_probe_interface - got id [ 6.721282] smsc95xx 1-2.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet, c2:7a:cd:e3:cb:21 [ 6.746002] /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.2.0/linux-3.2/drivers/usb/core/inode.c: creating file '003' [ 152.115692] usb 1-2.1: link qh8-0001/d96d52e0 start 2 [1/0 us] ******************************************************************************** It seems there is no EHCI detection. It may be due to bad clock? Do you have this problem on Beagleboard (original, not xM) and on pandaboard also or is it a BB xM only problem? Any idea to solve the problem? Cheers, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 5

[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