Re: SD fails spectacularly and unpredictably when a SIM card is used
2009/3/16 Enrico Zini > On Sun, Mar 15, 2009 at 11:58:51PM +0100, Nicola Mfb wrote: > > >I'm experiencing the same here. > >May you post vendor/model of your SD card and the GSM operator? > > Exactly this one: > http://wiki.openmoko.org/wiki/Supported_microSD_cards/SD-C02G > > It turns out that the problem is well known, not solved, but with a few > work-arounds. Given the cost of microSD cards nowadays, it's probably > cheaper to buy a different one than it is to waste time in testing the > work-arounds. > I have problems with a Kingstone SDC4/8GB, that on that wiki page is reported as working. Are you using a Vodafone SIM? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: BrokenMoko (burnt)
Werner Almesberger wrote: > Another theory is that the bead doesn't like 1 A for extended > periods of time. But then, if this was a general problem, we'd > see more units with that issue. As far as I know, yours is the > only one that did this. > > Yet another theory (by Joerg) is that your power supply has a > lot of high-frequency ripple and the bead had to work extra-hard > to get rid of that. When the original reporter said the phone was plugged in all night - was this on the Openmoko wall charger? And what state was the phone in? Was it running Linux, suspended, off, etc? I am just wondering if this could be connected to a u-boot bug that I encountered last year (see http://lists.openmoko.org/pipermail/openmoko-kernel/2008-August/004706.html). With that issue a phone connected to the wall charger would rapidly toggle the PMU's current limit between 0 and 1A, resulting in spikes in the current drawn from the wall charger. A similar issue is the "Vsys brownout" on A5 boards with a completely dead battery (trac #1712), where the PMU tries to start up but the system draws too much current and the PMU shuts off again. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: SD fails spectacularly and unpredictably when a SIM card is used
2009/3/14 Enrico Zini > Hello, > > everything works fine if I use the FreeRunner as a PDA, without a SIM > card. However, if I put the SIM card in it, sometimes and unpredictably > the whole SD subsystem fails and I get I/O errors on any activity. > Several months ago I used to get filesystem corruption as well, but that > seems to have improved over time. > > [...] > Among the public was another FreeRunner owner who also boots from SD and > reported that he is occasionally experiencing the same problem. > > > Ciao, > > Enrico > I'm experiencing the same here. May you post vendor/model of your SD card and the GSM operator? Ciao :) Nicola ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Wifi issues in SHR-Testing
On Sun, 2009-03-15 at 19:38 +0100, Johny Tenfinger wrote: > If you want to connect with open network, you don't have to add it > manually to that file. In future shr-settings will have WiFi manager > based on FSO dbus calls. > Hopefully it will use wpa-supplicant and not go off and do something weird and non-standard like the rest of the FR. BillK ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Wifi issues in SHR-Testing
On Sunday 15 March 2009 02:38:24 pm Johny Tenfinger wrote: > If you want to connect with open network, you don't have to add it > manually to that file. In future shr-settings will have WiFi manager > based on FSO dbus calls. > wpa-supplicant is also not working, when I ran the ifup eth0 command after setting it up it ran for about a minute then gave an error about how it got no lease and it was failing and it seems to be a one shot thing because when I reran ifup it printed that the device was already configured and I can't run ifdown on eth0 and has this error: cat:: can't open '/var/run/udhcpc.eth0.pid: No such file or directory' ifconfig shows no device on my freerunner that has an IP that my DHCP server will give out. signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Wifi issues in SHR-Testing
If you want to connect with open network, you don't have to add it manually to that file. In future shr-settings will have WiFi manager based on FSO dbus calls. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: More than 7 partitions on the SD
Nicolas Dufresne writes: > Le samedi 14 mars 2009 à 18:33 +0200, Timo Juhani Lindfors a écrit : >> Why pivot_root? Modern initramfs' use chroot. > > Really ? Which distros uses that ? It's really unclean to my sense, At least debian etch (oldstable) and lenny (stable). > since you stay with two partitions mounted while you only need one and I wouldn't call tmpfs a partition. > You cannot free from ram uses for initramrfs while you could use it for Wrong, run-init removes all files from tmpfs before calling chroot(). > other work. I've checked both Gentoo and Ubuntu/Debian and they both > uses pivot_root. I have checked debian etch and lenny and they use chroot :-) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: FR works but can't charge battery
On Sun, Mar 01, 2009 at 01:31:39PM -0700, Steve Leung wrote: > Just for kicks I tried opening it up but didn't see any obvious melted > parts... hey, you never know, it might be something easily visible! Perhaps you can check this specific part? https://people.openmoko.org/werner/burntmoko-inside.jpg There shoul be no significant voltage drop across it with charger or USB host plugged in. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: More than 7 partitions on the SD [entering OT]
Pietro "m0nt0" Montorfano wrote: > If you read > that file, there are the specs about mmcblk files, major and minor > number, it's ok, nothing new, but reading that it's explained that scsi > disks devices should be at most 16 devices, am i correct? There are 16 SCSI disk devices available with major=8 but there are additional allocations at major numbers 65-71 and 128-135 for a total of 256 devices. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Help! GSM not working after updating to SHR (was: Moko10)
Am Fr 27. Februar 2009 schrieb Ingvaldur Sigurjonsson: > Me too is in the same boat. > > After having the Freerunner laying around, untouched, for quite some > time I decided to give it a new chance so I started doing some upgrades. > > I also followed the wiki on flashing the GSM but I never got the > "(fluid, version 3) ok". > > Been trying with flashing different kernels/rootfs's to no avail. I cant > even get to the phone over USB anymore. Now the Phone is completely > bricked. > > Does anyone know how to unbrick the phone ? A method using debug board > maybe ? > > Regards > - Ingi > > M. K. Pkhetan wrote: > > Hi everybody, > > > > I really appreciate your help because my phone is not any more a phone!! > > > > the story is that i have updated the GSM firmware to the Moko10 in my GTA2Bv5 as described on http://wiki.openmoko.org/wiki/GSM/Flashing > > > > I have follow exactly the instructions there on the same proposed FSO, and every thing went ok, i even got the message : > > > > (fluid, version 3) ok > > Checksumming (269 * 8kB = 2152kB): ok > > Flash Detect: (0xEC, 0x22A0) Samsung K5A3240CT ok > > Program: (34 sectors, 267*8k=2136k) (***) ok > > > > so every thing seemed ok i even tried the proposed verification : > > > > r...@om-gta02:~# cat /dev/ttySAC0 & > > r...@om-gta02:~# echo -en 'AT\r' >/dev/ttySAC0 > > r...@om-gta02:~# echo -en 'AT+CGMR\r' >/dev/ttySAC0 > > +CGMR: "HW: GTA, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal_amd8_ts0-Moko10" > > kill %1 > > > > Well, after that i went back to SHR testing, but i couldn't register to the GSM network. i tried FDOM and same thing : no registering > > > > Then i said maybe the firmware is not valid (even that i ckecked the md5sum and it was ok) so i tried to downgrade to Moko8 (the gta02bv5 one) but i stucked in "Bootloader: (reset target)" > > > > i tried the -oO and -oo. with and without the 'FLUID_FLOWCONTROL=h' and in the other season i tried the "s3c24xx-gpio b7=1", "echo 0 > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on" and "echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on" but nothing work i can't reflash my GSM anymore Please notice all this turned out to be a problem of Qi and kernel (here SHR-testing) combination, and problem with GSM has been existing prior to successful GSM-flashing. It's not related to GSM-flashing in the way OP suggests! Also it's absolutely unnecessary to use devirginator and debug-board to recover from this QI+kernel issue leaving GSM serial interface in an unusable state. Usual bootloader and/or kernel update following standard dfu-util path will suffice, as mentioned by Arne and Al in previous posts. OP asked for a method to "unbrick" FR and that's the advice Werner gave. Nevertheless OP's FR never has been bricked, and usage of devirginator or the dynpart/dynenv isn't recommended for a standard procedure. There's no way to brick FR by flashing GSM. /jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: More than 7 partitions on the SD [entering OT]
Il giorno dom, 15/03/2009 alle 12.32 +0100, Kees Jongenburger ha scritto: > > This is different in that it uses the SCSI subsystem v.s directly MMC layer. > If you put our 7+ parditioned MMC/SD card in a usb card reader you should see > you can access all the partitions. Ok, i've understood that, infact i was asking if there was a possibility to switch to scsi subsystem, but this is not the problem, i've found this http://www.lanana.org/docs/device-list/devices-2.6+.txt , referenced in the wiki page explaining how to boot from sd. If you read that file, there are the specs about mmcblk files, major and minor number, it's ok, nothing new, but reading that it's explained that scsi disks devices should be at most 16 devices, am i correct? Of course this is really OT i think, but i'm curious about that so if someone could reply ok, else, no problem. Thank you all! Pietro ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: More than 7 partitions on the SD
Le samedi 14 mars 2009 à 18:33 +0200, Timo Juhani Lindfors a écrit : > Why pivot_root? Modern initramfs' use chroot. Really ? Which distros uses that ? It's really unclean to my sense, since you stay with two partitions mounted while you only need one and You cannot free from ram uses for initramrfs while you could use it for other work. I've checked both Gentoo and Ubuntu/Debian and they both uses pivot_root. Nicolas ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: More than 7 partitions on the SD
On Sat, Mar 14, 2009 at 11:33 PM, Pietro m0nt0 Montorfano wrote: > Il giorno sab, 14/03/2009 alle 21.20 +0100, Kees Jongenburger ha > scritto: > > Hello Pietro, > > > [snip] > > This problem was also discussed on the LKML, but with no actual result > > > > http://lkml.org/lkml/2008/4/5/21 > > > > Greetings > > Thanks for the info, i'll watch that topic! > Just one question, why i've saw /dev/sdaz ? I work with storages like > SAN and some of our customer are using linux, considering a multipath > environment (1 LUN 4 path) and a multipathing software the 16 sd* device > limit is easily reached, but i'm sure that i've saw devices > like /dev/sdaz which are teorically impossible to be created reading the > spec file. It was a RHEL, various version with the default kernel and > i'm quite sure that the multipath sw didn't patch anything, so, how is > this possible? > > This is different in that it uses the SCSI subsystem v.s directly MMC layer. If you put our 7+ parditioned MMC/SD card in a usb card reader you should see you can access all the partitions. greetings ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
