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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
