Re: [FSO] milestone V on GTA01 - U-Boot updates
Rask Ingemann Lambertsen wrote: >U-Boot probably needs a patch for the Neo1973 to fully work with such > cards, just like it did for the Freerunner: Someone else was working on Neo1973 SDHC support last month - see http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009499.html ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
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: 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: 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: 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: Bricked?
Armin ranjbar wrote:
> so i did connected my device to minicom , i thought that there might be
> something wrong with nand memory , i did 'erase all' and 'nand erase' ,
> then i have tried 'reset' which cause device to hang ( white screen of
> death! )
If you ran "nand erase" without specifying a partition (e.g. "nand erase
rootfs") then you have wiped out the NAND copy of u-boot and its
environment partition. You should be able to recover it using the NOR
copy of u-boot. I haven't tried this yet, but I would do something like:
- Boot from NOR u-boot (hold Aux then hold Power)
- Use dfu-util to download a new copy of u-boot into NAND ("dfu-util -R
-a u-boot ...")
- Power off
- Reboot into NAND u-boot (hold Power then hold Aux)
- Use the "dynpart", "dynenv set u-boot_env", and "saveenv" commands to
set up the NAND partition table
- Re-create the u-boot environment variables such as menu entries
- Re-flash your kernel, rootfs, and splash-screen partitions with dfu-util
The http://wiki.openmoko.org/wiki/Neo1973_Debug_Board_v2/Unbricking page
may be of interest, even though it doesn't apply directly to your situation.
You may also want to use the "neocon" terminal program instead of
minicom, since "neocon" has a per-character delay option that allows you
to copy+paste long strings into the u-boot console.
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: Revive Freerunner with USB power?
William Kenworthy wrote: > Only leaves the gsm chip (that doesnt register on the charge counter as > its directly connected to the battery, correct?) - whats it doing? The charge counter is inside the battery so it does show the current drawn by the GSM chip. Sorry, I don't know the answer to your "why does it discharge flat" question. ___ 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: 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: 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: 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: 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
:, 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: Is a 12 MB/s microSD overkill for what the glamo driver does?
Jim Colton wrote: > If anyone cares this is the card I have coming and will speed test by > using dd(1) from the device to dev/null. I wrote a small benchmark program that will measure both read and write speeds for a file. A binary is available at http://members.shaw.ca/mmontour/neo/iospeed (add a ".c" for the source). Usage is: ./iospeed . Note that measurements with this program may not be valid on a jffs2 filesystem (due to compression) but it should be OK for SD-card measurements. This thread on the Community list has some measurements from an 8G Sandisk card: http://lists.openmoko.org/pipermail/community/2008-July/021270.html ___ 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
Re: Battery discharging after long time connected to the power charger ?
Olivier Berger wrote: > I've just noticed something strange. > > If 'm not mistaken, the battry was reported discharging (whith 'apm') > while the FR was connected to the power charger (provided with the > FR). I've seen another report of this behavior on IRC. There was a similar bug reported against the Neo1973: http://docs.openmoko.org/trac/ticket/1158 , although I have not seen that behavior on my 1973. The Freerunner has a different PMU so I don't know whether or not this bug is relevant. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: gta02, 2007.2: configure what to start on boot (gsm, gps, wifi, ...); gsm special number
nick loeve wrote: > I do not know if gsmd supports sending USSD requests (which is the > protocol for these types of messages), but i do not think the dialer > knows how to do it. There's a Trac entry for USSD support - http://docs.openmoko.org/trac/ticket/1226 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: can't log into nor flash
ChandleWEi wrote: > but nothing happen > > anyone have some advice? Boot into Linux and execute "hexdump /dev/mtd0 | head". See if you get the same output that is shown in http://docs.openmoko.org/trac/ticket/1568 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
