Re: GSM Power Control
Joel B. Land wrote: http://lists.openmoko.org/pipermail/support/2008-August/001121.html What about the Freerunner? It has the same GSM chipset as the Neo1973 so there should be no difference. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GSM Power Control
Joel B. Land wrote: Is the phone’s GSM modem doing power control? [...] I can change the received field strength (rxlvl) by moving in and outside, but not the txlvl. This because the power is always the same? The phone's actual transmitted power level does change - I tested this in the past while looking at the gsm buzz problem: http://lists.openmoko.org/pipermail/support/2008-August/001121.html ___ 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: 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: Stylus
Marc Rios wrote: Anybody knows where can I buy another stylus?? http://www.dealextreme.com/details.dx/sku.849 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GTA02 is now an expensive brick / pcf50633 defaults
Andy Green wrote: There's two interesting ideas from Mike though, one is that disable USB insert as ON will help by giving longer for VB_SYS to charge and the other is leave charger enabled. For both of these, they are defeated (USB insert is ON action, charger disabled) by NOPOWER and we have no control then. I'm not considering the NOPOWER case, because as you point out there is nothing that can be done in software to help with that problem. Another software workaround for this issue is to never let the main battery drain into the cutoff state. The PMU can generate a low-battery interrupt. If the FR gets this interrupt, it can re-program the PMU with safe settings and then immediately power off the main device and the Calypso. The battery will still drain a bit from leakage current and self-discharge, but at a much slower rate. That's the simple version - more work is needed to handle cases like hot-swapping batteries while the device is plugged into external power (which could also generate a low-battery signal). There should also be an opportunity for userspace to do a clean shutdown of the device when the battery gets low, but before it reaches the critically-low level to trigger an immediate shutdown. I have not looked at any recent kernels or u-boots (for several months) to see if this has already been implemented. It's somewhere on my to-do list. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GTA02 is now an expensive brick
Gothnet wrote: I still find it amazing that the FR doesn't charge when off and empty. Every phone (and every other portable device) I've ever owned does this. It's not even a software thing - there ought to be some direct hardware way to charge the battery from totally dead without the need to even start booting. The FR's power-management chip (PCF50633) can be configured to do this, but it's not as simple as you might think. One source of complexity is the USB standard, which requires devices to negotiate their power consumption with the host computer. Another complication is a brownout problem on some phones which prevents them from booting the CPU unless a battery is present. If you program the PCF50633 as: - charger enabled - 100mA current limit - do not wake on USB insertion (avoids the brownout issue) then it will have the behaviour that you want - even with a completely-dead battery, you can plug it in and it will slow-charge the battery in hardware. I think it still technically violates one of the USB standards by drawing current without talking to the host, but IMHO it's unlikely to cause any real-world problems. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Battery discharging while plugged in
Dale Maggee wrote: Hi, currently when I have my freerunner plugged into USB, it will charge to 100% and then start (slowly) discharging. If I unplug the USB cable and plug it back in, it charges back up to 100 percent, then starts discharging again. That might be normal - the charger in the PCF50633 shuts off the charge current once the battery is full, and turns it on again when the voltage falls below a threshold. It seems that it can discharge quite a bit before charging switches back on - in one test my battery got down to around 75% before it started to charge again. The GSM modem draws current directly from the battery so this will cause the battery to discharge when the charger is off, even when the rest of the phone is powered by USB. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Battery discharging while plugged in
Angus Ainslie wrote: It doesn't completely turn off charging. It drops to a 100mA trickle charge which is insufficient to keep the battery topped up with the GSM radio turned on. That's why the batteries state of discharge is slower when its plugged into the charger ( even the wall charger ) No, it turns off the charge current. See page 86 of the PCF50633 user manual (http://people.openmoko.org/tony_tu/GTA02/datasheet/PMU/PCF50633UM_6.pdf). Battery fully charged: When the battery is fully charged and the charger is in Battery Full mode, the charge path is disabled (the USB-BAT FET is off). I've charted this by sampling the capacity, voltage_now, and current_now /sys files, but I don't have time right now to dig out that file and post it. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: using openocd
Lynn Nguyen wrote: An easily made but devastating mistake is to forget to actually activate the CPU. Just connecting power is not enough ! Press and hold the power button until the boot loader does its count-down, or, in case there is no runnable boot loader, the CPU keeps itself busy. is the 'it' this part referring to the openmoko? I mean, isn't the whole point of a bricked openmoko the fact that it can't turn on? How am I supposed to activate the CPU if it won't turn on at all? I know the battery is fully charged because I checked the voltage. it does refer to the phone. Turn it on means setting the power-management unit (PMU) into Active mode so that voltage is applied to the CPU. This might happen automatically when you plug in the USB cable, but if not you can do it by pressing the power button. If the device is bricked you will not see anything happen when you turn it on, but internally the CPU will be ready to accept a JTAG connection. Try following the sequence described at http://wiki.openmoko.org/wiki/Debug_Board_v2#Hardware_connection (which AFAIK should be the same for a v3 debug board). this is the openocd.cfg i am using: Looks OK to me. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: using openocd
Lynn Nguyen wrote: I tried the sequence but still the same errors. Should I have a /dev/ttyUSB1 when I plug in the debug board? because i dont... You should, as long as you have the ftdi_sio module loaded with the right vendor/product IDs for the debug board (0x1457/0x1458). Here's what I see when I plug in my debug board v2: usb 1-2: new full speed USB device using uhci_hcd and address 5 usb 1-2: new device found, idVendor=0451, idProduct=2046 usb 1-2: new device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-2: configuration #1 chosen from 1 choice hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected usb 1-2.1: new full speed USB device using uhci_hcd and address 6 usb 1-2.1: new device found, idVendor=1457, idProduct=5118 usb 1-2.1: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.1: Product: Debug Board for Neo1973 usb 1-2.1: Manufacturer: OpenMoko usb 1-2.1: configuration #1 chosen from 1 choice ftdi_sio 1-2.1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT2232C usb 1-2.1: FTDI USB Serial Device converter now attached to ttyUSB0 ftdi_sio 1-2.1:1.1: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT2232C usb 1-2.1: FTDI USB Serial Device converter now attached to ttyUSB1 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: updating uboot while the phone's running
robin paulson wrote: in a bid to do away with dfu and usb networking altogether - it all seems a bit clunky to be honest - is it possible to update uboot while the phone is running? It's not supported yet (AFAIK) but I think that it would be possible. It's not as easy as flashing the kernel partition because you have to write an environment offset pointer into the out-of-band data of the first flash block. This tells u-boot which block contains its environment variables, and this number is specific to each device due to bad blocks. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Support for pre-paid system notifications
Michael 'Mickey' Lauer wrote: Once I know his this works, I'll be glad to add it to the framework. Can you give me a dump of the AT commands? With my carrier (Fido Prepaid in Canada) these notifications are sent as USSD messages. http://docs.openmoko.org/trac/ticket/1226 has a couple of examples. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Can't Boot Qtopia from microSD
Andy Green wrote:
setenv bootcmd mmcinit \; ext2load mmc 2 0x3200 uImage.bin \;
setenv bootargs \${mtdparts} rootfstype=ext2 root=/dev/mmcblk0p2
console=ttySAC2,115200 loglevel=4 init=/sbin/init \; bootm 0x3200 ; boot
Notice on ext2load the first number is the partition index it should
use, counting from 1.
Minor correction - the parameter for ext2load and fatload is
device:partition, so partition 2 would be ext2load mmc 1:2
IIRC this is documented in the online help for fatload but not for
ext2load.
For troubleshooting you can also run mmcinit; ext2ls mmc 1:2 / from
the u-boot console to make sure that u-boot is able to access the
partition, and to see what files are on the card. There is also a
fatls command to look at a VFAT partition.
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: Buzzing sound
Joerg Reisenweber wrote: BS decides on this depending on signal-quality of MS as BS sees it. It would be *very* helpful to confirm this, by using some RF-meter (e.g. microwave leakage tester?), and/or reading the battery current, while observing the noise come and go- I tested this a while ago with my Neo1973, and the noise did get quieter as the RF level went down. I can't quantify this - it was just subjective observations. The test was a cheap Radio Shack microwave leakage tester and the phone sitting next to each other on my desk (not moved during the test). I covered both of them with a metal mixing bowl to block some of the RF signal. After I removed the bowl, the RF level stepped down a few times (a couple of seconds between steps) and the buzzing got quieter at each step. I didn't look at the battery current. The Neo was transmitting audio throughout this test. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Is a 12 MB/s microSD overkill for what the glamo driver does?
Jim Colton wrote: Hi Mike, I looked at the code your wrote. It doesn't do anything that 'time dd' already can do. It includes an fsync() in the timing measurement when writing the file, and does a posix_fadvise() before reading it back (both intended to make sure that the I/O is going to the device under test rather than just hitting cache memory). You can do the same things in a 'dd'-based test, but it requires a few additional steps. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: mkfs.vfat on 2007.02
Aaron Sowry wrote: However the problem as it stands currently is that there doesn't seem to be a package containing mkfs.vfat, or at least I can't find out what it is. Anyone? It's in dosfstools. You can bitbake it yourself with OE/MokoMakefile or download one that I've built from http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk Note that the Booting from SD wiki page is out of date. The newest u-boot images (20080723 or newer) are able to load the kernel from ext2/3 so you don't need a FAT partition any more. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
