Re: GSM Power Control

2009-03-23 Thread Mike Montour
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

2009-03-21 Thread Mike Montour
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]

2009-03-15 Thread Mike Montour
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)

2009-03-15 Thread Mike Montour
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

2009-01-22 Thread Mike Montour
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

2009-01-07 Thread Mike Montour
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

2009-01-05 Thread Mike Montour
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

2008-09-05 Thread Mike Montour
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

2008-09-05 Thread Mike Montour
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

2008-09-01 Thread Mike Montour
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

2008-09-01 Thread Mike Montour
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

2008-08-26 Thread Mike Montour
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

2008-08-21 Thread Mike Montour
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

2008-08-06 Thread Mike Montour
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

2008-08-05 Thread Mike Montour
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?

2008-07-31 Thread Mike Montour
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

2008-07-25 Thread Mike Montour
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