Res: Flashing NAND from NAND
On Tue, Oct 20, 2009 at 09:20:13AM -0300, Werner Almesberger wrote: Yes, DFU follows all the NAND erasing rituals properly. The rootfs is very tricky, because there you also have JFFS2 that tries to hide problems from you. Flashing the u-boot partition is also tricky because it contains a pointer to the u-boot_env partition in the OOB data. You can't simply write a U-Boot image to the u-boot partition using nandwrite and expect it to work. For your backup system, you should at least add flash_eraseall to the restore procedure. To make things work also for systems that have bad NAND blocks, you would have to use nanddump and nandwrite. (And you still have to erase explicitly - nandwrite won't do it for you.) What is the difference between nandwrite and flashcp? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Broken Freerunner.. display ok, messages.. repairable?
On Mon, Sep 28, 2009 at 08:28:57PM +0200, Thomas Franck wrote: Some moron broke my freerunner by a hard impact yesterday.. :( [snip] when I touch the screen, I get: drivers/input/touchscreen/s3c2410_ts.c:stylus_action bug. drivers/input/touchscreen/s3c2410_ts.c: stylus_updown lost event! drivers/input/touchscreen/s3c2410_ts.c: stylus_updown lost event! You could look for damage at the lower right of the screen where the four wire flat cable connects to the touch screen. Just in case it is something easy to repair. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [SHR-Unstable] swapon: swapfile has holes
On Sat, Sep 05, 2009 at 01:32:59PM +0200, Joachim Ott wrote: I wonder if dd (which is just busybox) has created a sparse file (in order to optimize for speed and space). I cannot check this, because du, which is busybox too, lacks the --apperent-size option. You can check it without a working du: $ df -h / $ rm /swapfile $ df -h / -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: How to get over Battery not charging
On Fri, Aug 21, 2009 at 04:13:14PM -0400, François-Léonard Gilbert wrote: I think CHARGE could be a nice menu option, it would lead to a text progress bar showing in real time (every 10 secs to save power) the battery status. Except for the progress bar, it is already there, only the label for the menu item reads just Power off instead of Power off and charge. The catch is that when it powers off, it will charge at no more than 500 mA even when connected to the charger. Another way to do this is to change the default action when plugging in the charger to a shut down FR for a silent charge without booting. It is supposed to do that already, but if I'm reading the code right, there are however a few cases in U-Boot where it leaves the the charger turned off: 1) If you press the power button for less than one second. 2) If you plug in a power supply other than the charger or a USB host, i.e. one that is detected as 100 mA only[1]. Over the weekend, I'll post a patch to always enable the charger and post a message here when the binary shows up at http://downloads.openmoko.org/distro/experimental/NeoFreerunner/ [1] This assumes that the 100 mA detection is works. It doesn't in the 2.6.24 and 2.6.29 kernels, for example. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: sd card?
On Tue, Aug 18, 2009 at 01:36:23PM -0700, Ali wrote: Yea, i would really appreciate that. The version I flashed is u-boot-gta02v5-1.3.1+gitr650149a53dbdd48bf6dfef90930c8ab182adb512-r1.bin which seems to be the latest, That version is a whole year old (with known problems reading ext2 partitions as well as reading from partitions above 4 GB). The latest U-Boot is git commit 57f7a4288aaa08d2dc480a923372e7a7781ce882 available at http://downloads.openmoko.org/distro/experimental/ But I am still getting the buffer i/o problem. The exact error is: [ 2489.55] glamo-mci glamo-mci.0: Error after cmd: 0x8120 [ 2489.56] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x400b00 [ 2489.57] end_request: I/O error, dev mmcblk0, sector 31 [ 2489.57] Buffer I/O error on device mmcblk0, logical block 3 That's a kernel error which shouldn't be affected by upgrading U-Boot or qi. Please provide the output of $ cat /proc/version $ cat /proc/cmdline -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: sd card?
On Tue, Jul 21, 2009 at 07:47:45PM -0400, Seth Rothenberg wrote: I can't access my SD card. [...] Apologies for not spotting the mistake until now, but: r...@om-gta02 ~ $ fdisk /dev/mmcblk0 Unable to open /dev/mmcblk0 You need to run fdisk as root to access /dev/mmcblk0. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: unable to enumerate USB device on port 1
On Wed, Jul 22, 2009 at 10:13:57AM +0200, Thomas des Courières wrote: me again, it is definitely the sd card which is causing the problem : removing it allows the phone to start whithout any error and to connect it through usb. I also noticed that with the sd card, the system time is borked. How do you know it is borked? But if booting without the sd card, the correct date and time is back again. With the SD card in, Are you booting from the SD card? /proc/cmdline will tell you, e.g. in $ cat /proc/cmdline console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot mtdparts=physmap-flash:-(nor);neo1973-nand:0x0004(u-boot),0x0004(u-boot_env),0x0080(kernel),0x000a(splash),0x0004(factory),0x0f6a(rootfs) root=/dev/mmcblk0p2 rootdelay=0 ro the root=/dev/mmcblk0p2 shows that I booted from the SD card. It would be /dev/mtdXXX if I booted from flash ROM instead. Are you using qi as your bootloader? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: sd card?
On Tue, Jul 21, 2009 at 07:47:45PM -0400, Seth Rothenberg wrote: I can't access my SD card. Does anyone have suggestions beyond testing it in another device? (I am working on that) I am not 100% sure that it has worked at all since I got it back from buzzfix center. The card might have come loose in transport. Try taking it out and putting it back in. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[Debian/Xorg glamo] Power leak in X server blanker
The DPMS support in the Xorg glamo video driver turns _on_ the display
refresh after 20 minutes, which increases current draw by about 38 mA.
On a sunny day, I found that with the display supposedly blanked and
sunlight hitting the display at just the right angle, I could see the cursor
blinking in a terminal window and the LXDE clock updating. I.e. display
refresh was enabled with no backlight, thereby wasting power. And measuring
battery current over time confirmes it:
# echo /sys/class/power_supply/usb/device/usb_curlim 0
$ for i in {' ',1,2,3,4,5}{0,1,2,3,4,5,6,7,8,9}; do \
echo -n After ${i} minute(s): ; \
cat /sys/class/power_supply/battery/current_now ; \
sleep 60; \
done
After 0 minute(s): 178125
After 1 minute(s): 41625
After 2 minute(s): 40312
After 3 minute(s): 40125
After 4 minute(s): 40125
After 5 minute(s): 40312
[...]
After 15 minute(s): 39937
After 16 minute(s): 39937
After 17 minute(s): 40125
After 18 minute(s): 39937
After 19 minute(s): 39937
After 20 minute(s): 39937
After 21 minute(s): 78000
After 22 minute(s): 78000
After 23 minute(s): 78000
After 24 minute(s): 78000
[...]
After 56 minute(s): 78562
After 57 minute(s): 78562
After 58 minute(s): 78562
After 59 minute(s): 78750
The culprit would appear to be the X server DPMS support:
$ xset -display :0 -q
Keyboard Control:
auto repeat: onkey click percent: 0LED mask:
auto repeat delay: 500repeat rate: 30
auto repeating keys: 00ffdbbf
fadfffdfffdfe5ef
bell percent: 50bell pitch: 400bell duration: 100
Pointer Control:
acceleration: 2/1threshold: 4
Screen Saver:
prefer blanking: yesallow exposures: yes
timeout: 600cycle: 600
Colors:
default colormap: 0x20BlackPixel: 0WhitePixel: 65535
Font Path:
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,built-ins
DPMS (Energy Star):
Standby: 1200Suspend: 1800Off: 2400
DPMS is Enabled
Monitor is On
Suggestion: Add this
xset -dpms s off
to your ~/.xsession because with FSO already managing display power, there's
no benefit from the X blanker or X DPMS support. The improvement is
as expected:
$ for i in {' ',1,2,3,4,5}{0,1,2,3,4,5,6,7,8,9}; do \
echo -n After ${i} minute(s): ; \
cat /sys/class/power_supply/battery/current_now ; \
sleep 60; \
done
After 0 minute(s): 165000
After 1 minute(s): 41437
After 2 minute(s): 41062
After 3 minute(s): 39375
After 4 minute(s): 39562
After 5 minute(s): 39375
After 6 minute(s): 39187
[...]
After 53 minute(s): 38437
After 54 minute(s): 38625
After 55 minute(s): 38625
After 56 minute(s): 38812
After 57 minute(s): 38625
After 58 minute(s): 39000
After 59 minute(s): 40312
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: Om2009 testing release 5
On Tue, Jun 16, 2009 at 11:24:06AM -0600, Angus Ainslie wrote: Hi All, There have been some major show stoppers fixed in the last week. As usual there are additional instructions here. http://wiki.openmoko.org/wiki/Om2009 The version of u-boot you point to is nearly 10 months old (2008-08-08). Please upgrade to the latest version. See http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=refs/heads/stable Also please say which branch you are building the kernel from so the most critical patches from andy-tracking can be applied. (Or just switch to andy-tracking. :-) -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Freerunner won't boot: dies in uboot
On Sat, Jun 27, 2009 at 02:17:41PM +0200, David Fokkema wrote: My understanding is that the boot loader does _not_ enable charging. It does. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [OM2009] Testing 2009-06-11: Misreading hardware clock
On Sun, Jun 14, 2009 at 05:09:16PM +0200, Joerg Reisenweber wrote: If setting hwclock is done with same month off by 1 algo you use for reading it, you probably only will notice your months have wrong number of days (RTC counting to 31. for July (May?), readout algo says June 31.) The kernel refuses to read the RTC when the date is invalid. Thus, you will see failure to advance kernel time across suspend/resume or kernel time starting at 1970-01-01 UTC when booting. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Need help! FR seems to be dead cold!
On Tue, Jun 09, 2009 at 07:06:21PM +0400, Ilya Platonov wrote: My FR just couldn't power up in both NAND and NOR alike. Absolutely no sign of life. Prior to that i flashed the NAND nandwrite -p /dev/mtd1 u-boot.bin and shutdown, but this couldn't ruin the NOR afaik. Doing so will clobber the pointer to u-boot_env in NAND flash, so don't do that. Use U-Boot and dfu-util to flash /dev/mtd1. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[OM2009] Testing 2009-06-11: Misreading hardware clock
Out of curiosity, I had a look at OM2009: # flash_eraseall /dev/mtd6 # wget --no-verbose \ http://downloads.openmoko.org/distro/testing/daily/NeoFreerunner/fso-paroli-image-om-gta02.jffs2 \ -O - | nandwrite -p /dev/mtd6 - # flash_eraseall /dev/mtd3 # wget --no-verbose \ http://downloads.openmoko.org/distro/testing/daily/NeoFreerunner/uImage-2.6.28-stable+gitr0+f19f259d3c1afde8eae53983fd19f61831927413-r2-om-gta02.bin \ -O - | nandwrite -p /dev/mtd3 - The screen says 16:53 Monday, July 13, 2009. That makes it exactly one month ahead of time. The 2.6.28 kernel needs a backport of these two patches: http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=60c66130a4467ca2a2994a6e3d7d5ac63839eefb http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=cc1663fc922c03feb0d7bbb8b18d62fbac0128de -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Finding a recent U-Boot (Was: Om2009 testing release 4)
On Mon, Jun 01, 2009 at 04:50:12PM +1200, Robin Paulson wrote: this is more about predicting where qi will go in future, than where it is now. and various people from om have talked about qi being the way forward. i imagine there will be no more significant changes to uboot from here onwards, whereas qi will steadily improve. i might be wrong Those same people also don't work for OM any more, so the amount of time they have available for qi work could be very limited. Andy said he'd keep working on qi[1], but we haven't seen any of it yet. Likewise we haven't yet seen much of what I said I'd work on for U-Boot[2][3] either. Judge by what people _actually_ do rather than what they say they'll do. [1] https://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009584.html [2] https://lists.openmoko.org/pipermail/openmoko-kernel/2009-April/009827.html [3] https://lists.openmoko.org/pipermail/openmoko-kernel/2009-April/010007.html -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Finding a recent U-Boot (Was: Om2009 testing release 4)
On Tue, May 26, 2009 at 07:55:31PM +1200, Robin Paulson wrote: i think the critical thing is that you are using a *recent* version of whichever bootloader, be it uboot or qi http://wiki.openmoko.org/wiki/Om2009#Installing Unfortunately, the U-Boot download link points to an ancient (8 months old) version of U-Boot. The latest U-Boot is here: http://downloads.openmoko.org/distro/experimental/NeoFreerunner/ that said, i'm sticking with qi, and development there looks much more active. Not much difference: U-Boot: Two commits in the last two months. [1] qi: Three commits in the last two months. [2] [1] http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=refs/heads/stable [2] http://git.openmoko.org/?p=qi.git;a=shortlog;h=refs/heads/master there's no incentive i can see to stay with uboot Other than being able to flash a new boot loader. :-) -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: disassembling the device?
On Sat, May 02, 2009 at 03:43:24PM +0200, Dr. H. Nikolaus Schaller wrote: http://wiki.openmoko.org/wiki/Disassembling_Neo1973 It is the same for the Neo Freerunner As to the part about bending the side of the back cover away from the headphone connector, I found that it works relatively easily if you insert a small (1.6 mm) flat head screwdriver between the headphone connector and the PCB retaining clip right next to it. To the other side of the headphone connector is a white plastic spacer that you might damage if you insert the screwdriver there. And when you lift the side of the PCB, check that the Bluetooth module clears the battery compartment before you move the PCB sideways. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: The myth of missed phone calls (was: OM2008.12 - basic usage instructions?)
On Wed, Apr 22, 2009 at 11:08:14PM -0400, Paul wrote: The distro I've used that missed phone calls the most was FSO, zhone was pretty unstable. But I have missed calls on SHR and OM2008.12. OM2008.12 has terrible echo and is unusable last I tried. If there were new patches since Feb, I'll be out of date. I had to get a real phone because I couldn't use my freerunner. There was a GSM firmware bug such that you would miss all calls during the first suspend after a reboot or power on[1]. It will happen when the firmware is moko10 or older and your kernel is older than 2009-02-22. Later kernels include a workaround[2] for the firmware bug and the moko11 firmware[3] from 2009-02-24 fixes the bug. [1] https://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008497.html [2] https://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008832.html [3] https://people.openmoko.org/joerg/calypso_moko_FW/moko11/ -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Wrong size reported on SD Card
On Sat, Apr 18, 2009 at 09:47:14AM -0700, Daemon D wrote: Appears there is no blockdev command. I've never heard of it before either. Do you have hdparm? $ /sbin/hdparm -g /dev/mmcblk0p3 /dev/mmcblk0p3: geometry = 52688/4/16, sectors = 2097152, start = 12424193 -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[Debian] Clock problems across suspend/resume. Apmd considered harmful?
] pcf50633 0-0073: Masking IRQ 7 Mar 25 23:00:28 debian-gta02 kernel: [32953.39] pcf50633 0-0073: Masking IRQ 7 Mar 25 13:02:51 debian-gta02 kernel: [33006.645000] fbcon_event_notify action=9, data=c7b9bde0 And here we see user space setting the system clock from the hardware clock, that is suspend time. So, who might be the culprit? It looks like apmd does this: # ls -l /etc/apm/resume.d /etc/apm/suspend.d /etc/apm/resume.d: total 0 lrwxrwxrwx 1 root root 20 Dec 25 20:27 00hwclock - ../scripts.d/hwclock lrwxrwxrwx 1 root root 17 Dec 25 20:27 20alsa - ../scripts.d/alsa /etc/apm/suspend.d: total 0 lrwxrwxrwx 1 root root 17 Dec 25 20:27 80alsa - ../scripts.d/alsa lrwxrwxrwx 1 root root 20 Dec 25 20:27 99hwclock - ../scripts.d/hwclock I guess the systems suspends before apmd gets to run the hwclock script. When the system resumes, the script continues, setting the clock backwards. Suggested fix: Stop and disable apmd: # /etc/init.d/apmd stop # update-rc.d -f apmd remove # update-rc.d apmd stop 20 0 1 2 3 4 5 6 . Btw, it is zhone that brings in apmd as a dependency. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: No GSM. Suspect dead Calypso. What to do?
On Fri, Apr 10, 2009 at 08:17:17PM -0700, danek wrote: 4. Since it took a while to get socat sorted, and I wasn't sure what you meant when you said Calypso goes to sleep very fast (goes to sleep after being powered on? in between commands? didn't know.) Both. Also, from the GSM 07.07 document: 9.1 Report Mobile Equipment error +CMEE [...] Defined values n: 0 disable +CME ERROR: err result code and use ERROR instead 1 enable +CME ERROR: err result code and use numeric err values (refer next subclause) 2 enable +CME ERROR: err result code and use verbose err values (refer next subclause) The first few commands to send are these: AT AT%SLEEP=2 ATE1 AT+CMEE=2 Me: AT+COPS Neo: AT+COPS OK AT-Command Interpreter ready //It looks like it reset itself. I try dialing anyway... Perhaps the modem loses power? Which power sources are you connecting (charger/USB/battery)? Does the battery connector and the battery both have clean contact points? Are you using a battery of the same length as the original battery? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO] milestone V on GTA01 - U-Boot updates
On Tue, Apr 07, 2009 at 02:41:17AM +0200, Peter Rasmussen wrote: I would love to do some testing, and I have a 6GB micro-SD dedicated for it, but I have no access to a debug board, so if I brick my Neo1973 I'm screwed :-) However, if you do have a debug board, and you live in the neighborhood of Copenhagen we could work something out. I live in Rødovre. No, I don't have a debug board either. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Device somehow powered down - would not power up again
On Sat, Mar 28, 2009 at 11:23:17PM +0100, Michael 'Mickey' Lauer wrote: Correct. This will be fixed with the new combined battery object that aggregates the information from various power sources. If noone beats me to it, I'll try to get it done after OpenExpo. Btw, (how) will FSO handle the case where two batteries show up in /sys/class/power_supply? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Device somehow powered down - would not power up again
On Sun, Mar 29, 2009 at 02:37:37PM -0400, Stefan Monnier wrote: FR is not expected to work without battery. That's technically impossible basically. GSM will take 2A in spikes, and usb can deliver max 500mA, from What about running the FR without using GSM? Works fine for me. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Device somehow powered down - would not power up again
On Sat, Mar 28, 2009 at 01:31:56PM +0100, Sebastian Spaeth wrote:
USB only delivers 100mA until a higher rate is negotiated. But for this
to happen you need to have the kernel and the usb drivers loaded
already, so it is kind of difficult. And the FR uses more than 100mA
when booting.
USB ports are not just USB ports. I have a PCI card with USB ports that
provide around 600 mA while the ones on the motherboard provide only around
300 mA (and generally work poorly with the FR). My FR without battery boots
and runs fine off the PCI card USB ports.
Btw, there's an FSO bug which means that distributions based on FSO won't
work without a battery unless you comment out this part of
/etc/freesmartphone/oevents/rules.yaml:
-
trigger: PowerStatus()
filters: HasAttr(status, empty)
actions: Command('poweroff')
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: Solar Moko Idea
On Thu, Feb 19, 2009 at 09:11:24AM -0700, Brad Midgley wrote: The cell would need to be isolated from the rest of the phone to keep the battery cool. If the battery gets warmed up from proximity with the cell, it will be too hot to be safely charged. Why would the battery get hotter _with_ the solar panel than _without_ it? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Solar Moko Idea
On Thu, Feb 26, 2009 at 12:20:58PM -0500, Paul wrote: Brad, How much does the openmoko need to run in standby? About 8 mA in standby or 55 mA idle with screen blanked. Add around 34 mA on top of that for the GSM modem (with deep sleep disabled). http://www.mountainwindandsun.com/sili16635.html Note that the 5.5 V it supplies as minimum is the absolute maximum rating for the Freerunner. It would be better with something in the range of 4.4 V - 5.3 V, although if you don't need to be able to keep the battery charged, 3.6 - 3.7 V ought to be enough. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Broken Screen
On Mon, Feb 16, 2009 at 01:55:19AM -0700, Matthias Stone wrote: 1. If it's possible to just puchase a new screen Yes, at least Trisoft sells screens separately. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Updating an old GTA01 (Neo 1973)
On Mon, Feb 16, 2009 at 11:44:53AM +0100, Tilman Baumann wrote: I also read about a GSM firmware upgrade which I may need. Only in case of incompatibilities with certain SIM I believe. Especially on the GTA01 with only 16 byte serial port buffers you may want to upgrade to the moko11 firmware to fix some problems with serial port overruns (bug 2180) due to hardware flow control not being used: https://docs.openmoko.org/trac/ticket/2180#comment:20 https://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008648.html Also fixed is resume on call during first suspend (bug 2231): https://docs.openmoko.org/trac/ticket/2231 https://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008497.html -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: OM 2008.x networking problems
On Sun, Feb 22, 2009 at 08:38:38PM +0100, joris...@gmx.net wrote: Hey guys, Ok. I upgraded from 2008.9 to 2008.12. Issues on the 2008.9: - unable to get on the internet through usb networking although it was possible to ssh into root. I followed the usb networking guide on the wiki, more specifically for Ubuntu 8.10. (Error message after attempting e.g. opkg install openmoko-terminal2: 'An error occured: return value:2.') After flashing on the 2008.12 image (kernel + rootfs): - unable to access the internet through usb networking. ssh into root still works as before. Error message when attempting opkg install has changed into: 'Could not obtain administrative lock' (although once I got the 'An error occured: return value:2.' again which I was not able to reproduce). It's in the Wiki somewhere: Missing or incorrect /etc/resolv.conf. Look at the one on your desktop computer. Also try these two commands: $ ping -c 3 88.198.124.202 Failure means routing/NAT problem. $ ping -c 3 www.openmoko.com Failure means DNS problem (assuming the first one worked). -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Audio Buzz / Rattling Issue
On Sun, Feb 08, 2009 at 12:00:23PM +, Al Johnson wrote: 2008.x does not change the mixer state on headset jack insertion or removal, but the kernel does create an input event that would allow it to do so. FSO should switch from speaker to headset, but this isn't extensively tested and may be buggy. It works fine on Debian, which uses FSO. IMHO: Forget OM2008.x and go with a distributions which builds on FSO. Please see URL:https://wiki.openmoko.org/wiki/Distributions. The 'buzz' that most reports refer to is heard during phone calls by the person on the far end of the call, not on the FR itself. The buzz you hear seems like either a distortion from the media player or a mechanical issue in the speaker of your unit. You can get distortion by maxing out all the volume settings (e.g. both PCM and Headphone). -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: OpenMoko Webcam - guvcview bug fix
On Sun, Jan 25, 2009 at 11:04:31PM +, Paulo Assis wrote: Thank you. Removed packed attribute from all struts, except imaged headers. Changes commited to svn, will be available in the next release (0.9.8), in a week or so -:). I built a binary package of guvcview 0.9.8: http://nospamnospam.homepage.dk/software/download/guvcview_0.9.8-ubuntu1_armel.deb -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: OpenMoko Webcam
On Tue, Jan 20, 2009 at 12:52:14AM +0100, Neil Benn wrote: Hello, Okay, dealing with the low resolution I thought that it could be something to do with the odl pcw/pcwx issue for philips webcam drivers. At least for the Logitech cameras, it apperears to be a hardware limitation. There just isn't buffer space in the camera to hold an image: http://forums.quickcamteam.net/showthread.php?tid=255 So I tried to install that, however the install instructions don;t work - the patch file bombs out and I'm not _totally_ sure how to correct the flaw manually. Basically the patch file seems to not reflect the directory structuire of the 2.6.24 kernel. Before you spend more time on that, check which driver it uses. E.g. mine: $ head -v /sys/class/video4linux/video*/name == /sys/class/video4linux/video0/name == UVC Camera (046d:0991) -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: OpenMoko Webcam - guvcview bug fix
On Wed, Jan 14, 2009 at 12:27:03AM +0100, Rask Ingemann Lambertsen wrote:
1) Guvcview on Debian/armel has problems. It saves a corrupt config file,
preventing it from starting again unless you delete the config file. It also
saves a corrupt AVI capture file. It works fine on Fedora/x86. I haven't yet
tried other video programs.
(For the impatient, see patch at the bottom.)
The config file corruption was in these two lines:
# video resolution
resolution=352x288
# control window size: default 575x610
windowsize=480x588
Instead of the proper values, there was junk for 288, 480 and 588. My
first thought was an endianess problem, but the Neo runs the ARM in little
endian mode, which is the same endianess as the x86. But still, it looked
very much as if something was writing to the wrong address, clobbering
adjecent fields in the configuration. In src/globals.h:
int width;
int height;
int winwidth;
int winheight;
A bit further up, it says:
DWORD framecount;
unsigned char frmrate;
short Sound_enable; /*Enable Sound by Default*/
int Sound_SampRate;
There's supposed to be a hidden, one byte pad field after the 'frmrate'
field so 'Sound_enable' is naturally aligned. However, the structure has
'__attribute__ ((packed))' which prevents such pad fields from being
inserted by the compiler. The following fields will then be misaligned.
Misaligned fields are handled, with a performance penalty, by either the
compiler or the CPU. On x86, the CPU handles it while on ARM, the compiler
handles it. The latter fails for guvcview because of this line in
src/close.c:
gtk_window_get_size(GTK_WINDOW(gwidget-mainwin),(global-winwidth),(global-winheight));//mainwin
or widget
gtk_window_get_size() will of course assume that it is passed properly
aligned pointers. And sure enough, this patch (against guvcview 0.9.5) makes
the problem go away:
--- src/globals.h~ 2008-11-08 00:43:18.0 +0100
+++ src/globals.h 2009-01-25 17:29:59.0 +0100
@@ -103,7 +103,7 @@ struct GLOBAL {
unsigned int jpeg_bufsize; /* width*height/2 */
int autofocus;/*some autofocus flags*/
int AFcontrol;
-} __attribute__ ((packed));
+} /* __attribute__ ((packed)) */ ;
/*- prototypes
*/
int initGlobals(struct GLOBAL *global);
Guvcview then saves a working config file on exit and the AVI files it
saves can be played back (tested with mplayer).
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: OpenMoko Webcam
. Suggestions are welcome, since I would like to be able to capture still images of higher resolution, preferably uncompressed. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
