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
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
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 t
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 powe
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
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 nee
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
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 yo
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 char
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 charg
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 wha
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
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 kern
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
ex
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 i
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 wh
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
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
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:
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 a
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
___
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@li
24 matches
Mail list logo
