Re: SD not detected when installing to sheevaplug
Try re-downloading the installer, that solved the modules problem for me. On Jul 17, 2010 4:55 PM, Carles Pagès bona...@gmail.com wrote: I'm trying to install debian lenny to a sheeva plug following the instructions on Martin's page. When the installer finishes the hardware detection, I get an error stating that no partitionable media was found. I have an SD card in the slot, which I previously had used with a debian tarball (so it should work). Has anyone experienced something similar? During the installation I received a warning that no modules were found for the current kernel? Is this normal or could it be the cause of the error I'm getting? Thanks -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin87cfyyzocag_eeetssyrflmajqtk3rk9_6...@mail.gmail.com
Re: SD not detected when installing to sheevaplug
No luck. The installer hasn't changed since yesterday, so I had few expectations. 2010/7/18 Björn Wetterbom bj...@wetterbom.se: Try re-downloading the installer, that solved the modules problem for me. On Jul 17, 2010 4:55 PM, Carles Pagès bona...@gmail.com wrote: I'm trying to install debian lenny to a sheeva plug following the instructions on Martin's page. When the installer finishes the hardware detection, I get an error stating that no partitionable media was found. I have an SD card in the slot, which I previously had used with a debian tarball (so it should work). Has anyone experienced something similar? During the installation I received a warning that no modules were found for the current kernel? Is this normal or could it be the cause of the error I'm getting? Thanks -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin87cfyyzocag_eeetssyrflmajqtk3rk9_6...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiki49ylbwxkxoin3hbomo_k5pilfxuuh_lt8...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Fri, Jul 16, 2010 at 09:46:29AM +0200, Loïc Minier wrote: On Fri, Jul 16, 2010, Hector Oron wrote: to take it as another architecture, but, nowadays, arm-none-linux-gnueabi supports hard, soft and softfp. Bringing old discussions up to front, would not make sense to have ABI support in the distribution itself (which really is an overhead) and not in the upstream code? We need a new port because the binaries are incompatible with each others, we need a different triplet because it's a dpkg limitation. Perhaps we could change dpkg to not require that anymore, but we'd still need a new port. We also need a different triplet for the multiarch use case; I know you're not too interested in multiarch yourself anymore, but it's safer to pick a different triplet nevertheless IMHO, using the vendor field. I'm puzzled why dpkg needs a unique triplet for a port. dpkg needs to map port names to triplets, but why does it need to do the inverse? And if it doesn't need to map triplet-port, why would the triplet need to be unique? There is a need for a distinct port name; I think this is also not a Debian-specific problem, it's a problem common to any distributions that want to do what's described here. Paul commented that: Anything that relies on the target triplet is going to break as soon as you move outside a pure Debian system. i.e. any patches relying on a particular target triplet are inherently Debian specific, and IMO should never be pushed upstream. But, er, relying on the target triplet for this shouldn't be done in Debian, either! FWIW, this discussion ties in with one of the known outstanding issues with multiarch, namely we want to support coinstallation of libraries optimized for multiple /compatible/ instruction sets. And we don't want to have to add /lib/i386-linux-gnu, /lib/i486-linux-gnu, /lib/i586-linux-gnu [,...] to the path one by one to accomplish that, especially when we already have hwcaps to do the job for us. So perhaps triplets aren't the right level of abstraction to encode in the library paths after all? I mean, it's ok to have libraries in /lib/i486-linux-gnu/686/cmov, but we definitely don't want to *change* the library path if and when Debian's base compatibility level moves from i486 to i586 (or from armv4t to armv5t, to keep this on topic ;) and have to deal with path transitions. Is there a better identifier we should be using to qualify the library paths, instead of these triplets? I.e., instead of the cpu from the triplet, perhaps there are official names for the ELF architectures that can be used - that can be determined without too much hard-coding all over the place? (BTW... if you want to run both armel and armhf under multiarch... which package's libc gets to own ld.so? :P) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
RE: E220 Modem
I just tried another stick dmesg [42949380.27] usb 1-2: New USB device found, idVendor=0af0, idProduct=7401 [42949380.28] usb 1-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [42949380.28] usb 1-2: Product: Globetrotter HSUPA Modem [42949380.29] usb 1-2: Manufacturer: Option N.V. lsusb Bus 001 Device 002: ID 1bcf:0c31 Sunplus Innovation Technology Inc but that was not detected by wvdial so I installed usb-modeswitch and got dmesg [42950500.55] usb 1-2: new high speed USB device using ehci_hcd and address 4 [42950500.70] usb 1-2: configuration #1 chosen from 1 choice [42950500.71] scsi2 : SCSI emulation for USB Mass Storage devices [42950500.72] usb 1-2: New USB device found, idVendor=0af0, idProduct=7501 [42950500.73] usb 1-2: New USB device strings: Mfr=2, Product=1, SerialNumber=3 [42950500.74] usb 1-2: Product: Globetrotter HSUPA Modem [42950500.74] usb 1-2: Manufacturer: Option N.V. [42950500.75] usb 1-2: SerialNumber: Serial Number [42950500.75] usb-storage: device found at 4 [42950500.75] usb-storage: waiting for device to settle before scanning [42950505.75] usb-storage: device scan complete [42950505.75] scsi 2:0:0:0: CD-ROMZCOption HSUPA Modem PQ: 0 ANSI: 2 [42950506.42] Driver 'sr' needs updating - please use bus_type methods [42950506.44] sr0: scsi-1 drive [42950506.44] Uniform CD-ROM driver Revision: 3.20 [42950506.45] sr 2:0:0:0: Attached scsi CD-ROM sr0 [42950506.86] sd 0:0:0:0: Attached scsi generic sg0 type 0 [42950506.87] sr 2:0:0:0: Attached scsi generic sg1 type 5 lsusb Bus 001 Device 004: ID 0af0:7501 Option Globetrotter HSUPA Modem (icon 411 aka Vodafone K3760) But it's still not detected by wvdialconf? Date: Sat, 17 Jul 2010 12:01:08 + Subject: Re: E220 Modem From: l...@lkcl.net To: brianpl...@hotmail.com CC: debian-arm@lists.debian.org i'm using an E156G for three.co.uk and a K3565 for vodafone, you _must_ have approx a 2.6.24 or greater kernel, and the following wvdial.conf works perfectly. make sure you look up and have the appropriate IP setting, can't remember its official name. also try using a powered USB2 high-speed hub. _powered_ hub. l. [Dialer three] Phone = *99***1# #Username = web #Password = web #Stupid Mode = 1 Dial Command = ATDT Modem = /dev/ttyUSB0 Baud = 460800 Init2 = ATZ Init3 = ATE0V1D2C1S0=0+IFC=2,2 ISDN = 0 Modem Type = Analog Modem Init5 = AT+CGDCONT=1,IP,three.co.uk; [Dialer vodafone] Phone = *99***1# Username = web Password = web Stupid Mode = 1 Dial Command = ATDT Modem = /dev/ttyUSB0 Baud = 460800 Init2 = ATZ Init3 = ATE0V1D2C1S0=0+IFC=2,2 ISDN = 0 Modem Type = Analog Modem Init5 = AT+CGDCONT=1,IP,pp.internet; On Sat, Jul 17, 2010 at 8:16 AM, Brian Platt brianpl...@hotmail.com wrote: I've been trying for ages to try and get my T-Mobile E220 modem working on my Linksys NSLU2 but I can't for love nor money and hoping someone on here can help me, here's some info -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktil4fkl_xvbfh5frmg4akjgxqhpzcyl1vydz4...@mail.gmail.com _ http://clk.atdmt.com/UKM/go/19780/direct/01/ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Sun, Jul 18, 2010, Steve Langasek wrote: (BTW... if you want to run both armel and armhf under multiarch... which package's libc gets to own ld.so? :P) I understand ld.so can be wherever we want, since it's part of the executables, but I understand you're asking which architecture gets to own whatever /lib/ld-linux.so.2 is, since there's only one of them and we want to preserve compatibility with non-Debian binaries, right? On my amd64 system, /bin/rm points at /lib64/ld-linux-x86-64.so.2 for an interpreter (*cough* /lib64) but on an armel system, it points at /lib/ld-linux.so.3, and on i386 system /lib/ld-linux.so.2 so perhaps we can expect 64-bits arches to have a suffix while 32-bits arches so that one could leave ld-linux to 32-bits arches and use the suffix for 64-bits arches? No idea whether there's a general rule for this -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100718194011.ga25...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Sun, Jul 18, 2010 at 09:40:11PM +0200, Loïc Minier wrote: On Sun, Jul 18, 2010, Steve Langasek wrote: (BTW... if you want to run both armel and armhf under multiarch... which package's libc gets to own ld.so? :P) I understand ld.so can be wherever we want, since it's part of the executables, but I understand you're asking which architecture gets to own whatever /lib/ld-linux.so.2 is, since there's only one of them and we want to preserve compatibility with non-Debian binaries, right? On my amd64 system, /bin/rm points at /lib64/ld-linux-x86-64.so.2 for an interpreter (*cough* /lib64) but on an armel system, it points at /lib/ld-linux.so.3, and on i386 system /lib/ld-linux.so.2 so perhaps we can expect 64-bits arches to have a suffix while 32-bits arches so that one could leave ld-linux to 32-bits arches and use the suffix for 64-bits arches? No idea whether there's a general rule for this It's not a general rule. For example, 32-bit sparc is /lib/ld-linux.so.2 while 64-bit sparc is /lib64/ld-linux.so.2. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100718235614.ga4...@volta.aurel32.net
