Re: Bounty for Navit delopment - Free freerunner - anyone?
"arne anka" writes: > is this part of the official navit sources? The cache size setting at least is. Look for cache in ./configure --help or svn log ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Bounty for Navit delopment - Free freerunner - anyone?
> I suggest you all try the new navit > (http://download.navit-project.org/navit/openmoko/svn/navit-svn-2308_armv4t.opk) > it has a few improvements which MAKE IT USABLE WITH OSM (seems like it > was already usable with map&guide reiseplanner): > *added a 20 MB cache for the FR > *there was a bug until a few days ago which made the navigation to > recalculate at every update (mostly with OSM) > > time to calculate route is now acceptable and re-calculating also! is this part of the official navit sources? i use to grab once in a while a debianized source tar ball and create an armel deb. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
> I've still seen varying opinions on these mailing lists ranging from > 'only > 5% of people need the buzz fix' to 'everyone with an A5 or A6 needs the > buzz > fix'. they're not really varying -- it's like learning to swim: if you are absolutely sure, you'll never get into deep water, there's no need to spend time learning how to swim. but if you're unsure, you better do it. it's the same with the buzz fix: if you don't experience it and if you are absolutely sure, the location and conditions your fr works under will never change, no need to fix. technically, though, the buzz is there and you might experience it when you expect it the least. so, if you got the opportunity to get the fix applied, use it -- better safe than sorry. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Hi Joerg, I certainly don't mean to downplay the research you did - I was just trying to explain the experiences I've had. When I set control.5 to about 85 I no longer heard a buzz when I called myself on a phone - A few people complained that I sounded a bit muffled, so I reset it to the 101 (same as gsmhandset-a7.state), and since then it seems pretty good - my wife has complained once about some intermittent minor buzz, but I've had a number of phone conversations where people said I sounded fine. I've still seen varying opinions on these mailing lists ranging from 'only 5% of people need the buzz fix' to 'everyone with an A5 or A6 needs the buzz fix'. Is the official line that everyone with an A5 or A6 would benefit from the buzz fix? Warren On Mon, Jun 8, 2009 at 9:49 AM, Joerg Reisenweber wrote: > > > Warren said: > > > > "I've always had people complain that they got a lot of static when > > they called me - I thought I had the buzz problem in fact. I just > > spent the time to figure out how to use alsamixer to tweak things, and > > if I set control.5 (Mono Playback Volume) to 83 from above 100 like > > I've seen in other gsmhandset.state files (ranging from 100 to 110 > > seems normal), I get a perfectly clear signal on the other end." > > Another unconfirmed taletelling about Buzzfix by ALSA settings. Don't you > think we checked this prior to coming up with a hw-rework after months and > months of wrestling with this issue? > /j > > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support > > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Please note the hardware revisions A5 and A6 have a hardware defect that is being recalled. To determine your hardware revision http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware#Distinguishing_hardware_revisions I was notified by the vendor I purchased my freerunner from. Figured I would share this info. On Mon, Jun 8, 2009 at 10:29 AM, Joerg Reisenweber wrote: > Am Mo 8. Juni 2009 schrieb Risto H. Kurppa: > > > Joerg, I also tested this by lowering Mono to 72 with alsa-mixer on my > > > A6 OM2009 Test4 after reading Warrens mail, and I now no longer sound > > > like sitting on a motor lawnmower during a call. > > > > > > Maybe this is something different than the Buzz Issue, but it improves > > > sounds for the other party a lot. > > > > I've experienced that on some settings the background noise of my > > environment (=cars / computer fan / air conditioning / ...) is > > amplified a lot when I'm silent and the person I'm talking to can hear > > it. It isn't easy to recognice what's the source of the noise but I'd > > say there's some tunign to do to make this work. So I don't think it's > > the actual buzz but amplifying the environment. > > > > r > > See my other post wrt EC and calypso noisegate. Basically I'm telling your > story there. > > cheers > jOERG > > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support > > -- Paul Email - pault...@gmail.com There were moments when he looked on evil simply as a mode through which he could realize his conception of the beautiful. Oscar Wilde - The Picture of Dorian Gray ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Review of Om2009 release 4 & freerunner recall
Great, thanks for reporting allt his and it's great to hear you think it's the most stable release :) Could you please report the bugs to http://www.paroli-project.org/trac so they will not be forgotten in the mail archives but are ironed out! Some comments inline: On Mon, Jun 8, 2009 at 5:19 PM, Paul wrote: > I wanted to point out a couple of things. > 1. Previously I complained about the buzz issue. I just got an email > notifying that my Freerunner has a hardware defect and they are doing a > recall to rectify the situation. I have a a5 hardware revision. If this > really is the problem, then this complaint may be moot. Yep, A5 has the buzz issue (and the badness depends on the GSM frequencies) > 4. The UI seems sluggish, typing, bringing up menus, etc. The latest unstable has some great updates there waiting to be released as testing image : > 6. (parolli) Call Log/SMS does not elegantly handle the prepended 1 in phone > numbers. This causes contacts without the prepended 1 to not be associated. I think this is reported in trac somewhere.. I hope it'll be fixed soon.. > This release is a good start. When these bugs are ironed out, it'll be a > great foundation to build an app library on. Indeed!! ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Am Mo 8. Juni 2009 schrieb Risto H. Kurppa: > > Joerg, I also tested this by lowering Mono to 72 with alsa-mixer on my > > A6 OM2009 Test4 after reading Warrens mail, and I now no longer sound > > like sitting on a motor lawnmower during a call. > > > > Maybe this is something different than the Buzz Issue, but it improves > > sounds for the other party a lot. > > I've experienced that on some settings the background noise of my > environment (=cars / computer fan / air conditioning / ...) is > amplified a lot when I'm silent and the person I'm talking to can hear > it. It isn't easy to recognice what's the source of the noise but I'd > say there's some tunign to do to make this work. So I don't think it's > the actual buzz but amplifying the environment. > > r See my other post wrt EC and calypso noisegate. Basically I'm telling your story there. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Am Mo 8. Juni 2009 schrieb openm...@humilis.net: > Joerg Reisenweber wrote (ao): > > Am Do 4. Juni 2009 schrieb William Ray Yeager: > > > A critical friend of mine who has mocked my purchase of an > > > "unfinished" phone just told me that our connection was as good as a > > > landline! I followed Warren's advice below and lowered control.5 to > > > 80 (I'm naturally conservative) which has (so far) completely removed > > > the previously unbearable buzz my friend had observed on the other end > > > of the conversation. Wow. Now I might not need to solder in a new > > > capacitor! > > > > > > For the demi-newbie: > > > > > > Open /usr/share/openmoko/scenarios/gsmhandset.state > > > Scroll down to control.5 and in that section change the line under > > > 'Mono Playback Volume' from "value 110" to "value 80". > > > Save file. > > > Call OM skeptic. > > > Gloat. > > > > > > Warren said: > > > > > > "I've always had people complain that they got a lot of static when > > > they called me - I thought I had the buzz problem in fact. I just > > > spent the time to figure out how to use alsamixer to tweak things, and > > > if I set control.5 (Mono Playback Volume) to 83 from above 100 like > > > I've seen in other gsmhandset.state files (ranging from 100 to 110 > > > seems normal), I get a perfectly clear signal on the other end." > > > > Another unconfirmed taletelling about Buzzfix by ALSA settings. Don't you > > think we checked this prior to coming up with a hw-rework after months and > > months of wrestling with this issue? > > Joerg, I also tested this by lowering Mono to 72 with alsa-mixer on my > A6 OM2009 Test4 after reading Warrens mail, and I now no longer sound > like sitting on a motor lawnmower during a call. > > Maybe this is something different than the Buzz Issue, but it improves > sounds for the other party a lot. > > This btw is in The Netherlands. After reading that less than 5% of the > owners are hit in practice by the Buzz Issue, I was pretty surprised to > be one of them. But now it seems the noise is not due to the Buzz Issue? reducing mic gain and/or mic volume might cause some of the many sound improvement circuits involved in carriers' exchange (here: half duplex echo cancellation, kind of a two-way noise gate) to cut out buzz during periods of no voice transmitted. Nevertheless the S/N ratio *during talking* (S=your voice, N=buzz) can NOT be changed by alsa settings any way whatsoever. So this change of control.5 may improve some of the subjective audio sensation for far end, only if you got slight buzz that becomes unnoticeable during actual voice. Severe buzz rendering voice illegible can NOT be cured this way, not even a little bit. btw you can get same result (without lowering volume of your voice for far end, and without relying on carrier's/far-end's EC meassures) by setting AT%N noise gate value of Calypso to a level that effectively stops buzz during periods of no voice (aka silence) Official recommendation is: If you got Buzz issue, try to get bigC-buzzfix. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Om2009] PIN & PUK
On Mon, 2009-06-08 at 12:39 +0100, Al Johnson wrote: > On Monday 08 June 2009, David Fokkema wrote: > > On Mon, 2009-06-08 at 12:15 +0300, Risto H. Kurppa wrote: > > > On Mon, Jun 8, 2009 at 11:36 AM, David Fokkema wrote: > > > > Hi list, > > > > > > > > Getting a bit too confident, I decided to change the PIN (default ) > > > > of my SIM. > > > > > > > > 1. Paroli doesn't require you to re-enter the PIN, to make sure you > > > > made no typo's. > > > > > > > > 2. Paroli doesn't give feedback on incorrect old PIN values, so you > > > > don't really know for sure the PIN was actually changed. > > > > > > > > 3. On startup, unlocking the phone with your PIN is not very verbose. > > > > An incorrect PIN results in another 'enter your PIN' screen, but > > > > nothing like 'PIN incorrect, only 2 tries left'. > > > > > > > > 4. When the SIM is blocked (incorrect PIN) nothing shows in Paroli. It > > > > doesn't tell you that the SIM is blocked and that you now need to enter > > > > your PUK code. Having already tried a few times, I asked a colleague > > > > for his unlocked phone to really make sure I wouldn't block the SIM by > > > > entering incorrect PUK codes. > > > > > > > > So, does anyone dare reproducing this, ;-) ? > > > > > > Thank you David for sharing your experience! I don't think we'll soon > > > find anyone ready to test this (maybe with old SIM cards..). Could you > > > please report all this to http://www.paroli-project.org/trac so it > > > will not get lost in the mail archives. I think this is something > > > quite important to be fixed.. > > > > I might try a few times. Apparently, as long as you're not entering an > > incorrect PUK code ten times, all is well. Of course, an unlocked phone > > nearby is necessary to the whole procedure. > > Why? You can just use mdbus to enter the PUK and set the PIN: > > http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.SIM.html;hb=HEAD#Unlock Sure, but I didn't really know if paroli had already sent several invalid PIN attempts as actual PUK attempts (and I thus had maybe only a few attempts left). I really wanted to make sure I didn't lock my SIM permanently. When running tests and keeping track of your failed attempts, you'll be quicker running the actual AT commands, of course. Thanks for the pointer BTW, didn't know this one. Maybe this deserves a nice wiki page. David ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Review of Om2009 release 4 & freerunner recall
So I've been using the latest testing build of Om2009 release 4. This build is the most stable release I've tested to date provided all you use it for is phone calls. Paroli seems fairly stable. I wanted to point out a couple of things. 1. Previously I complained about the buzz issue. I just got an email notifying that my Freerunner has a hardware defect and they are doing a recall to rectify the situation. I have a a5 hardware revision. If this really is the problem, then this complaint may be moot. 2. Parolli occasionally will become unresponsive after a call/sms message (This was listed as a bug) 3. Using GPRS will cause the phone to crash after a couple of minutes. Once I turn this on, I have to restart in order to use the telephone features again 4. The UI seems sluggish, typing, bringing up menus, etc. 5. Using GPS (TangoGPS) causes xglamo to eat cpu. 6. (parolli) Call Log/SMS does not elegantly handle the prepended 1 in phone numbers. This causes contacts without the prepended 1 to not be associated. This release is a good start. When these bugs are ironed out, it'll be a great foundation to build an app library on. -- Paul Email - pault...@gmail.com There were moments when he looked on evil simply as a mode through which he could realize his conception of the beautiful. Oscar Wilde - The Picture of Dorian Gray ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
> Joerg, I also tested this by lowering Mono to 72 with alsa-mixer on my > A6 OM2009 Test4 after reading Warrens mail, and I now no longer sound > like sitting on a motor lawnmower during a call. > > Maybe this is something different than the Buzz Issue, but it improves > sounds for the other party a lot. I've experienced that on some settings the background noise of my environment (=cars / computer fan / air conditioning / ...) is amplified a lot when I'm silent and the person I'm talking to can hear it. It isn't easy to recognice what's the source of the noise but I'd say there's some tunign to do to make this work. So I don't think it's the actual buzz but amplifying the environment. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Joerg Reisenweber wrote (ao): > Am Do 4. Juni 2009 schrieb William Ray Yeager: > > A critical friend of mine who has mocked my purchase of an > > "unfinished" phone just told me that our connection was as good as a > > landline! I followed Warren's advice below and lowered control.5 to > > 80 (I'm naturally conservative) which has (so far) completely removed > > the previously unbearable buzz my friend had observed on the other end > > of the conversation. Wow. Now I might not need to solder in a new > > capacitor! > > > > For the demi-newbie: > > > > Open /usr/share/openmoko/scenarios/gsmhandset.state > > Scroll down to control.5 and in that section change the line under > > 'Mono Playback Volume' from "value 110" to "value 80". > > Save file. > > Call OM skeptic. > > Gloat. > > > > Warren said: > > > > "I've always had people complain that they got a lot of static when > > they called me - I thought I had the buzz problem in fact. I just > > spent the time to figure out how to use alsamixer to tweak things, and > > if I set control.5 (Mono Playback Volume) to 83 from above 100 like > > I've seen in other gsmhandset.state files (ranging from 100 to 110 > > seems normal), I get a perfectly clear signal on the other end." > > Another unconfirmed taletelling about Buzzfix by ALSA settings. Don't you > think we checked this prior to coming up with a hw-rework after months and > months of wrestling with this issue? Joerg, I also tested this by lowering Mono to 72 with alsa-mixer on my A6 OM2009 Test4 after reading Warrens mail, and I now no longer sound like sitting on a motor lawnmower during a call. Maybe this is something different than the Buzz Issue, but it improves sounds for the other party a lot. This btw is in The Netherlands. After reading that less than 5% of the owners are hit in practice by the Buzz Issue, I was pretty surprised to be one of them. But now it seems the noise is not due to the Buzz Issue? With kind regards, Sander -- Humilis IT Services and Solutions http://www.humilis.net ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Am Do 4. Juni 2009 schrieb William Ray Yeager: > A critical friend of mine who has mocked my purchase of an > "unfinished" phone just told me that our connection was as good as a > landline! I followed Warren's advice below and lowered control.5 to > 80 (I'm naturally conservative) which has (so far) completely removed > the previously unbearable buzz my friend had observed on the other end > of the conversation. Wow. Now I might not need to solder in a new > capacitor! > > For the demi-newbie: > > Open /usr/share/openmoko/scenarios/gsmhandset.state > Scroll down to control.5 and in that section change the line under > 'Mono Playback Volume' from "value 110" to "value 80". > Save file. > Call OM skeptic. > Gloat. > > Warren said: > > "I've always had people complain that they got a lot of static when > they called me - I thought I had the buzz problem in fact. I just > spent the time to figure out how to use alsamixer to tweak things, and > if I set control.5 (Mono Playback Volume) to 83 from above 100 like > I've seen in other gsmhandset.state files (ranging from 100 to 110 > seems normal), I get a perfectly clear signal on the other end." Another unconfirmed taletelling about Buzzfix by ALSA settings. Don't you think we checked this prior to coming up with a hw-rework after months and months of wrestling with this issue? /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Stylus replacement button cells
Am Mi 3. Juni 2009 schrieb Joachim Ott: > The original cells are labeled GP192, searching the web I found > equivalent cells labeled LR41 AG3. But when I put 4 of them into the > stylus, the laser beam was very weak and became weaker very fast. Is > this cell type not suitable for the stylus? > > I bought this button cells in a set, 6 different types with 6 cells > each for just € 3.00, and I tried 3 cells of type LR754 AG5, they work > great and the laser beam is as if the stylus was new. > > Should I put this to the FAQ, and if yes, to which section? Hardware? > Misc? A new section Accessoires? Probably your blister pack purchase was aged battery cells (there's a reason those are sold for even 1€ now and then). There's no inherent incompatibility there. Please don't spam wiki with a single random observation. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Bounty for Navit delopment - Free freerunner - anyone?
Yorick Moko writes: > I suggest you all try the new navit > (http://download.navit-project.org/navit/openmoko/svn/navit-svn-2308_armv4t.opk) > it has a few improvements which MAKE IT USABLE WITH OSM (seems like it > was already usable with map&guide reiseplanner): > *added a 20 MB cache for the FR > *there was a bug until a few days ago which made the navigation to > recalculate at every update (mostly with OSM) Which commit fixes this bug? I'd like to benchmark it. I looked at the svn log but could only find that a new option for specifying cache size was added. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Bounty for Navit delopment - Free freerunner - anyone?
Hiya, is there any .deb package for h1 etc? Thanx Chris READY. █ 2009/6/8 Yorick Moko > I suggest you all try the new navit > ( > http://download.navit-project.org/navit/openmoko/svn/navit-svn-2308_armv4t.opk > ) > it has a few improvements which MAKE IT USABLE WITH OSM (seems like it > was already usable with map&guide reiseplanner): > *added a 20 MB cache for the FR > *there was a bug until a few days ago which made the navigation to > recalculate at every update (mostly with OSM) > > time to calculate route is now acceptable and re-calculating also! > > > > On Wed, May 27, 2009 at 4:41 PM, Tilman Baumann > wrote: > > Hello navit community. > > > > This idea was brought up at the openmoko mailinglists. > > I just wanted to ask you guys if this makes sense to you before we > proceed. > > > > So far this is only a brain fart of me, but if it is worthwhile I would > > try to push this in the openmoko community. > > > > Would it help if the openmoko community sponsors a freerunner to someone > > who can optimise navit for this device? > > Navit is by far the most promising and most important app for openmoko, > > but unfortunately it is very slow and not perfectly prepared to the whole > > situations. > > For example I believe it still uses the gpsd emulation instead of the > > gypsy api and so on... > > > > The whole thread is there (Best graphics performance?) > > http://lists.openmoko.org/pipermail/support/2009-May/thread.html#5440 > > > > > > PS: Please kepp both lists in CC ;-) > > > > Tilman Baumann wrote: > >> > >> arne anka wrote: > Don't ask me what to do, I'm not a computer scientist. But I'm sure it > would be possible. > >>> > >>> > >>> well, maybe we all should chip in and give the navit author a > >>> freerunner, > >>> to spur his motivation :-) > >> > >> If that is the fix, count me in as a supporter. > >> A FR optimised build would be really great. Not just from performance > >> prospective, but also the right default config for example. > >> > >> Maybe we canuse one of these services that allow you to set bounties for > >> opensource developments... > >> > >> -- > >> MFG > >> Tilman Baumann > >> > >> > >> ___ > >> support mailing list > >> support@lists.openmoko.org > >> https://lists.openmoko.org/mailman/listinfo/support > >> > > > > > > -- > > MFG > > Tilman Baumann > > > > > > ___ > > support mailing list > > support@lists.openmoko.org > > https://lists.openmoko.org/mailman/listinfo/support > > > > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support > ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Bounty for Navit delopment - Free freerunner - anyone?
I suggest you all try the new navit (http://download.navit-project.org/navit/openmoko/svn/navit-svn-2308_armv4t.opk) it has a few improvements which MAKE IT USABLE WITH OSM (seems like it was already usable with map&guide reiseplanner): *added a 20 MB cache for the FR *there was a bug until a few days ago which made the navigation to recalculate at every update (mostly with OSM) time to calculate route is now acceptable and re-calculating also! On Wed, May 27, 2009 at 4:41 PM, Tilman Baumann wrote: > Hello navit community. > > This idea was brought up at the openmoko mailinglists. > I just wanted to ask you guys if this makes sense to you before we proceed. > > So far this is only a brain fart of me, but if it is worthwhile I would > try to push this in the openmoko community. > > Would it help if the openmoko community sponsors a freerunner to someone > who can optimise navit for this device? > Navit is by far the most promising and most important app for openmoko, > but unfortunately it is very slow and not perfectly prepared to the whole > situations. > For example I believe it still uses the gpsd emulation instead of the > gypsy api and so on... > > The whole thread is there (Best graphics performance?) > http://lists.openmoko.org/pipermail/support/2009-May/thread.html#5440 > > > PS: Please kepp both lists in CC ;-) > > Tilman Baumann wrote: >> >> arne anka wrote: Don't ask me what to do, I'm not a computer scientist. But I'm sure it would be possible. >>> >>> >>> well, maybe we all should chip in and give the navit author a >>> freerunner, >>> to spur his motivation :-) >> >> If that is the fix, count me in as a supporter. >> A FR optimised build would be really great. Not just from performance >> prospective, but also the right default config for example. >> >> Maybe we canuse one of these services that allow you to set bounties for >> opensource developments... >> >> -- >> MFG >> Tilman Baumann >> >> >> ___ >> support mailing list >> support@lists.openmoko.org >> https://lists.openmoko.org/mailman/listinfo/support >> > > > -- > MFG > Tilman Baumann > > > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support > ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Om2009] PIN & PUK
On Monday 08 June 2009, David Fokkema wrote: > On Mon, 2009-06-08 at 12:15 +0300, Risto H. Kurppa wrote: > > On Mon, Jun 8, 2009 at 11:36 AM, David Fokkema wrote: > > > Hi list, > > > > > > Getting a bit too confident, I decided to change the PIN (default ) > > > of my SIM. > > > > > > 1. Paroli doesn't require you to re-enter the PIN, to make sure you > > > made no typo's. > > > > > > 2. Paroli doesn't give feedback on incorrect old PIN values, so you > > > don't really know for sure the PIN was actually changed. > > > > > > 3. On startup, unlocking the phone with your PIN is not very verbose. > > > An incorrect PIN results in another 'enter your PIN' screen, but > > > nothing like 'PIN incorrect, only 2 tries left'. > > > > > > 4. When the SIM is blocked (incorrect PIN) nothing shows in Paroli. It > > > doesn't tell you that the SIM is blocked and that you now need to enter > > > your PUK code. Having already tried a few times, I asked a colleague > > > for his unlocked phone to really make sure I wouldn't block the SIM by > > > entering incorrect PUK codes. > > > > > > So, does anyone dare reproducing this, ;-) ? > > > > Thank you David for sharing your experience! I don't think we'll soon > > find anyone ready to test this (maybe with old SIM cards..). Could you > > please report all this to http://www.paroli-project.org/trac so it > > will not get lost in the mail archives. I think this is something > > quite important to be fixed.. > > I might try a few times. Apparently, as long as you're not entering an > incorrect PUK code ten times, all is well. Of course, an unlocked phone > nearby is necessary to the whole procedure. Why? You can just use mdbus to enter the PUK and set the PIN: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.SIM.html;hb=HEAD#Unlock ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Om2009] PIN & PUK
On Mon, 2009-06-08 at 12:15 +0300, Risto H. Kurppa wrote: > On Mon, Jun 8, 2009 at 11:36 AM, David Fokkema wrote: > > Hi list, > > > > Getting a bit too confident, I decided to change the PIN (default ) > > of my SIM. > > > > 1. Paroli doesn't require you to re-enter the PIN, to make sure you made > > no typo's. > > > > 2. Paroli doesn't give feedback on incorrect old PIN values, so you > > don't really know for sure the PIN was actually changed. > > > > 3. On startup, unlocking the phone with your PIN is not very verbose. An > > incorrect PIN results in another 'enter your PIN' screen, but nothing > > like 'PIN incorrect, only 2 tries left'. > > > > 4. When the SIM is blocked (incorrect PIN) nothing shows in Paroli. It > > doesn't tell you that the SIM is blocked and that you now need to enter > > your PUK code. Having already tried a few times, I asked a colleague for > > his unlocked phone to really make sure I wouldn't block the SIM by > > entering incorrect PUK codes. > > > > So, does anyone dare reproducing this, ;-) ? > > Thank you David for sharing your experience! I don't think we'll soon > find anyone ready to test this (maybe with old SIM cards..). Could you > please report all this to http://www.paroli-project.org/trac so it > will not get lost in the mail archives. I think this is something > quite important to be fixed.. I might try a few times. Apparently, as long as you're not entering an incorrect PUK code ten times, all is well. Of course, an unlocked phone nearby is necessary to the whole procedure. I added this to trac: http://www.paroli-project.org/trac/ticket/176 Regards, David ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
initramfs (was: Re: Om2009 testing release 4)
Hi Kevin, Kevin Day wrote (ao): > The initramfs must be pregenerated. > The command to create the initramfs is: > find . | cpio --quiet -H newc -o | gzip -9 -n > /usr/src/boot-initrd.cpio.gz > > Place the initramfs into the kernel source tree, and then something > like this config option should be used: > CONFIG_INITRAMFS_SOURCE="boot-initrd.cpio.gz" There is no need to create the initramfs. You can just have this in your kernel config: CONFIG_INITRAMFS_SOURCE="/home/user/initramfs" The /home/user/initramfs directory gets included in the initramfs during kernel build. With kind regards, Sander -- Humilis IT Services and Solutions http://www.humilis.net ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Om2009] PIN & PUK
On Mon, Jun 8, 2009 at 11:36 AM, David Fokkema wrote: > Hi list, > > Getting a bit too confident, I decided to change the PIN (default ) > of my SIM. > > 1. Paroli doesn't require you to re-enter the PIN, to make sure you made > no typo's. > > 2. Paroli doesn't give feedback on incorrect old PIN values, so you > don't really know for sure the PIN was actually changed. > > 3. On startup, unlocking the phone with your PIN is not very verbose. An > incorrect PIN results in another 'enter your PIN' screen, but nothing > like 'PIN incorrect, only 2 tries left'. > > 4. When the SIM is blocked (incorrect PIN) nothing shows in Paroli. It > doesn't tell you that the SIM is blocked and that you now need to enter > your PUK code. Having already tried a few times, I asked a colleague for > his unlocked phone to really make sure I wouldn't block the SIM by > entering incorrect PUK codes. > > So, does anyone dare reproducing this, ;-) ? Thank you David for sharing your experience! I don't think we'll soon find anyone ready to test this (maybe with old SIM cards..). Could you please report all this to http://www.paroli-project.org/trac so it will not get lost in the mail archives. I think this is something quite important to be fixed.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[Om2009] PIN & PUK
Hi list, Getting a bit too confident, I decided to change the PIN (default ) of my SIM. 1. Paroli doesn't require you to re-enter the PIN, to make sure you made no typo's. 2. Paroli doesn't give feedback on incorrect old PIN values, so you don't really know for sure the PIN was actually changed. 3. On startup, unlocking the phone with your PIN is not very verbose. An incorrect PIN results in another 'enter your PIN' screen, but nothing like 'PIN incorrect, only 2 tries left'. 4. When the SIM is blocked (incorrect PIN) nothing shows in Paroli. It doesn't tell you that the SIM is blocked and that you now need to enter your PUK code. Having already tried a few times, I asked a colleague for his unlocked phone to really make sure I wouldn't block the SIM by entering incorrect PUK codes. So, does anyone dare reproducing this, ;-) ? Thanks, David ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
