Re: unable to start up freerunner after batterie was full down
Am Mo 14. Juli 2008 schrieb Marco Trevisan (Treviño): Joerg Reisenweber wrote: Am Mo 14. Juli 2008 schrieb Marco Trevisan (Treviño): Michael Shiloh wrote: The final method involves charging the battery manually, enough to allow Freerunner to boot. This requires an external power supply of about 4.5 Volts and should be done only if you feel comfortable with electronics and hardware and understand about short circuits. Let me know if you want to do this and I'll instruct you privately. Well, maybe this could be useful for other owners, isn't it? We mustn't advice customers to try potentially destructive or even dangerous procedures. Thus no public howto for manual charge of LiIon batteries! Well, I don't think that one would to that just for fun... I figure that who will try a procedure like that is enough experienced and/or wants to risk with his own device. I'm simply saying that the method should be well documented in public (since it's not the first time that occurs) underlining that it's only a very dangerous tip and that the Om team doesn't suggest it, then everyone can decide if following it. PS: BTW I hope I won't use it since I've ordered also some extra an battery and I've some compatible ones near me; I just wanted to express my idea... Actually I don't recommend this, not even with warning note. There are better ways do cope with this: hotswap or external LiIon charger/other cellphone. Battery has max chrg V of ~4.2V and max I of ~1A. Anybody needing to know more on it, shouldn't even think about it. The ones who think they understood the above: formating charge current when bat is deeply discharged shouldn't even exceed 50~100mA! Otherwise U might kill bat. LiIon is tricky! /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unable to start up freerunner after batterie was full down
Am Mo 14. Juli 2008 schrieb Ben Wilson: So the freerunner doesn't suffer from the problem in gta01 of squealing (and potential damage) if you remove the battery while it's charging? No reports so far. Seems we fixed that ;-) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't boot Freerunner without battery - Was: Re: unable to start up freerunner after batterie was full down
Am Mo 14. Juli 2008 schrieb Steven **: Perhaps it's been said before and I missed it... But why can't the Neo boot off USB power alone? Boils down to sth like powering up a whole town after blackout. All components drawing a spike of energy same moment, which USB can't deliver. -next blackout. Werner's new U-boot extenuates this somewhat, but as much of this is inside PMU hardcoded, SW can't do much. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Better keyboard?
Marco Trevisan (Treviño) wrote: In Ubuntu I had to install libfakekey-dev to compile. However I've also ported and applied the thseiler's popup patch to this version (I could attach it somewhere if you want, but it's still incomplete since it's show only the clicked letter on a small pop-up window). I'd like also to redesign it a little, to gain a bit more space while my FR is coming... :P I got it to work under Ubuntu although it causes all my open windows to get squished. What are you using to build it? the toolchain or mokomakefile? Because when I try to build it using the toolchain there are a bunch of missing x libraries, which are not in the toolchain. Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Hello, I've only had my freerunner for a week or so, so I'm not too into the security aspects yet. One thing I did notice was of course passwordless root login. Now over usb this can be acceptable, but if this is possible over wifi (I haven't actually tested), it needs the firewall / make it listen only to the usb. In addition to that, a separate encrypted partition for /root (or /home if the account will changed to a non-privileged user) could be nice, but maybe too heavy and battery draining? In addition to that, I'd say all linux security administration best practices should be at least considered, including automatic security updates. After the basic security is in good shape, one could move on to fun things like phone lock/unlock/shutdown with an sms, personal data backups / remote removal... the possibilities! :) Cheers, Kalle Yorick Moko wrote: This mail was posted on the devel list (http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html). Thought it would interest a lot of people who are not subscribed to that list: Hi Guys, a few months ago we have planned to improve the security of our beloved Neo, after we have read about desires of the community regarding to the security issue. And here we are. Today I will present you our project MokSec. What is MokSec? === MokSec is framework which target is to improve the security of the mobile devices which are based on OpenMoko (and other frameworks which are running on Neos) What is our main focus at the moment? = The main focus is the encryption over GSM. This is very complicated issue and for this we searching developer which are willing to work with us on this interesting project. What are the other components? == At the moment we only working on a phone firewall, which will be blocking/accepting incoming calls. Later one we will add other projects or developer will be able to add their projects. Were you can find more informations? http://moksec.networld.to : The main page http://moko.networld.to : The git repositories http://networld.to/mailman/listinfo/moksec-public : The mailinglist We hope that a lot of people will work with us on the security issue. Happy programming Alex Oberhauser ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtopia on freerunner] - What is the right place to discuss Qtopia on Openmoko?
Thomas B. wrote: Hi! On Sat, Jul 12, 2008 at 06:48:41AM +1000, Lorn Potter wrote: Kevin Dean wrote: Plugging a Freerunner up via USB to a Debian system while running this image doesn't appear to charge. Is this a purely visual thing, or is Qtopia unable to charge a Freerunner? I'm assuming that since the other software can, this is a Qtopia thing? actually, it is an apm thing. apm battery status on the freerunner does not work correctly. I guess I need to back port a workaround from the 4.4. branch for at least showing when it is charging. I have a slightly different problem: The battery does get charged, but the screen doesn't dim or get switched off, although I told it to do that in the settings. That's a bit annoying, and it's probably not very healthy for the display, too. Is this also an apm problem, and can it be worked around? I haven't seen this problem. Although, because apm is broken, qtopia cannot tell if the power is plugged in or on battery. If anyone knows how to get a real battery status on the freerunner I can fix this up. I only know of /sys/devices/platform/bq27000-battery.0/power_supply/bat/status. Maybe that helps? not on my devices: [EMAIL PROTECTED]:~# cat /sys/devices/platform/bq27000-battery.0/power_supply/bat/status cat: read error: Timer expired -- Lorn 'ljp' Potter Software Engineer, Systems Group, Trolltech, a Nokia company ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtopia on freerunner] - What is the right place to discuss Qtopia on Openmoko?
Thomas B. wrote: On Sun, Jul 13, 2008 at 10:16:01PM +0200, Thomas B. wrote: I have a slightly different problem: The battery does get charged, but the screen doesn't dim or get switched off, although I told it to do that in the settings. That's a bit annoying, and it's probably not very healthy for the display, too. Is this also an apm problem, and can it be worked around? I just noticed that there is already a newer Qtopia snapshot available for download than the one I have installed (mine is from Friday). I'd love to try that one out, maybe it solves my problem quoted above. Now my next question is: Is there a way to upgrade Qtopia to the new snapshot without losing my data (e.g. contacts and messages)? Backing up the data and writing it back after the upgrade would be fine, but I don't know where the data is stored. it is stored in the databases: ~/Applications/Qtopia/qtopia_db.sqlite ~/Applications/qtmail/qtopia_db.sqlite Settings are stored in ~/Settings -- Lorn 'ljp' Potter Software Engineer, Systems Group, Trolltech, a Nokia company ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
On 7/14/08, Kalle Happonen [EMAIL PROTECTED] wrote: Hello, I've only had my freerunner for a week or so, so I'm not too into the security aspects yet. One thing I did notice was of course passwordless root login. Now over usb this can be acceptable, but if this is possible over wifi (I haven't actually tested), it needs the firewall / make it listen only to the usb. There's no need for a firewall at all (in fact it's probably the worst idea). Just set a root password (you're probably a win user, the command is simply passwd) and it'll be fine. In addition to that, a separate encrypted partition for /root (or /home if the account will changed to a non-privileged user) could be nice, but maybe too heavy and battery draining? Imho it's not needed to encrypt the whole system. Would be the better choice to have some crypto-containers for the files that really need to be secured (phonebook, messages, important documents). We had some discussion in IRC a while ago and my idea would be to have that containers and a daemon in background who handles encryption/decryption, asks for passwords if needed and makes sure that applications who want access to a encrypted container get it (e.g. dialer wants to look up a number in the phonebook). This way the containers can stay decrypted while the phone is on and access is granted dynamically (as needed). Yeah, it's a little much effort, but there is no security without it. If you'd encrypt the whole rootfs you'd have it decrypted the whole time the phone is on (otherwise nothing would work), what means, the security is gone. Well, that's only a part of a possible security framework, but this are only some thoughts. In addition to that, I'd say all linux security administration best practices should be at least considered, including automatic security updates. It's a standard linux system with a lightweight, but still standard, packet management, so that's how it already is handeled (well, without the automatic, but I don't like automatic updating anyway). After the basic security is in good shape, one could move on to fun things like phone lock/unlock/shutdown with an sms, personal data backups / remote removal... the possibilities! :) Possibly to be implemented in a (modular) security-daemon, as mentioned before. Cheers, Kalle Yorick Moko wrote: This mail was posted on the devel list ( http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html). Thought it would interest a lot of people who are not subscribed to that list: Hi Guys, a few months ago we have planned to improve the security of our beloved Neo, after we have read about desires of the community regarding to the security issue. And here we are. Today I will present you our project MokSec. What is MokSec? === MokSec is framework which target is to improve the security of the mobile devices which are based on OpenMoko (and other frameworks which are running on Neos) What is our main focus at the moment? = The main focus is the encryption over GSM. This is very complicated issue and for this we searching developer which are willing to work with us on this interesting project. What are the other components? == At the moment we only working on a phone firewall, which will be blocking/accepting incoming calls. Later one we will add other projects or developer will be able to add their projects. Were you can find more informations? http://moksec.networld.to : The main page http://moko.networld.to : The git repositories http://networld.to/mailman/listinfo/moksec-public : The mailinglist We hope that a lot of people will work with us on the security issue. Happy programming Alex Oberhauser ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
2008/7/13 BlueStar88 [EMAIL PROTECTED]: Feeding assist data to compensate bad hardware based reception is no real solution, since there are some FRs, which seem not to have any problems to get a fast fix at all. My personal current belief is that those FRs are generally no better than eg. yours or mine. It's simply a matter of software used and especially the place used (some countries have also better GPS coverage than others), plus whether one really has a table or so where the device can easily be mounted firmly. If you hold it in your hand, still otherwise, it might not be steady enough to get the fix (or does someone know otherwise, eg. what kind of movement might corrupt the received bits?). Or are there some people who get a fix while moving Neo around? Since the software has zero GPS data saving features etc., it's no wonder people easily think it's broken. Especially, like in my case, if people don't have previous GPS usage experience or don't know how hard it's actually to start from scratch (scanning the whole sky) without any eg. estimate on current whereabouts or any other help. And also it doesn't help that if eg. people use AGPS UI which clears any received data every time it's started. One reason I believe it's not bad hardware reception is that when the fix is gotten, the fix stays better than on many real GPS hardware. Still, I've yet to experiment more on what would be best ways to get the initial fix. Even if feeded initial data, it seems relatively impossible to get the fix around my place. I'm not sure what could be improved still for the first fix, since after the fix is gotten it stays so well one would imagine the fix should also be possible to get in an (relatively) open area with a clear sky. -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On 7/14/08, Timo Jyrinki [EMAIL PROTECTED] wrote: 2008/7/13 BlueStar88 [EMAIL PROTECTED]: Feeding assist data to compensate bad hardware based reception is no real solution, since there are some FRs, which seem not to have any problems to get a fast fix at all. My personal current belief is that those FRs are generally no better than eg. yours or mine. It's simply a matter of software used and especially the place used (some countries have also better GPS coverage than others), plus whether one really has a table or so where the device can easily be mounted firmly. If you hold it in your hand, still otherwise, it might not be steady enough to get the fix (or does someone know otherwise, eg. what kind of movement might corrupt the received bits?). Or are there some people who get a fix while moving Neo around? Since the software has zero GPS data saving features etc., it's no wonder people easily think it's broken. Especially, like in my case, if people don't have previous GPS usage experience or don't know how hard it's actually to start from scratch (scanning the whole sky) without any eg. estimate on current whereabouts or any other help. And also it doesn't help that if eg. people use AGPS UI which clears any received data every time it's started. One reason I believe it's not bad hardware reception is that when the fix is gotten, the fix stays better than on many real GPS hardware. Still, I've yet to experiment more on what would be best ways to get the initial fix. Even if feeded initial data, it seems relatively impossible to get the fix around my place. I'm not sure what could be improved still for the first fix, since after the fix is gotten it stays so well one would imagine the fix should also be possible to get in an (relatively) open area with a clear sky. -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. Well, I know the freerunner is no specialized gps navigation device, but the fact that the signals are so weak that it's barely possible to get a fix under optimal condition (clear view to the sky, antenna on top, without moving 1 mm) shows, that this is no simple software problem and has to be fixed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Homezone Icon for O2 in Germany
Hi, Am Sonntag, den 13.07.2008, 20:05 +0200 schrieb smurfy - phil: Hey, i'm really new to the bitbaker stuff :) i also noticed, that after some new build of the app it wants to download gtk+ and fails. i really don't know why this happens. if you do a removal of the gtk+-fastscaling and then a install of gtk+ it works, also, gtk+ installs a new version of gtk+fastscaling. so i realy don't know why it is doing that :) maybe because on 12.jul, there was an update of the gtk+* packages. Indeed, Forcibly installing the gtk+-package works, and, as I’m back in my homezone now, I can confirm that it works nicely so far. Obviously, you use O2 as well. Some other Freephone and O2 user had observed regular wake-ups from the sleep mode, which obviously kills the battery time, and we thought that the O2 cell broadcasts might cause these wakeups. I haven’t had my phone long enough myself to really test this. Do you observe the same problem? And (now to anyone): Is there a way to disable wake-up on Cell Broadcasts, if that turns out to be the problem? Thanks, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
thomasg kirjoitti: This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. In my past life I developed a fleet management device that had GPS and GSM in it, able to send the fix data to server in intervals. we even implemented some location alerts (around the vicinity of, or near customer..). Based on that experience, we used on of falcoms devices for it, it most probably did not have much of a cache for gps data (black box, tough to tell), but it needed a strong antenna for gps. For a GSM antenna you could use a hairpin, anything that had 10-15 cm of length was totally enough for good quality gsm connection. GPS required much more, in our case we supplied all the devices with external antennas. My knowledge is based solely on this work experience, I'm no radio-geek so I cant really tell much about antennas and signal catching. What kind of GPS-antenna is there in FR? Embedded for sure, but could that be the problem? I guess your TomTom comes with an external windshield antenna? -- Kalle. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Homezone Icon for O2 in Germany
Ok, after some test, i guess i missed something, or my o2 buggs, i receive no new cellbroadcast after leaving my homezone. currently i only receive cellbroadcasts after reregiserting to the network. so there must be another variable to use to detect the homezone. maybe the locationarea code. Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Personally, I'd be more interested in an encrypted filesystem so that I what use is encryption if the user always is root and no password is required? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Homezone Icon for O2 in Germany
Do you observe the same problem? And (now to anyone): Is there a way to disable wake-up on Cell Broadcasts, if that turns out to be the problem? i have the problem that i don't receive more than one cell broadcast after registering with the network. homezoned sets cellboadcasts to ON, i don't know if you disable the deamon and send a manual cell broadcast off command (at command) if you stell get wakeups. Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
again: its not a software issue. This chip should work out of the box. 39 s to fix with good antenna is possible on my dev board, without any agps or anything. 2008/7/14 Timo Jyrinki [EMAIL PROTECTED]: 2008/7/13 BlueStar88 [EMAIL PROTECTED]: Feeding assist data to compensate bad hardware based reception is no real solution, since there are some FRs, which seem not to have any problems to get a fast fix at all. My personal current belief is that those FRs are generally no better than eg. yours or mine. It's simply a matter of software used and especially the place used (some countries have also better GPS coverage than others), plus whether one really has a table or so where the device can easily be mounted firmly. If you hold it in your hand, still otherwise, it might not be steady enough to get the fix (or does someone know otherwise, eg. what kind of movement might corrupt the received bits?). Or are there some people who get a fix while moving Neo around? A good GPS reciever like some properly build SIRF3 systems and others get a fix within 1 minute under good conditions (clear view to sky) cold boot no matter how you hold your device. (proved here several times) The openmoko does not get a fix in reliable time (3 minutes). If you plug in a external antenna and keep it away from the device it works like with a good SIFR3 chip. So lets face it: IT IS NOT A SOFTWARE ISSUE! Since the software has zero GPS data saving features etc., it's no wonder people easily think it's broken. Especially, like in my case, if people don't have previous GPS usage experience or don't know how hard it's actually to start from scratch (scanning the whole sky) without any eg. estimate on current whereabouts or any other help. And also it doesn't help that if eg. people use AGPS UI which clears any received data every time it's started. One reason I believe it's not bad hardware reception is that when the fix is gotten, the fix stays better than on many real GPS hardware. As you can see if you search for the thread GPS External antenna detect issue it is a hardware issue. And there are a lot of people on this list having experienced with gps systems like me. Reading the manual of the chip you can see, that it should work out of the box without software support. 39 s is what this chip is able to. But of course not if the antenna system is broken. Some people expect it to be a combination of: * broken antenna switch * bad antenna * antenna too near to device Still, I've yet to experiment more on what would be best ways to get the initial fix. Even if feeded initial data, it seems relatively impossible to get the fix around my place. I'm not sure what could be improved still for the first fix, since after the fix is gotten it stays so well one would imagine the fix should also be possible to get in an (relatively) open area with a clear sky. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Jalimo fails to install on freerunner gta02
Hi, Jim Morris schrieb: Robert Schuster wrote: Hi, yes this is a know issue with the packages in our repo. Sorry, I had no time to fix this yet. Btw: cacao + classpath should be in the official repos as well. So there is no need to add the Jalimo repos any more. Thanks, also in the docs on the site it says to do ipkg install swt-gtk however this is not needed as it seems to be installed with the opkg install cacao classpath Will fix it. Also do you know if this release has any hooks into the phone API or any other H/W on the freerunner? (Dbus would be cool). dbus-java is in OpenEmbedded. I am not sure if its being built and part of the official repos tough. Try installing libdbus-java, javadoc and general usage can be found here: http://dbus.freedesktop.org/doc/dbus-java/ Regards Robert signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OpenMoko] qemu win32 emulator
Hi, what you want is a binary of QEMU + OpenMoko's patches for it. If the links do not work try to get in contact with the people who distributed them first. AFIU the OpenMoko project is mostly about doing things from source so it should be possible to compile QEMU + patches under Windows and/or cygwin, too. Regards Robert Yocto schrieb: Hi, Where can I find an openmoko win32 emulator ? The links to the pre-build binaries of openmoko-emulator-win32-bin-20070625.zip or its mirror are broken. From the wiki at wiki.openmoko.org/wiki/OpenMoko_under_QEMU mdk.linux.org.tw/~jserv/openmoko/openmoko-emulator-win32-bin-20070625.zip snakesoftruth.com/openmoko-emulator-win32-bin-20070625.zip Thanks. // Yocto ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Homezone Icon for O2 in Germany
Obviously, you use O2 as well. Some other Freephone and O2 user had observed regular wake-ups from the sleep mode, which obviously kills the battery time, and we thought that the O2 cell broadcasts might cause these wakeups. I haven’t had my phone long enough myself to really test this. experienced that (no o2 user!) with power management set to dim first, then lock. after switching to dim only, don't lock i didn't see it anymore -- but the fr still locks ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Claws Mail
Hi all, did anyone succeed in building this package? I only got libtinymail tmut compiled packed up to now. Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Claws Mail
did anyone succeed in building this package? I only got libtinymail tmut compiled packed up to now. yupp. got it built and running. will load it up to ginguppin.de tonight (note to self: learn how to create a feed) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Claws Mail
arne anka wrote: did anyone succeed in building this package? I only got libtinymail tmut compiled packed up to now. yupp. got it built and running. will load it up to ginguppin.de tonight (note to self: learn how to create a feed) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community take a look at http://wiki.openmoko.org/wiki/CommunityRepository by adding the ipkg to the download area of a project on projects.openmoko.org it automatically gets into a 'to be reviewed' files. then i want to see some testers saying 'yap' on the community-repository mailinglist and we'll add it to the repository. kind regards ps: we're still needing more testers for the CommunityRepository project ;) -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OpenMoko] qemu win32 emulator
Hi, I did svn checkout the qemu-neo1973 and was following manual setup on the wiki. But I bumped into the SDL requirement, etc... Thanks to Yorick Moko who provided a link to his pre-built binaries. I was able to get a quick first look feel of the openmoko projet. Even if that build was over a year old... I saw the potential... Now, I can invest more of my spare time on this projet. Thanks. // Yocto - Original Message - From: Robert Schuster [EMAIL PROTECTED] To: List for Openmoko community discussion community@lists.openmoko.org Sent: Monday, July 14, 2008 5:15 AM Subject: Re: [OpenMoko] qemu win32 emulator ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS issue
On Jul 13, 2008, at 11:32 AM, jonathan spooner wrote: Also there is a fair bit of drift on my position. Using the plot feature in agps it looks like I'm walking all over my garden while the gta02 is sat on the table at times. As far as I know, that drift is quite normal. If you leave GPS receiver in one place, there always will be some drift. It depends on chipset used in GPS. For example SiRF III has greater drift than older, less sensitive chipsets. More important is precision while moving and the same SiRF III based receivers are much better than older receivers. That drift doesn't occur when moving. Also more important is keeping signal, and again, SiRF III rarely loose signal, even in bad conditions. I don't know what chipset is used in FR, but I wouldn't worry about drifting ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
Russell Sears schrieb: That sounds like a different problem than I have. People have reported many different failure modes: - Everything works. The phone gets a reliable fix in ~5-15 minutes if you baby it enough. (This might be improved w/ better drivers...) The GPS-module talks NMEA to the serial. I'm no GPS-expert, but where exactly should a 'driver' step in, to assist in basic technical procedures? - The software is somehow messed up, and there are never any fixes. (People report GPS breakage after installing some combination of the GPS packages...) Reflashing the phone does not seem to help(!) Ignore the software, just look at the NMEA output! If you get a communication to the module established, all depends on the facts coming from the NMEA output. There should be no 'misunderstandings' from any software involved. This poor (?) signal is just not enough, to get any fix: https://docs.openmoko.org/trac/attachment/ticket/1542/reception.jpg - Actual antenna troubles. (See message GPS issue related to GPS antenna selector ?) Yepp, I assume this as the right (and only) direction it goes. TangoGPS problems: - TangoGPS says no gps found. Run opkg install gpsd. - The GPS device usually works, but sometimes tangoGPS sees zero satellites after 5 minutes. If you to power down the GPS device, then power it back up, it starts seeing satellites. GPS UI 0.20 is used by me to do the diagnostics. Is there a cause not to trust it, even by looking at the pure NMEA output of it? -- BlueStar88 PGPID: 0x36150C86 PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86 signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hampshire group buy
All - It seems that the 900MHz version of the phone won't be available from the OM shop for at least a couple of weeks (see [1]). However, Pulster are now selling 10 packs for EUR 2990, including taxes and shipping. This works out at about UKP 240 a phone -- probably a little more expensive than getting from the USA, *but* you get the full 2-year warranty, and they're available right now. Also, I've only got 7 people (bcc'd) who've said they're interested in the Hampshire group purchase. Unless we get 10 people, I can't do anything, so this is a call for further people to sign up. Finally, I'm not actually buying mine in this transaction, as it's coming through an alternative route (for various complicated reasons). Therefore if anyone wants to take up the effort of organising this group purchase, please let me know. Hugo. [1] http://lists.openmoko.org/pipermail/community/2008-July/020981.html -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Comic Sans goes into a bar, and the barman says, We don't --- serve your type here. signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hampshire group buy
We have a number of FreeRunners in Oxford ready to be dispatched as either group buys or individual purchases [1]. Unfortunately we don't have a payment system arranged yet, but that should be coming in the near future. Initial pricing is £200 + VAT + Postage. The FreeRunner neoprene pouch and headset are included for free. Stocks are currently limited as many of our phones have either been earmarked for project work, or have been pre-ordered. In the near future we will be securing more stock and specialising our sales to research groups, LUGs, and into developing custom solutions based on the Openmoko platform. Please email me; joseph dot reeves at thehumanjourney dot net for further information. Thanks, Joseph Oxford Archaeology http://thehumanjourney.net [1] http://blogs.thehumanjourney.net/finds/entry/20080710 2008/7/14 Hugo Mills [EMAIL PROTECTED]: All - It seems that the 900MHz version of the phone won't be available from the OM shop for at least a couple of weeks (see [1]). However, Pulster are now selling 10 packs for EUR 2990, including taxes and shipping. This works out at about UKP 240 a phone -- probably a little more expensive than getting from the USA, *but* you get the full 2-year warranty, and they're available right now. Also, I've only got 7 people (bcc'd) who've said they're interested in the Hampshire group purchase. Unless we get 10 people, I can't do anything, so this is a call for further people to sign up. Finally, I'm not actually buying mine in this transaction, as it's coming through an alternative route (for various complicated reasons). Therefore if anyone wants to take up the effort of organising this group purchase, please let me know. Hugo. [1] http://lists.openmoko.org/pipermail/community/2008-July/020981.html -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Comic Sans goes into a bar, and the barman says, We don't --- serve your type here. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIezhVIKyzvlFcI40RAovbAJwPzqYM6/89sOQx6QzHevyBGUy0LgCgn2/O GXubiamGxl5Ojr28OJN+qB8= =xRZY -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import Contacts
2008/7/12 Al Johnson [EMAIL PROTECTED]:
On Friday 11 July 2008, Kalle Happonen wrote:
Hi,
Brian C wrote:
Brian C wrote:
[a long error message because he didn't run the script from the OM
terminal]
Ok, so the script runs now that I realize it must be run from the OM
terminal.
It might work from an ssh session if you run:
dbus-launch scriptname
I haven't tried this though - just guessing based on similar behaviour from
gconftool-2
However, it appears to have entered all null contacts and
so far none of them appear to have any actual contact info in them
If you do not want to delete all the null contacts by hand I've made
a script(attached as remove_all_contacts.py) based on Wurps script
which removes all contacts in your addressbook. It should be pretty
easy to modify so that it only deletes null contacts.
I ran into the same problem, but I did get them in now with the script.
I had two issues actually. The easiest to try
is to remove the empty lines between the entries in the vCard file, and
have them all in a long jumble. That solved my last problem.
Blank line removal should be a one-liner - if only I were more familiar with
python ;-)
Take a quick look at the attached import_contacts.py script, it is
based on Al Johnson modification to Wurps script.
I did have another problem when I played around with the contacts in
Evolution on the desktop. I started by exporting the contacts as vCard
from Wammu. Evolution refused to read those v2.1 vCards. I then
exported it as ldif from wammu, and had to make a small change in the
entries so that evolution read them correctly (adding a cn or smth).
AFAIK the openmoko contacts is also based on evolution so there might be
similar problems.
When I tried to import Wammu vCards, they showed up as null entries on
openmoko. When I exported the contacts as vCard (3.0) from evolution,
and removed the empty lines in the vCard file, I could import them to
openmoko with the script. I'm not sure if the new vCard format helped any.
Interesting...I remember having similar problems with OpenXchange a couple of
years ago. It assumed v3 and didn't check the version in the vCard itself.
You had to pick which interface to use depending on the vCard version. i
wonder if Evolution Data Server is doing something similar?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
#!/usr/bin/python
from __future__ import with_statement
import dbus
import sys, os
import tempfile
import re
bus_name = 'org.gnome.evolution.dataserver.AddressBook'
obj_name = /org/gnome/evolution/dataserver/addressbook/file_3a__2f__2f__2f_home_2f_root_2f__2e_evolution_2f_addressbook_2f_local_2f_system
addressBook = None
def getAddressBook():
global addressBook
if addressBook is None:
sb = dbus.SessionBus()
obj = sb.get_object(bus_name, obj_name)
addressBook = dbus.Interface(obj, 'org.gnome.evolution.dataserver.addressbook.Book')
return addressBook
names = os.listdir('.')
for name in names:
print name
vcard =
f=open(name,'r')
for line in f:
if line != \r\n:
vcard = vcard + line
if line[:9] == END:VCARD:
GPS
thomasg wrote: This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. Well, I know the freerunner is no specialized gps navigation device, but the fact that the signals are so weak that it's barely possible to get a fix under optimal condition (clear view to the sky, antenna on top, without moving 1 mm) shows, that this is no simple software problem and has to be fixed. The GPS performance of my Freerunner is also much worse than the GPS performance of my neo1973. I've done side-by-side tests of the two units many times. My neo1973 gets a good fix in 2 to 3 minutes after a completely cold start; it's very reliable. My Freerunner initially was getting a fix after 7 or 8 minutes. For the last few days it has not been able to get a fix at all. Ken Young ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: MokSec - The Security Framework
How would being root help somebody decrypt a filesystem? Accessing an encrypted filesystem should depend only on having the correct key. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of arne anka Sent: Monday, July 14, 2008 4:58 AM To: List for Openmoko community discussion Subject: Re: MokSec - The Security Framework Personally, I'd be more interested in an encrypted filesystem so that I what use is encryption if the user always is root and no password is required? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import Contacts
Andreas Dalsgaard wrote: 2008/7/12 Al Johnson [EMAIL PROTECTED]: On Friday 11 July 2008, Kalle Happonen wrote: Hi, Brian C wrote: Brian C wrote: [a long error message because he didn't run the script from the OM terminal] Ok, so the script runs now that I realize it must be run from the OM terminal. It might work from an ssh session if you run: dbus-launch scriptname I haven't tried this though - just guessing based on similar behaviour from gconftool-2 However, it appears to have entered all null contacts and so far none of them appear to have any actual contact info in them If you do not want to delete all the null contacts by hand I've made a script(attached as remove_all_contacts.py) based on Wurps script which removes all contacts in your addressbook. It should be pretty easy to modify so that it only deletes null contacts. I ran into the same problem, but I did get them in now with the script. I had two issues actually. The easiest to try is to remove the empty lines between the entries in the vCard file, and have them all in a long jumble. That solved my last problem. Blank line removal should be a one-liner - if only I were more familiar with python ;-) Take a quick look at the attached import_contacts.py script, it is based on Al Johnson modification to Wurps script. Hah, thanks for fixing the script. I almost feel ashamed for not spending a few minutes to fix it up, but just did vim magic on my contacts files :). And thanks for the contact remover too! I did have another problem when I played around with the contacts in Evolution on the desktop. I started by exporting the contacts as vCard from Wammu. Evolution refused to read those v2.1 vCards. I then exported it as ldif from wammu, and had to make a small change in the entries so that evolution read them correctly (adding a cn or smth). AFAIK the openmoko contacts is also based on evolution so there might be similar problems. When I tried to import Wammu vCards, they showed up as null entries on openmoko. When I exported the contacts as vCard (3.0) from evolution, and removed the empty lines in the vCard file, I could import them to openmoko with the script. I'm not sure if the new vCard format helped any. Interesting...I remember having similar problems with OpenXchange a couple of years ago. It assumed v3 and didn't check the version in the vCard itself. You had to pick which interface to use depending on the vCard version. i wonder if Evolution Data Server is doing something similar? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Monday 14 July 2008, BlueStar88 wrote: Russell Sears schrieb: That sounds like a different problem than I have. People have reported many different failure modes: - Everything works. The phone gets a reliable fix in ~5-15 minutes if you baby it enough. (This might be improved w/ better drivers...) The GPS-module talks NMEA to the serial. I'm no GPS-expert, but where exactly should a 'driver' step in, to assist in basic technical procedures? The module talks NMEA but also a ublox binary format. Among other things this allows time and location estimates, ephemeris and almanac data to be fed to the module to give it an initial state, and should reduce time to first fix. Likewise it can be used to request this data from the module so it can be saved before shutdown. 'Driver' probably isn't the right word. - The software is somehow messed up, and there are never any fixes. (People report GPS breakage after installing some combination of the GPS packages...) Reflashing the phone does not seem to help(!) Ignore the software, just look at the NMEA output! If you get a communication to the module established, all depends on the facts coming from the NMEA output. There should be no 'misunderstandings' from any software involved. This poor (?) signal is just not enough, to get any fix: https://docs.openmoko.org/trac/attachment/ticket/1542/reception.jpg - Actual antenna troubles. (See message GPS issue related to GPS antenna selector ?) Yepp, I assume this as the right (and only) direction it goes. TangoGPS problems: - TangoGPS says no gps found. Run opkg install gpsd. - The GPS device usually works, but sometimes tangoGPS sees zero satellites after 5 minutes. If you to power down the GPS device, then power it back up, it starts seeing satellites. GPS UI 0.20 is used by me to do the diagnostics. Is there a cause not to trust it, even by looking at the pure NMEA output of it? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Claws Mail
On Monday 14 July 2008, Joachim Steiger wrote: arne anka wrote: did anyone succeed in building this package? I only got libtinymail tmut compiled packed up to now. yupp. got it built and running. will load it up to ginguppin.de tonight (note to self: learn how to create a feed) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community take a look at http://wiki.openmoko.org/wiki/CommunityRepository by adding the ipkg to the download area of a project on projects.openmoko.org it automatically gets into a 'to be reviewed' files. then i want to see some testers saying 'yap' on the community-repository mailinglist and we'll add it to the repository. kind regards ps: we're still needing more testers for the CommunityRepository project ;) Many of the things people are asking about are already available in OE and build just fine using mokomakefile's 'make build-package-packagename'. These shouldn't need adding to projects.openmoko.org to make it into a repository. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Mon, Jul 14, 2008 at 10:45 AM, Kalle Kärkkäinen [EMAIL PROTECTED] wrote: In my past life I developed a fleet management device that had GPS and GSM in it, able to send the fix data to server in intervals. we even implemented some location alerts (around the vicinity of, or near customer..). Based on that experience, we used on of falcoms devices for it, it most probably did not have much of a cache for gps data (black box, tough to tell), but it needed a strong antenna for gps. For a GSM antenna you could use a hairpin, anything that had 10-15 cm of length was totally enough for good quality gsm connection. GPS required much more, in our case we supplied all the devices with external antennas. My knowledge is based solely on this work experience, I'm no radio-geek so I cant really tell much about antennas and signal catching. What kind of GPS-antenna is there in FR? Embedded for sure, but could that be the problem? I guess your TomTom comes with an external windshield antenna? -- Kalle. No, it has no external antenna, only a window-mount with antenna connector but without one connected. That GSM works better is sure, because mobile GSM devices can receive at -110 dBm (usually ~ -70 to -90) while GPS chips receive at up to -160 dBm (usually between -130 and -150 at the antenna). I think the antenna in the freerunner is not that bad, it even has a preamp. Ublox can receive at -158 dBm (according to the datasheet), what is pretty good (and definitely not worse than every good navigation device), and should get at least -130 dB (good enough for a cold boot fix) _after_ the antenna (preamplified) I guess. It even has it's own additional amp on chip. So the problem is imho only bad build quality (QA) at least in some of the devices (might be a defect connector by 3rd party, don't know). Short version: antenna good (I bet it's better than the antennas in most other smartphones with GPS), chip very good - bug. And btw. - SIRF Star III are damn good chips and used in many navigation devices and bluetooth gps devices, but the antaris is almost at the same level. It surely is no software issue, theoretically it could be a firmware issue of the u-blox, but I don't think it is. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import Contacts
Andreas Dalsgaard, 2008-07-14 14:01:07 +0200 :
[...]
Take a quick look at the attached import_contacts.py script, it is
based on Al Johnson modification to Wurps script.
Please pardon my intruding into a thread, I just subscribed to the
list. I have also worked on contacts management, mostly to allow
myself to fix non-ASCII names in a real editor with a real keyboard.
The result is the attached script, which improves on the previous
ones in the following ways:
- you can run it through SSH, and it looks for a DBUS session;
- you can dump all contacts to a file (a series of concatenated
vcards);
- you an reload that file (after having altered it), and it'll update
contacts when they already exist (based on UID) or create
new contacts otherwise.
So, basically:
$ scp manage-contacts.py openmoko:
$ ssh openmoko python manage-contacts.py dump contacts.txt
$ emacs/vim/nano/gedit/whatever contacts.txt
$ ssh openmoko python manage-contacts.py load contacts.txt
As far as I'm concerned (look, I'm a Debian integrist, I'm
*supposed* to care about these things :-), my modifications to the
initial script are subject to the WTFPL.
Roland.
--
Roland Mas
Plus on en fout, plus y'en a du riz.
-- Proverbe chinois.
#!/usr/bin/python
# coding=utf-8
from __future__ import with_statement
import dbus
import sys, os
import tempfile
import re, string, time
ps = os.popen ('ps auxe | grep -m 1 DBUS_SESSION_BUS_ADDRESS')
l = ps.read ()
r = re.compile ('DBUS_SESSION_BUS_ADDRESS=(\S+)')
m = r.search (l)
a = m.expand ('\\1')
os.environ ['DBUS_SESSION_BUS_ADDRESS'] = a
bus_name = 'org.gnome.evolution.dataserver.AddressBook'
obj_name = '/org/gnome/evolution/dataserver/addressbook/file_3a__2f__2f__2f_home_2f_root_2f__2e_evolution_2f_addressbook_2f_local_2f_system'
addressBook = None
def getAddressBook ():
global addressBook
if addressBook is None:
sb = dbus.SessionBus ()
obj = sb.get_object (bus_name, obj_name)
addressBook = dbus.Interface (obj, 'org.gnome.evolution.dataserver.addressbook.Book')
return addressBook
if len (sys.argv) != 2:
print (Expects a single argument, 'dump' or 'load')
print (With 'dump', dumps all contacts as vcards to STDOUT)
print (With 'load', loads vcards from STDIN)
exit (1)
def dump_contacts ():
# Note: this is a gross hack, but I didn't manage to get getContactList to work
strings = os.popen ('strings /home/root/.evolution/addressbook/local/system/addressbook.db | grep ^pas-id- | sort -u').readlines ()
for id in strings:
id = id.rstrip ()
try:
print getAddressBook ().getContact (id) + \r
except:
pass
def load_contacts ():
contacts = parse_stdin ()
ab = getAddressBook ()
l = contacts.keys ()
l.sort ()
for k in contacts.keys ():
try:
c = ab.getContact (k)
print Contact already exists, modifying
try:
ab.modifyContact (contacts [k])
except:
print Got error when modifying + c
except:
print New contact
ab.addContact (contacts [k])
def parse_stdin ():
lines = sys.stdin.readlines ()
contacts = {}
cur = []
index = 0
for l in lines:
line = l.rstrip ()
if line == '':
continue
if line == 'END:VCARD':
cur.append (line)
seen = ''
for record in cur:
if record.startswith ('UID:'):
seen = record [4:]
seen = seen.rstrip ()
if seen == '':
seen = 'new-contact-' + str(index)
index += 1
contacts [seen] = string.join (cur, '\r\n')
cur = []
else:
if line.startswith ('REV:'):
cur.append ('REV: ' + time.strftime ('%Y-%m-%dT%H:%M:%SZ', time.gmtime()))
else:
cur.append (line)
return contacts
if sys.argv [1] == 'load':
load_contacts ()
else:
dump_contacts ()
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Import Contacts
Roland Mas, 2008-07-14 15:09:34 +0200 : - you can dump all contacts to a file (a series of concatenated vcards); Forgot to mention: that feature uses a gross hack, I'd be happy to see it cleaned up. I just didn't manage to find the query syntax for the getContactList() method. Roland. -- Roland Mas Le weblog entièrement nu -- http://roland.entierement.nu/ Le photoblog entièrement net -- http://roland.entierement.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
How would being root help somebody decrypt a filesystem? Accessing an encrypted filesystem should depend only on having the correct key. well, to be really usefull the fs should be mounted transparently (hacking in the passphrase on every access seems utterly tedious with that tiny keyboard -- and would probably add to the exposure risk). or you need to store the passphrase somewhere on the fr and access it by some automatic. in both cases somebody finding or stealing your fr would be able to read your encrypted data. please, correct me, if i am wrong. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import Contacts
Please update http://wiki.openmoko.org/wiki/Import_Vcf_Contacts with your new versions, if you need space i could place it @my domain (like my first version :D) Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
thomasg wrote: On 7/14/08, *Kalle Happonen* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, I've only had my freerunner for a week or so, so I'm not too into the security aspects yet. One thing I did notice was of course passwordless root login. Now over usb this can be acceptable, but if this is possible over wifi (I haven't actually tested), it needs the firewall / make it listen only to the usb. There's no need for a firewall at all (in fact it's probably the worst idea). Just set a root password (you're probably a win user, the command is simply passwd) and it'll be fine. What an insult! *slap* :P. No I'm not a windows user. and I can set the root password on my device, but defaults matter. And they matter a lot if openmoko will become more mass-market. A firewall migth be a bit heavy, I agree, every watt and cycle should try to be saved, but making dropbear just listen to the usb interface would be a pretty good compromise, if that is possible. However, later on an easily configurable firewall would be almost essential imho. Connecting to the phone (any port) over the wifi should (almost?)never be allowed as default. Even if the point with the phone is that users can do what they want, it doesn't mean that the apps they install shouldn't be protected. And a firewall is almost the only viable way. There's no easy way of making all the apps listen to just one interface, and while host.allow/deny is more lightweight than a firewall, those don't allow distinguishing of interface. In addition to that, a separate encrypted partition for /root (or /home if the account will changed to a non-privileged user) could be nice, but maybe too heavy and battery draining? Imho it's not needed to encrypt the whole system. Would be the better choice to have some crypto-containers for the files that really need to be secured (phonebook, messages, important documents). We had some discussion in IRC a while ago and my idea would No, not the whole system. But well the user homedir would be basically what we want to protect, and if it was on it's own partition, there is kernel support for it already. be to have that containers and a daemon in background who handles encryption/decryption, asks for passwords if needed and makes sure that applications who want access to a encrypted container get it (e.g. dialer wants to look up a number in the phonebook). This way the containers can stay decrypted while the phone is on and access is granted dynamically (as needed). I think completely dynamic decryption would be too cumbersone to use. If you mean that it would need an unlock for every received sms (to get the contact behind the number) and phone call, it's just unfeasible. If you want to protect the en/decryption key, it needs a passphrase that is long enough to be of any benefit. The other option is a PKI enabled SIM, which would be cool. Hence it should be unlocked only once, at bootup. The sim pin could also be saved on the encrypted partition (maybe the pin itself again encrypted with the passphrase, so it's not accessible easily at runtime) so that the user only needs to authenticate once to use the phone. There could be then options to forget the encryption key either locally or via a magic sms. Yeah, it's a little much effort, but there is no security without it. If you'd encrypt the whole rootfs you'd have it decrypted the whole time the phone is on (otherwise nothing would work), what means, the security is gone. No it doesn't. Everything NEEDS to be decrypted automagically when the phone is on. Otherwise it's just unusable. The whole system shouldn't be encrypted, that's just waste. But having a personal area decrypted at startup means that only you can access it at bootup, and one can add the option of remotely disabling access to it. That is very much security, way more than phones usually have nowadays, even more than laptops/desktops, but not too much to make it hard/annoying to use. Well, that's only a part of a possible security framework, but this are only some thoughts. In addition to that, I'd say all linux security administration best practices should be at least considered, including automatic security updates. It's a standard linux system with a lightweight, but still standard, packet management, so that's how it already is handeled (well, without the automatic, but I don't like automatic updating anyway). The fact that it has package management doesn't mean much in itself. I think current linux distributions have a pretty good model. A separate security updates repo, which just releases security patches, and since these are an security update of the recommended version, they don't (well shouldn't) break anything, so they can even be pretty safely applied automatically. Again, defaults matter. If you need to log in, run
Re: GPS
two small questions: 1) is there ANYBODY who has a freerunner with a normal functioning GPS? 2) We must presume openmoko tested the GPS before starting the mass production. The GPS of those devices must have worked, no? On Mon, Jul 14, 2008 at 3:05 PM, thomasg [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 10:45 AM, Kalle Kärkkäinen [EMAIL PROTECTED] wrote: In my past life I developed a fleet management device that had GPS and GSM in it, able to send the fix data to server in intervals. we even implemented some location alerts (around the vicinity of, or near customer..). Based on that experience, we used on of falcoms devices for it, it most probably did not have much of a cache for gps data (black box, tough to tell), but it needed a strong antenna for gps. For a GSM antenna you could use a hairpin, anything that had 10-15 cm of length was totally enough for good quality gsm connection. GPS required much more, in our case we supplied all the devices with external antennas. My knowledge is based solely on this work experience, I'm no radio-geek so I cant really tell much about antennas and signal catching. What kind of GPS-antenna is there in FR? Embedded for sure, but could that be the problem? I guess your TomTom comes with an external windshield antenna? -- Kalle. No, it has no external antenna, only a window-mount with antenna connector but without one connected. That GSM works better is sure, because mobile GSM devices can receive at -110 dBm (usually ~ -70 to -90) while GPS chips receive at up to -160 dBm (usually between -130 and -150 at the antenna). I think the antenna in the freerunner is not that bad, it even has a preamp. Ublox can receive at -158 dBm (according to the datasheet), what is pretty good (and definitely not worse than every good navigation device), and should get at least -130 dB (good enough for a cold boot fix) _after_ the antenna (preamplified) I guess. It even has it's own additional amp on chip. So the problem is imho only bad build quality (QA) at least in some of the devices (might be a defect connector by 3rd party, don't know). Short version: antenna good (I bet it's better than the antennas in most other smartphones with GPS), chip very good - bug. And btw. - SIRF Star III are damn good chips and used in many navigation devices and bluetooth gps devices, but the antaris is almost at the same level. It surely is no software issue, theoretically it could be a firmware issue of the u-blox, but I don't think it is. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
arne anka wrote: How would being root help somebody decrypt a filesystem? Accessing an encrypted filesystem should depend only on having the correct key. well, to be really usefull the fs should be mounted transparently (hacking in the passphrase on every access seems utterly tedious with that tiny keyboard -- and would probably add to the exposure risk). depends on what you mean on every access. If it's once per startup, I wouldn't think it's too much. How often do you reboot the phone? Cheers, Kalle ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
wouldn't think it's too much. How often do you reboot the phone? with a battery uptime of about 8h -- at least once a day, because the fr usually silently shuts down. on weekends more frequently because i play around and something crashes or so. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import Contacts
smurfy - phil, 2008-07-14 15:30:22 +0200 : Please update http://wiki.openmoko.org/wiki/Import_Vcf_Contacts with your new versions, if you need space i could place it @my domain (like my first version :D) Space isn't a problem (I uploaded the script to [1]), but I'm reluctant to create yet another account on yet another website. Could you add the link (and maybe rephrase the text on the article to remove the thing about running from a terminal rather than SSH)? Thanks, Roland. [1] http://www.placard.fr.eu.org/~roland/tmp/manage-contacts.py -- Roland Mas ()Campagne du ruban ASCII : /\Contre les mails en HTML et les vcard ! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: MokSec - The Security Framework
Once the device is powered, and the correct key entered, I would expect it would remain in memory until the phone is powered off. Parnoid types would of course disable network access. Nearly all phones have a secured access mode, where you enter a pin every time you access the phone. That's a must for some. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of arne anka Sent: Monday, July 14, 2008 9:26 AM To: List for Openmoko community discussion Subject: Re: MokSec - The Security Framework How would being root help somebody decrypt a filesystem? Accessing an encrypted filesystem should depend only on having the correct key. well, to be really usefull the fs should be mounted transparently (hacking in the passphrase on every access seems utterly tedious with that tiny keyboard -- and would probably add to the exposure risk). or you need to store the passphrase somewhere on the fr and access it by some automatic. in both cases somebody finding or stealing your fr would be able to read your encrypted data. please, correct me, if i am wrong. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
arne anka wrote: wouldn't think it's too much. How often do you reboot the phone? with a battery uptime of about 8h -- at least once a day, because the fr usually silently shuts down. on weekends more frequently because i play around and something crashes or so. Well, this wasn't available now, was it? :). Since these are only plans, and afaik the powersave functionality will be vastly improved, that argument is hopefully invalid when the encryption is available. Kalle ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Paul Jimenez wrote: Alex Oberhauser wrote: Bumbl wrote: It would be more important to not run everything as root I think This will be also a main focus. When we receive the Freerunners, we will see how fast we can change this bad state. Personally, I'd be more interested in an encrypted filesystem so that I can worry less about snoopy people getting access to my personal data if I lose my phone or it's stolen. How many 'main focuses' are you allowed ? :) Can we use the SIM-Card to decrypt stuff? It's after all a smart card. :) Would be cool if we could store a crypto key on the SIM, which it will only release if you provide the right SIM. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Kalle Happonen wrote: However, later on an easily configurable firewall would be almost essential imho. Connecting to the phone (any port) over the wifi should (almost?)never be allowed as default. Even if the point with the phone is that users can do what they want, it doesn't mean that the apps they install shouldn't be protected. And a firewall is almost the only viable way. There's no easy way of making all the apps listen to just one interface, and while host.allow/deny is more lightweight than a firewall, those don't allow distinguishing of interface. SELinux comes to mind. Or at least the capabilites framework. This way i could choose to allow a app to open sockets. (Little bit like java sandboxes) As far as i know we could even have a popup asking for permission. And to give my 2 Eurocents to the everything as root discusion. Running user apps as root must end, better soon. If apps need things only root can do (not much comes to my mind) we could use sudo wrapper or SELinux rules. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Tilman Baumann wrote: Paul Jimenez wrote: Alex Oberhauser wrote: Bumbl wrote: It would be more important to not run everything as root I think This will be also a main focus. When we receive the Freerunners, we will see how fast we can change this bad state. Personally, I'd be more interested in an encrypted filesystem so that I can worry less about snoopy people getting access to my personal data if I lose my phone or it's stolen. How many 'main focuses' are you allowed ? :) Can we use the SIM-Card to decrypt stuff? It's after all a smart card. :) Would be cool if we could store a crypto key on the SIM, which it will only release if you provide the right SIM. I don't think that's doable with normal SIMs. But there are places where you can get SIM cards with built in encyption/decryption keys, and a certificate (PKI). This is possible at least in Finland, but not widely used. If you had the PKI enabled SIM, I'd say it wouldn't only be cool, it would be THE way to go, as far as security and ease of use goes. :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: MokSec - The Security Framework
I would think on a phone the primary concern is protecting the user data. E.g. sms, contacts, history. If somebody was able to malicously install software on the phone, your pretty much already [EMAIL PROTECTED]'ed. Not letting it call out helps, but it's already defeated. I'm assuming we're not installing a lot of new unknowns on a secure device, and anything trying to make network connections is evol. I've been picturing running an encrypted rootfs image off an SD card. There could be multiple encrypted rootfs images, only one would be the real one, or they all could be used for different reasons. Once the system boots it's up to the user to unlock the keys to the encrypted image to be used and that gets booted from the already running kernel. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tilman Baumann Sent: Monday, July 14, 2008 10:38 AM To: List for Openmoko community discussion Subject: Re: MokSec - The Security Framework Kalle Happonen wrote: However, later on an easily configurable firewall would be almost essential imho. Connecting to the phone (any port) over the wifi should (almost?)never be allowed as default. Even if the point with the phone is that users can do what they want, it doesn't mean that the apps they install shouldn't be protected. And a firewall is almost the only viable way. There's no easy way of making all the apps listen to just one interface, and while host.allow/deny is more lightweight than a firewall, those don't allow distinguishing of interface. SELinux comes to mind. Or at least the capabilites framework. This way i could choose to allow a app to open sockets. (Little bit like java sandboxes) As far as i know we could even have a popup asking for permission. And to give my 2 Eurocents to the everything as root discusion. Running user apps as root must end, better soon. If apps need things only root can do (not much comes to my mind) we could use sudo wrapper or SELinux rules. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen [EMAIL PROTECTED] wrote: But there are places where you can get SIM cards with built in encyption/decryption keys, and a certificate (PKI). I agree. Would you care to elaborate (link)? Sincerely, Jan. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen [EMAIL PROTECTED] wrote: What an insult! *slap* :P. No I'm not a windows user. and I can set the root password on my device, but defaults matter. And they matter a lot if openmoko will become more mass-market. A firewall migth be a bit heavy, I agree, every watt and cycle should try to be saved, but making dropbear just listen to the usb interface would be a pretty good compromise, if that is possible. Ok, sorry, that was a too mean joke :P The situation with no root password set is of course not bearable, but I'm pretty sure that this issue will be solved in a consumer-ready release. What I'd imagine would be a kind of first-run-guide, that forces (or allows, however you want :) ) the user to do all the important settings at the first run of the phone (could be used for backup purposes, too, e.g. load an xml-file with the settings). Would make the life way easier for newbies. However, later on an easily configurable firewall would be almost essential imho. Connecting to the phone (any port) over the wifi should (almost?)never be allowed as default. Even if the point with the phone is that users can do what they want, it doesn't mean that the apps they install shouldn't be protected. And a firewall is almost the only viable way. There's no easy way of making all the apps listen to just one interface, and while host.allow/deny is more lightweight than a firewall, those don't allow distinguishing of interface. A firewall is always a more or less big piece of software, always not the best for performance, and always a security risk (if it's not dedicated). It also is not possible to do a easy and _good_ configuration, so however it's done, it's always suboptimal. There are not too much services running, and all of them are open source software, so that is imho not that a big deal. In addition to that, a separate encrypted partition for /root (or /home if the account will changed to a non-privileged user) could be nice, but maybe too heavy and battery draining? Imho it's not needed to encrypt the whole system. Would be the better choice to have some crypto-containers for the files that really need to be secured (phonebook, messages, important documents). We had some discussion in IRC a while ago and my idea would No, not the whole system. But well the user homedir would be basically what we want to protect, and if it was on it's own partition, there is kernel support for it already. be to have that containers and a daemon in background who handles encryption/decryption, asks for passwords if needed and makes sure that applications who want access to a encrypted container get it (e.g. dialer wants to look up a number in the phonebook). This way the containers can stay decrypted while the phone is on and access is granted dynamically (as needed). I think completely dynamic decryption would be too cumbersone to use. If you mean that it would need an unlock for every received sms (to get the contact behind the number) and phone call, it's just unfeasible. If you want to protect the en/decryption key, it needs a passphrase that is long enough to be of any benefit. The other option is a PKI enabled SIM, which would be cool. Hence it should be unlocked only once, at bootup. The sim pin could also be saved on the encrypted partition (maybe the pin itself again encrypted with the passphrase, so it's not accessible easily at runtime) so that the user only needs to authenticate once to use the phone. There could be then options to forget the encryption key either locally or via a magic sms. Yeah, it's a little much effort, but there is no security without it. If you'd encrypt the whole rootfs you'd have it decrypted the whole time the phone is on (otherwise nothing would work), what means, the security is gone. No it doesn't. Everything NEEDS to be decrypted automagically when the phone is on. Otherwise it's just unusable. The whole system shouldn't be encrypted, that's just waste. But having a personal area decrypted at startup means that only you can access it at bootup, and one can add the option of remotely disabling access to it. That is very much security, way more than phones usually have nowadays, even more than laptops/desktops, but not too much to make it hard/annoying to use. Well, that's only a part of a possible security framework, but this are only some thoughts. In addition to that, I'd say all linux security administration best practices should be at least considered, including automatic security updates. It's a standard linux system with a lightweight, but still standard, packet management, so that's how it already is handeled (well, without the automatic, but I don't like automatic updating anyway). The fact that it has package management doesn't mean much in itself. I think current linux distributions have a
Re: MokSec - The Security Framework
On Mon, Jul 14, 2008 at 5:08 PM, arne anka [EMAIL PROTECTED] wrote: And to give my 2 Eurocents to the everything as root discusion. Running user apps as root must end, better soon. what exactly speaks against creating a regular user? did anyone try it already? and where exactly is root as default user stored? In /etc/passwd :) Of course you can create another user, as you are used to on any unix system. It just doesn't ship with one because the distro comes in ready-to-deploy images, not with a installer like the binary-distro-people are used to. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Jan de Haan wrote: On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen [EMAIL PROTECTED] wrote: But there are places where you can get SIM cards with built in encyption/decryption keys, and a certificate (PKI). I agree. Would you care to elaborate (link)? Sincerely, Sure, the only one I know about directly is this, it's coordinated by the Finninsh government, and naturally only available in finland. http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone using FR as a phone?
Ah -- thanks for the clarification! How does 'running' microwave/hair drier/coffee-grinder affects it? :-) may be some obvious EM noise source like that could create an easily reproducible and controllable environment for troubleshooting/comparison to the reference phone at hands. On Mon, 14 Jul 2008, Joerg Reisenweber wrote: It's not unit specific. This at least we already can say. Slight variations in severity, but I didn't get to reproduce it even with known bad devices, here at my lab. This known bad FR performed better than a Nokia6210 I used for reference. At my lab. :-/ But it's basically a EMI-shielding issue, it seems. We're on it. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
2008/7/14 thomasg [EMAIL PROTECTED]: This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. Ok, I don't claim my guess would be truth, I'm just guessing. Is it so that when the fix has been gotten, it stays and works properly even with (supposedly) very poor antenna like Neo's, even in places where zero signal was seemingly being got before the fix was had (elsewhere)? The main interesting thing for me was that the map updated completely fine inside a car and between tall buildings, after the fix was finally gotten. Is this really possible if the problem is broken / very poor antenna that cannot receive almost any signals? If such finely working GPS function is not possible in the case antenna is so poor that these fixes are so hard to get as it seems most of the time, then it would more likely be this is the case of this (random) internal/external switch problem instead of broken antenna otherwise. Or if not that, then some other possibly software based problem related to getting the fixes - again something in which I don't know enough about GPS since I don't know if the software is supposed to do something else besides telling the GPS chip to get the fix, please. -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't boot Freerunner without battery - Was: Re: unable to start up freerunner after batterie was full down
The battery can delivery more power than the AC USB adapter? -Steven On Mon, Jul 14, 2008 at 1:18 AM, Joerg Reisenweber [EMAIL PROTECTED] wrote: Am Mo 14. Juli 2008 schrieb Steven **: Perhaps it's been said before and I missed it... But why can't the Neo boot off USB power alone? Boils down to sth like powering up a whole town after blackout. All components drawing a spike of energy same moment, which USB can't deliver. -next blackout. Werner's new U-boot extenuates this somewhat, but as much of this is inside PMU hardcoded, SW can't do much. /jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Kalle Happonen wrote: Jan de Haan wrote: On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen [EMAIL PROTECTED] wrote: But there are places where you can get SIM cards with built in encyption/decryption keys, and a certificate (PKI). I agree. Would you care to elaborate (link)? Sincerely, Sure, the only one I know about directly is this, it's coordinated by the Finninsh government, and naturally only available in finland. http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument I wish more governments would be so progressive. *g* We in Germany are botching around on this idea for years with apparently no result. But at least our politicians have the will to implement anonymous signatures, which is rather cool. Sometimes you just want to prove that you are real, and not who you actually are. Well, off topic... Congrats Finland. ;) -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
On Mon, Jul 14, 2008 at 7:02 AM, Kalle Happonen [EMAIL PROTECTED] wrote: arne anka wrote: wouldn't think it's too much. How often do you reboot the phone? with a battery uptime of about 8h -- at least once a day, because the fr usually silently shuts down. on weekends more frequently because i play around and something crashes or so. Well, this wasn't available now, was it? :). Since these are only plans, and afaik the powersave functionality will be vastly improved, that argument is hopefully invalid when the encryption is available. And if you're not willing to have the inconvenience of a long password on boot up, use an easier one. You're slightly less secure, but still more secure than having no encryption. -- Steven Kurylo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Tilman Baumann wrote: Kalle Happonen wrote: Jan de Haan wrote: On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen [EMAIL PROTECTED] wrote: But there are places where you can get SIM cards with built in encyption/decryption keys, and a certificate (PKI). I agree. Would you care to elaborate (link)? Sincerely, Sure, the only one I know about directly is this, it's coordinated by the Finninsh government, and naturally only available in finland. http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument I wish more governments would be so progressive. *g* We in Germany are botching around on this idea for years with apparently no result. But at least our politicians have the will to implement anonymous signatures, which is rather cool. Sometimes you just want to prove that you are real, and not who you actually are. Well, off topic... Congrats Finland. ;) Well it looks cool, but in practice... there's maybe 1 service that accepts these.. maybe. And the operators are clueless about it. I agree, it's great to have this infrastructure, but without services, it's just a virtual finnish penis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't boot Freerunner without battery - Was: Re: unable to start up freerunner after batterie was full down
The phone can't take 100mA from USB without asking, and the PMU enforces this. The AC PSU can supply more than this, as can most USB ports, but at this stage of the process the checks to see if this is available can't be done so we're limited to 100mA. When the old uBoot powered up the assorted chips the current would spike higher than 100mA which was fine with battery, but without battery the PMU would cut the power to stop violation of the USB 100mA limit. The new uBoot changes the power up sequence to try to keep the current below 100mA at all times. That's a rough outline anyway - full discussion in the kernel list archive. On Monday 14 July 2008, Steven ** wrote: The battery can delivery more power than the AC USB adapter? -Steven On Mon, Jul 14, 2008 at 1:18 AM, Joerg Reisenweber [EMAIL PROTECTED] wrote: Am Mo 14. Juli 2008 schrieb Steven **: Perhaps it's been said before and I missed it... But why can't the Neo boot off USB power alone? Boils down to sth like powering up a whole town after blackout. All components drawing a spike of energy same moment, which USB can't deliver. -next blackout. Werner's new U-boot extenuates this somewhat, but as much of this is inside PMU hardcoded, SW can't do much. /jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtopia on freerunner] - What is the right place to discuss Qtopia on Openmoko?
On Mon, Jul 14, 2008 at 9:27 AM, Lorn Potter [EMAIL PROTECTED] wrote: If anyone knows how to get a real battery status on the freerunner I can fix this up. I only know of /sys/devices/platform/bq27000-battery.0/power_supply/bat/status. Maybe that helps? not on my devices: [EMAIL PROTECTED]:~# cat /sys/devices/platform/bq27000-battery.0/power_supply/bat/status cat: read error: Timer expired On my device: [EMAIL PROTECTED]:~# cat /sys/devices/platform/bq27000-battery.0/power_supply/bat/status Charging - Kai Stian Olstad ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
thomasg wrote: On Mon, Jul 14, 2008 at 5:22 PM, arne anka [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Of course you can create another user, as you are used to on any unix system. It just doesn't ship with one because the distro comes in ready-to-deploy images, not with a installer like the binary-distro-people are used to. sure? i think it possible that some things won't work when non-root ... Of course some things won't work - if they would, there would be no need for a special root account. Basically all the tools someone would use without a terminal should work (dialer, contacs, ...) no matter what stack is used. The daemons that need root access run in background and can be controlled by userspace-programs without root-access. If of course would take a loginmanager or similar to use a user with password at startup, because currently the user root is automatically logged in. Should be easy to fix. Even running only critical things as root, and most stuff on a no-password unprivileged account would be better. But an user account with a password a would of course be better. The I'd say that the PIN could almost be saved somewhere, to avoid the need for a double log-in. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: warranty issues
On 7/12/08 simarillion wrote: can somebody tell me if I will lose my warranty when I open my Freerunner. Hehe...do you really think we could get away with that kind of policy?! This is Openmoko. If you /don't/ open your Neo, you should probably have your warranty voided ;-) -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Segmentation fault trying to use opkg update
Hi i don't know if the right place to post this. well, i'm triying update neo and i get this: [EMAIL PROTECTED]:~# opkg update Downloading http://www.angstrom-distribution.org/feeds/2007/ipk/glibc/armv4t/base/Packages.gz 100% || Inflating http://www.angstrom-distribution.org/feeds/2007/ipk/glibc/armv4t/base/Packages.gz Updated list of available packages in /var/lib/opkg/base Downloading http://www.angstrom-distribution.org/feeds/2007/ipk/glibc/armv4t/base/Packages.sig Segmentation fault i was looking for an answer in mailing list but not found nothing. thx very much ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
The module talks NMEA but also a ublox binary format. Among other things this allows time and location estimates, ephemeris and almanac data to be fed to the module to give it an initial state, and should reduce time to first fix. Likewise it can be used to request this data from the module so it can be saved before shutdown. 'Driver' probably isn't the right word. So we just need to wrap 'save' and 'restore' scripts around the gpsd script? ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
I've only had my freerunner for a week or so, so I'm not too into the security aspects yet. One thing I did notice was of course passwordless root login. Now over usb this can be acceptable, but if this is possible over wifi (I haven't actually tested), it needs the firewall / make it listen only to the usb. Set your own root password. Fixed. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen [EMAIL PROTECTED] wrote: thomasg wrote: On Mon, Jul 14, 2008 at 5:22 PM, arne anka [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Of course you can create another user, as you are used to on any unix system. It just doesn't ship with one because the distro comes in ready-to-deploy images, not with a installer like the binary-distro-people are used to. sure? i think it possible that some things won't work when non-root ... Of course some things won't work - if they would, there would be no need for a special root account. Basically all the tools someone would use without a terminal should work (dialer, contacs, ...) no matter what stack is used. The daemons that need root access run in background and can be controlled by userspace-programs without root-access. If of course would take a loginmanager or similar to use a user with password at startup, because currently the user root is automatically logged in. Should be easy to fix. Even running only critical things as root, and most stuff on a no-password unprivileged account would be better. But an user account with a password a would of course be better. The I'd say that the PIN could almost be saved somewhere, to avoid the need for a double log-in. I had some thoughts about that, too. Would be cool if it wasn't necessary to have a PIN at all - you enter the PIN in the first-run-wizard, that will store it. After that you only have one password (of your choise) that does all - the security daemon would lookup in a key/password-database and use your password for all things, like decrypting the other containers (phonebook, messages, e.g.), authing you on the network with the stored pin, unlocking the phone screen, . ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
thomasg wrote: On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: What an insult! *slap* :P. No I'm not a windows user. and I can set the root password on my device, but defaults matter. And they matter a lot if openmoko will become more mass-market. A firewall migth be a bit heavy, I agree, every watt and cycle should try to be saved, but making dropbear just listen to the usb interface would be a pretty good compromise, if that is possible. Ok, sorry, that was a too mean joke :P I forgive you :) The situation with no root password set is of course not bearable, but I'm pretty sure that this issue will be solved in a consumer-ready release. What I'd imagine would be a kind of first-run-guide, that forces (or allows, however you want :) ) the user to do all the important settings at the first run of the phone (could be used for backup purposes, too, e.g. load an xml-file with the settings). Would make the life way easier for newbies. That would make sense yes. And since it's a pretty complex device, a first-run setup is almost needed anyway. However, later on an easily configurable firewall would be almost essential imho. Connecting to the phone (any port) over the wifi should (almost?)never be allowed as default. Even if the point with the phone is that users can do what they want, it doesn't mean that the apps they install shouldn't be protected. And a firewall is almost the only viable way. There's no easy way of making all the apps listen to just one interface, and while host.allow/deny is more lightweight than a firewall, those don't allow distinguishing of interface. A firewall is always a more or less big piece of software, always not the best for performance, and always a security risk (if it's not dedicated). It also is not possible to do a easy and _good_ configuration, so however it's done, it's always suboptimal. There are not too much services running, and all of them are open source software, so that is imho not that a big deal. iptables fits into a small kernel, that's not big software :). It might have some performance hits, but with these traffic amounts it shouldn't matter. The big but is of course the frontend to it. And open source software isn't immune to vulnerabilities :). Security patches help, but if possible, I'd still go for a firewall. In addition to that, a separate encrypted partition for /root (or /home if the account will changed to a non-privileged user) could be nice, but maybe too heavy and battery draining? Imho it's not needed to encrypt the whole system. Would be the better choice to have some crypto-containers for the files that really need to be secured (phonebook, messages, important documents). We had some discussion in IRC a while ago and my idea would No, not the whole system. But well the user homedir would be basically what we want to protect, and if it was on it's own partition, there is kernel support for it already. be to have that containers and a daemon in background who handles encryption/decryption, asks for passwords if needed and makes sure that applications who want access to a encrypted container get it (e.g. dialer wants to look up a number in the phonebook). This way the containers can stay decrypted while the phone is on and access is granted dynamically (as needed). I think completely dynamic decryption would be too cumbersone to use. If you mean that it would need an unlock for every received sms (to get the contact behind the number) and phone call, it's just unfeasible. If you want to protect the en/decryption key, it needs a passphrase that is long enough to be of any benefit. The other option is a PKI enabled SIM, which would be cool. Hence it should be unlocked only once, at bootup. The sim pin could also be saved on the encrypted partition (maybe the pin itself again encrypted with the passphrase, so it's not accessible easily at runtime) so that the user only needs to authenticate once to use the phone. There could be then options to forget the encryption key either locally or via a magic sms. Yeah, it's a little much effort, but there is no security without it. If you'd encrypt the whole rootfs you'd have it decrypted the whole time the phone is on (otherwise nothing would work), what means, the security is gone. No it doesn't. Everything NEEDS to be decrypted automagically when the phone is on. Otherwise it's just unusable. The whole system shouldn't be encrypted, that's just waste. But having a personal area decrypted at startup means that only you can access it at
Re: GPS
On Mon, Jul 14, 2008 at 4:23 PM, Jay Vaughan [EMAIL PROTECTED] wrote: The module talks NMEA but also a ublox binary format. Among other things this allows time and location estimates, ephemeris and almanac data to be fed to the module to give it an initial state, and should reduce time to first fix. Likewise it can be used to request this data from the module so it can be saved before shutdown. 'Driver' probably isn't the right word. So we just need to wrap 'save' and 'restore' scripts around the gpsd script? Basically yes, but this won't fix the problem. It's for later when the problem is fixed, so you wouldn't have to wait a minute for the fix but 10 seconds. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Mon, Jul 14, 2008 at 2:12 PM, Ken Young [EMAIL PROTECTED] wrote: thomasg wrote: This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. Well, I know the freerunner is no specialized gps navigation device, but the fact that the signals are so weak that it's barely possible to get a fix under optimal condition (clear view to the sky, antenna on top, without moving 1 mm) shows, that this is no simple software problem and has to be fixed. The GPS performance of my Freerunner is also much worse than the GPS performance of my neo1973. I've done side-by-side tests of the two units many times. My neo1973 gets a good fix in 2 to 3 minutes after a completely cold start; it's very reliable. My Freerunner initially was getting a fix after 7 or 8 minutes. For the last few days it has not been able to get a fix at all. Ken Young I can confirm that, too. The 1973 gets a cold start fix in less than 2 minutes. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
This will be my 3rd GPS device in ~5 years. The first two - a NAVMAN from New Zealand and a Garmin - always had exceedingly long cold starts (i.e. turn the device off, fly 1500 km, turn device on), on the order of 10 minutes. I still have the Garmin in working condition, it is the Garmin 10, a bluetooth model. If some one could help me with the FR bluetooth, and the GSP applications, I could connect to FR gps stack to the Garmin to isolate them from the on board chip. This would, of course. assume that the bluetooth stack didn't cloud any issue. Thoughts, how-tos? Chris On Jul 14, 2008, at 7:23 AM, Jay Vaughan wrote: The module talks NMEA but also a ublox binary format. Among other things this allows time and location estimates, ephemeris and almanac data to be fed to the module to give it an initial state, and should reduce time to first fix. Likewise it can be used to request this data from the module so it can be saved before shutdown. 'Driver' probably isn't the right word. So we just need to wrap 'save' and 'restore' scripts around the gpsd script? ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
When does it suspend?
Hi, Am Montag, den 14.07.2008, 11:20 +0200 schrieb arne anka: experienced that (no o2 user!) with power management set to dim first, then lock. after switching to dim only, don't lock i didn't see it anymore -- but the fr still locks ... speaking of suspend mode: When is the Freerunner supposed to suspend automatically? After a certain time with the Lock Screen active, or after a certain time with no user input? Note that the latter causes problems when there is constant random „input“ (Freerunner in the pocket). And it’s not suspended when I can activate it by touching the screen, right? And is there a way to manually put the Freerunner to screen? Greetings and thanks, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
What is meant by cold start? Is this simply a power off and power back on? Or is it the power cycle and no previous fix data for current location? With other GPS devices, until that first location fix was achieved, nothing happened, but once achieved and no significant change in geography, then a fix could be achieved in less than a few minutes. Given that most of these devices are being received in a location different than where ever the device may have previously gotten a fix, my thought is part of the problem is getting that first current location fix. Chris On Jul 14, 2008, at 9:23 AM, thomasg wrote: On Mon, Jul 14, 2008 at 2:12 PM, Ken Young [EMAIL PROTECTED] wrote: thomasg wrote: This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. Well, I know the freerunner is no specialized gps navigation device, but the fact that the signals are so weak that it's barely possible to get a fix under optimal condition (clear view to the sky, antenna on top, without moving 1 mm) shows, that this is no simple software problem and has to be fixed. The GPS performance of my Freerunner is also much worse than the GPS performance of my neo1973. I've done side-by-side tests of the two units many times. My neo1973 gets a good fix in 2 to 3 minutes after a completely cold start; it's very reliable. My Freerunner initially was getting a fix after 7 or 8 minutes. For the last few days it has not been able to get a fix at all. Ken Young I can confirm that, too. The 1973 gets a cold start fix in less than 2 minutes. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokSec - The Security Framework
Kalle Happonen wrote: Well, off topic... Congrats Finland. ;) Well it looks cool, but in practice... there's maybe 1 service that accepts these.. maybe. And the operators are clueless about it. I agree, it's great to have this infrastructure, but without services, it's just a virtual finnish penis Well, then congrats for the largest virtual penis. Who needs real success in times of the internet where fame is everything. *g* -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
So we just need to wrap 'save' and 'restore' scripts around the gpsd script? Basically yes, but this won't fix the problem. It's for later when the what exactly is the gpsd for, anyway? looking at my fr yesterday i noticed it is not installed anymore, if it ever was, that is, (and not available in the official feeds i got in my opkg-config). with agpsui i got one fix once, putting the fr in my bag and cycling home -- after 2/3 in a park i looked and it got a fix and ttff 1400. it was the only time i got one, so i wonder if the gpsd may somehow be involved ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
with cold start they mean no previous data: no information about satellites, location or time since the GPS chip itself does not have any memory, currently a power off - power on always results in a cold start (there is however some work being done to overcome this, but I don't know if it is already working) On Mon, Jul 14, 2008 at 6:33 PM, C R McClenaghan [EMAIL PROTECTED] wrote: What is meant by cold start? Is this simply a power off and power back on? Or is it the power cycle and no previous fix data for current location? With other GPS devices, until that first location fix was achieved, nothing happened, but once achieved and no significant change in geography, then a fix could be achieved in less than a few minutes. Given that most of these devices are being received in a location different than where ever the device may have previously gotten a fix, my thought is part of the problem is getting that first current location fix. Chris On Jul 14, 2008, at 9:23 AM, thomasg wrote: On Mon, Jul 14, 2008 at 2:12 PM, Ken Young [EMAIL PROTECTED] wrote: thomasg wrote: This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. Well, I know the freerunner is no specialized gps navigation device, but the fact that the signals are so weak that it's barely possible to get a fix under optimal condition (clear view to the sky, antenna on top, without moving 1 mm) shows, that this is no simple software problem and has to be fixed. The GPS performance of my Freerunner is also much worse than the GPS performance of my neo1973. I've done side-by-side tests of the two units many times. My neo1973 gets a good fix in 2 to 3 minutes after a completely cold start; it's very reliable. My Freerunner initially was getting a fix after 7 or 8 minutes. For the last few days it has not been able to get a fix at all. Ken Young I can confirm that, too. The 1973 gets a cold start fix in less than 2 minutes. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: MokSec - The Security Framework
There's apps that do this, like kdewallet. I was thinking of a picture pin entry. You display a small set of pictures with lots of detail, user must tap 1 or more points on each pictures. Quick entry, good number of bits of encryption, easy to remeber. Plus, when the phone comes up with a picture, to anybody else it just looks like it's stuck booting or broken. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of thomasg Sent: Monday, July 14, 2008 12:19 PM To: List for Openmoko community discussion Subject: Re: MokSec - The Security Framework On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen [EMAIL PROTECTED] wrote: I had some thoughts about that, too. Would be cool if it wasn't necessary to have a PIN at all - you enter the PIN in the first-run-wizard, that will store it. After that you only have one password (of your choise) that does all - the security daemon would lookup in a key/password-database and use your password for all things, like decrypting the other containers (phonebook, messages, e.g.), authing you on the network with the stored pin, unlocking the phone screen, . ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When does it suspend?
speaking of suspend mode: When is the Freerunner supposed to suspend automatically? After a certain time with the Lock Screen active, or after a certain time with no user input? the latter, i think. Note that the latter causes problems when there is constant random „input“ (Freerunner in the pocket). yepp -- it's rather annoying. i think a menu entry for the power or aux menu is needed, disabling the screen completely. accepring a call could be done by hitting aux and the screen may (configurable) switch on while calling. And it’s not suspended when I can activate it by touching the screen, depends probably on your definition of suspend. right? And is there a way to manually put the Freerunner to screen? put to screen? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: warranty issues
Sean Moss-Pultz wrote: This is Openmoko. If you /don't/ open your Neo, you should probably have your warranty voided ;-) Wow, second best quote I've ever seen on this list. The first being back in early May... Andy Powell wrote: Seriously, If everyone put as much effort into development as they do into bitching and whining this phone would be able to cure cancer by now. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Monday 14 July 2008, arne anka wrote: So we just need to wrap 'save' and 'restore' scripts around the gpsd script? Basically yes, but this won't fix the problem. It's for later when the what exactly is the gpsd for, anyway? looking at my fr yesterday i noticed it is not installed anymore, if it ever was, that is, (and not available in the official feeds i got in my opkg-config). gpsd is there so that more than one program can access the GPS device at the same time, making it available over a network interface. Some apps can access GPS data via gpsd but not directly from the device. I think tangogps is among them. Gypsy does something similar but shares it using dbus, and claims to be more efficient. FSO will apparently be using gypsy instead of gpsd, but currently more apps can connect to gpsd than gypsy. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Mon, Jul 14, 2008 at 6:42 PM, arne anka [EMAIL PROTECTED] wrote: So we just need to wrap 'save' and 'restore' scripts around the gpsd script? Basically yes, but this won't fix the problem. It's for later when the what exactly is the gpsd for, anyway? looking at my fr yesterday i noticed it is not installed anymore, if it ever was, that is, (and not available in the official feeds i got in my opkg-config). with agpsui i got one fix once, putting the fr in my bag and cycling home -- after 2/3 in a park i looked and it got a fix and ttff 1400. it was the only time i got one, so i wonder if the gpsd may somehow be involved ... Afaik gpsd is only used to make the NMEA data more accessible without having every app to parse it and some other minor things that makes handling easier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When does it suspend?
Hi, Am Montag, den 14.07.2008, 18:47 +0200 schrieb arne anka: speaking of suspend mode: When is the Freerunner supposed to suspend automatically? After a certain time with the Lock Screen active, or after a certain time with no user input? the latter, i think. Note that the latter causes problems when there is constant random „input“ (Freerunner in the pocket). yepp -- it's rather annoying. i think a menu entry for the power or aux menu is needed, disabling the screen completely. accepring a call could be done by hitting aux and the screen may (configurable) switch on while calling. I think it would be enough if it would not take input at the lock screen into account for the suspend counter, so that the phone can still suspend when carried around. And it’s not suspended when I can activate it by touching the screen, depends probably on your definition of suspend. right? And is there a way to manually put the Freerunner to screen? put to screen? sorry, put to sleep or put to suspend – too many s-words in my mind at the same time :-) Also, when it’s in sleep mode, does the LED still work, e.g. tell me about unread SMS or missed calls? If not, is that technically possible? Greetings, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
Today I powered up my gps the first time and got a fix after 80 seconds. I was on a hill in a small village outside in a garden under a apple tree and the Freerunner was standing upright. Then I rebooted it and got an other fix in 80 seconds again. I've been using agps-gui. Much better than I expected. The Freerunner did see 5 satellites the first time, 3 the second time. Michael Ken Young schrieb: thomasg wrote: This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in 3 minutes at 100 km/h. Well, I know the freerunner is no specialized gps navigation device, but the fact that the signals are so weak that it's barely possible to get a fix under optimal condition (clear view to the sky, antenna on top, without moving 1 mm) shows, that this is no simple software problem and has to be fixed. The GPS performance of my Freerunner is also much worse than the GPS performance of my neo1973. I've done side-by-side tests of the two units many times. My neo1973 gets a good fix in 2 to 3 minutes after a completely cold start; it's very reliable. My Freerunner initially was getting a fix after 7 or 8 minutes. For the last few days it has not been able to get a fix at all. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Anyone in NYC with an extra Freerunner?
Hello, So I missed my chance to get a Freerunner, and they won't take my credit cards. But on my flight back to Cape Town Delta screwed up and I missed my flight, so now I'm staying at my uncles place. Does anyone near New York City or within 120km of Trumbull, CT have a Freerunner that they would be willing to sell for $450? Thanks! Federico ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When does it suspend?
right? And is there a way to manually put the Freerunner to screen? put to screen? sorry, put to sleep or put to suspend – too many s-words in my mind at the same time :-) power menu has a lock display entry -- might send the fr to bed. else, maybe somewhere below /sys/ ... Also, when it’s in sleep mode, does the LED still work, e.g. tell me about unread SMS or missed calls? If not, is that technically possible? well, with 2007.2 leds do not work at all, by fiddling with /sys/.../leds/.../trigger i was able to get a led after the fr was charged, but not while charging (despite the trigger's name charge-and-full or so). regarding your muttons: i think technically it should be rather easy (other phones can do, too), but that's mostly kernel land, imho. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
Today I powered up my gps the first time and got a fix after 80 seconds. I was on a hill in a small village outside in a garden under a apple tree and the Freerunner was standing upright. Then I rebooted it and got an other fix in 80 seconds again. I've been using agps-gui. Much better than I expected. The Freerunner did see 5 satellites the first time, 3 the second time. i am afraid, most people on this list will hate you now :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
maybe we just need more people testing it under an apple tree? has Openmoko remembered to put in the magic GPS apple seeds? seriously: somebody dissect the freerunner of michael :) On Mon, Jul 14, 2008 at 7:22 PM, arne anka [EMAIL PROTECTED] wrote: Today I powered up my gps the first time and got a fix after 80 seconds. I was on a hill in a small village outside in a garden under a apple tree and the Freerunner was standing upright. Then I rebooted it and got an other fix in 80 seconds again. I've been using agps-gui. Much better than I expected. The Freerunner did see 5 satellites the first time, 3 the second time. i am afraid, most people on this list will hate you now :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
arne anka schrieb: Today I powered up my gps the first time and got a fix after 80 seconds. I was on a hill in a small village outside in a garden under a apple tree and the Freerunner was standing upright. Then I rebooted it and got an other fix in 80 seconds again. I've been using agps-gui. Much better than I expected. The Freerunner did see 5 satellites the first time, 3 the second time. i am afraid, most people on this list will hate you now :-) Well, this test scenario on a hill within Europe without buildings around is probably the best case for GPS. I will try again tomorrow by powering it up and driving 15 minutes with the bicycle to work. Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
have a look at the archives -- there were some lengthy threads about that recently ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
On Mon, Jul 14, 2008 at 1:37 PM, Francesco Cat [EMAIL PROTECTED] wrote: Nvidia seems to care about Linux and OpenSource In what world have you been living for the last 10 years or so? --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
A refinement on the thought below - how to pipe the NMEA data to a bluetooth serial port so I can connect my Palm TX and run its mapping off the FR GPS chip data. If anyone could provide pointers on setting up bluetooth serial connections to/from the FR I'd appreciate it. Thanks, Chris On Jul 14, 2008, at 9:26 AM, C R McClenaghan wrote: This will be my 3rd GPS device in ~5 years. The first two - a NAVMAN from New Zealand and a Garmin - always had exceedingly long cold starts (i.e. turn the device off, fly 1500 km, turn device on), on the order of 10 minutes. I still have the Garmin in working condition, it is the Garmin 10, a bluetooth model. If some one could help me with the FR bluetooth, and the GSP applications, I could connect to FR gps stack to the Garmin to isolate them from the on board chip. This would, of course. assume that the bluetooth stack didn't cloud any issue. Thoughts, how-tos? Chris On Jul 14, 2008, at 7:23 AM, Jay Vaughan wrote: The module talks NMEA but also a ublox binary format. Among other things this allows time and location estimates, ephemeris and almanac data to be fed to the module to give it an initial state, and should reduce time to first fix. Likewise it can be used to request this data from the module so it can be saved before shutdown. 'Driver' probably isn't the right word. So we just need to wrap 'save' and 'restore' scripts around the gpsd script? ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
Francesco Cat wrote: I found this System on a Chip by NVidia: http://www.nvidia.com/object/tegra_600.html and http://www.nvidia.com/object/apx_2500.html It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;) What do you think about? Will we have a chance to see it? Or it is pure dreaming since it won't be open at all? Nvidia seems to care about Linux and OpenSource, we might try a ride ;) OpenSource ? They care about Linux (good thing [?!?!]) cause they have a market opportunity there. I am not so sure they care about opensource at all. I like nVidia graphics cause they have both performance and a nice driver. But, if I had a choice, I'd choose some other vendor. Álvaro ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
Francesco Cat wrote: I found this System on a Chip by NVidia: http://www.nvidia.com/object/tegra_600.html and http://www.nvidia.com/object/apx_2500.html It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;) What do you think about? Will we have a chance to see it? Or it is pure dreaming since it won't be open at all? Nvidia seems to care about Linux and OpenSource, we might try a ride ;) Where do you see any real care about Linux and OpenSource from nvidia? If, then they only care a little bit about Linux, but they don't seem to care about OpenSource at all - at least this is the case for their graphics chips. I can't find any register specification or open drivers for this SOC either. Greetings, silwol. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
On Mon, Jul 14, 2008 at 7:37 PM, Francesco Cat [EMAIL PROTECTED] wrote: I found this System on a Chip by NVidia: http://www.nvidia.com/object/tegra_600.html and http://www.nvidia.com/object/apx_2500.html It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;) What do you think about? Will we have a chance to see it? Or it is pure dreaming since it won't be open at all? Nvidia seems to care about Linux and OpenSource, we might try a ride ;) Let's make it short: not gonna happen. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
on heise.de they wrote something about windows-support only. Francesco Cat schrieb: I found this System on a Chip by NVidia: http://www.nvidia.com/object/tegra_600.html and http://www.nvidia.com/object/apx_2500.html It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;) What do you think about? Will we have a chance to see it? Or it is pure dreaming since it won't be open at all? Nvidia seems to care about Linux and OpenSource, we might try a ride ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
Ok fine sorry for mistakes about OpenSource and whatever. 2008/7/14 thomasg [EMAIL PROTECTED]: On Mon, Jul 14, 2008 at 7:37 PM, Francesco Cat [EMAIL PROTECTED] wrote: I found this System on a Chip by NVidia: http://www.nvidia.com/object/tegra_600.html and http://www.nvidia.com/object/apx_2500.html It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;) What do you think about? Will we have a chance to see it? Or it is pure dreaming since it won't be open at all? Nvidia seems to care about Linux and OpenSource, we might try a ride ;) Let's make it short: not gonna happen. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
http://wiki.openmoko.org/wiki/GPS#GTA02 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NVidia S-O-C
On Mon, Jul 14, 2008 at 1:51 PM, Francesco Cat [EMAIL PROTECTED] wrote: Ehm... I don't get what you meant to say... You said you thought they cared about Linux / Open Source. In the last 10 years, I haven't seen a single hint that they do. One possible (absurd) explanation is that we've been observing different Nvidias from different worlds or dimensions. Hence the question. --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
Thanks for this, I also found how to go the other direction on the wiki. Right now I have the AGPS application reading data from the Garmin. Three minutes have passed and no fix yet. Will try Tango and then reverse the scenario for the Palm TX. L8r, Chris On Jul 14, 2008, at 10:54 AM, arne anka wrote: http://wiki.openmoko.org/wiki/GPS#GTA02 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New Freerunner, factory image - Registering...
Hi there, So my Freerunner arrived this evening, I plugged it in and started charging and it powered itself on. I _love_ that kernel messages are displayed during boot-up, and the plastic of the Freerunner's case has a really nice feel to it. Anyway, once booted to the factory image I get continuously a Registering... message in the top-left corner of the Home screen. After 30 minutes or so this message persists. Cell phone reception in my flat is always a little poor - I have to walk to the window if I want an intelligible conversation - but all other phones have connected to the phone network fine, SMS'd and rung on incoming calls fine when located at my desk. Could this indicate that my SIM is amongst those which the Freerunner doesn't like? It is a UK O2 SIM, at least a couple of years old, probably several and perhaps 7 or 8. It has been used last in my Sony-Ericsson P990i which is 3G, but I have no idea if that phone has been used at full speed. I find that when I received this P990i, c 15 months ago, O2 sent me a new SIM which is marked as 3G, but I have never used it as the phone seemed to work fine with the old one. It is very nice that a terminal app is included on the default image, but I cannot work out how to enter a forward-slash (/), so cannot list /var/log and see if there's anything interesting in there. Would I be best advised to set up USB networking and log in via SSH to see what's going on? Having plugged it into the wall and started it charging for the first time I am reluctant to unplug it until it is fully charged, as per the instructions. So any suggestions of how to debug this from the phone's own console would be appreciated. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
