test123
:) -- Joachim Steiger Openmoko.org Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test123 / ml should be working again
yay :) please also read http://admin-trac.openmoko.org/trac/blog/lists%20are%20back -- Joachim Steiger Openmoko.org Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Beagle Hybrid
Dr. H. Nikolaus Schaller wrote: The problem is not technology or DIY capabilities, but cost. What we want to have is a nice case achievable for everybody, not only the enthusiast who wants to spend time and money for experimenting with DIY hardware or commercial FDM. So the question is how much does a SW developer want to pay to get HW + Case? Let's say 50 EUR per plastic case. FDM is at least 200 EUR (that is what we got as a quotation from the rapid-prototyping shops for a simple part and not the whole case). Or 700 EUR for a Cupcake. Or 5k for a protomold made thing. Or 10-20k EUR for a 3D printer. A full freerunner case consists of 6 plastic parts (incl. 2 buttons). The other side is expectation of quality/robustness. I have been told by experts who own a RepRap/CupCake that the precision is not good enough to reproduce a Freerunner case (wall thickness 0.5mm). true also its much too complex. i tried importing the 3d models into quite a lot of the free and or open 3d and machining tools, but the shear amount of detail seems to be a problem there. also there are limitations of what you can do with which each production-method: * e.g. for reprap-alikes, all overhangs 45deg need support structures. * milling in 3axis means you can only 'mill from e.g. above'.. to turn it to the side you already need a trick/mechanical help to mount it sideways, without loosing alignment, or a 4 or 5 axis mill (i don't think there is any free toolpath-gen for that yet) * laser cutting heavily depend on used materials and is basically '2d only' for the affordable machines (50keuro) this means designs consist out of 2d shapes. one 'stacks' afterwards or uses creative mounting methods to hold the shaped sheets together, like e.g. on the cupcake-cnc (makerbot) So if we find a method that allows to make 10 units from a budget of 500 EUR or 100 units from a total budget of 5000 EUR I am happy! tricky. we got a cnc mill (3axis, 800W spindle) as well as a simple lasercutter (50W) here in berlin in our hackspace. there is also a rep-rap-like printing head for thermoplastics, but thats not completely ready yet. the much bigger problem than machining itself, is getting a the design done. after that one needs to get the toolpath generated. special sw as well as expertise in that line of work is what it makes so expensive. milling itself isn't a very cheap form to 'produce something'. but still, its not the time the machine is running but the worktime of the human which makes it expensive. if somebody has too much free time and wanna try this, check out http://camgeeks.de/ and visit us there ;) free and/or open tools for mechanical engineering are still not quite 'done' (yet), but there is progress. Still they work well when you learned about their limits (or even extend them). ps: what about finding some 'ready made universal case' like from teko or boppla and do some cnc coutouts for the sockets? thats much easier. -- roh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git.openmoko.org / GTA02 kernel sources?
Dr. H. Nikolaus Schaller wrote: Am 22.04.2010 um 08:09 schrieb Martin Jansa: On Thu, Apr 22, 2010 at 07:59:27AM +0200, Dr. H. Nikolaus Schaller wrote: I tried to fetch the latest kernel sources from http://git.openmoko.org/?p=kernel.git;a=summary for learning something, but it appears that the server has some failure: iMac:tmp hns$ git clone git://git.openmoko.org/git/kernel.git linux-2.6 Initialized empty Git repository in /private/tmp/linux-2.6/.git/ remote: fatal: Out of memory, realloc failed remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed iMac:tmp hns$ should be fixed now the repo got quite big so we hit memory as well as diskspace quotas at the same time ;) i just cloned the kernel repo and it went through fine at 800kbyte/sec kind regards -- Joachim Steiger Openmoko.org Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Abwesenheitsnotiz community Digest, Vol 110, Issue 70 erfolgreich auf Virenfreiheit geprueft
Michael 'Mickey' Lauer wrote: Please unsubscribe this guy. Oguz, if you are on a mailing list, you better change your subscription options before going on vacation. disabled his mail delivery in mailman. he can reenable it himself easily via the webinterface. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dfu_upload error -84 when trying to backup images
Russell Sears wrote: [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 09:36:43PM +0530, Vikas Saurabh wrote: I dont think this is related to the architecture. I had faced similar issue on core duo (i had put a comment on the wiki for the same). Btw, i didnt have to flash the back up image so i dont know if it actually worked out correctly. So does flashing new images work? Is it just uploading that's broken? Yes, and yes. -Rusty please refer to these tickets: https://docs.openmoko.org/trac/tags?q='dfu' -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: More posts to Planet Openmoko
Joachim Breitner wrote: Am Montag, den 25.08.2008, 10:35 +0300 schrieb Risto H. Kurppa: [...] As far as I know, it's meant for community to share their blog posts about openmoko, neo, freerunner. Maybe even qtopia and debian on freerunner. Too bad that there are not that many posts: I know that people are blogging about freerunner and software for it so why not add your feed to the planet and get more readers. I have no idea how to do it but I'm sure someone will let us know soon.. quite simple. make sure you have a tag/category in your blog and that the 'relevant to openmoko in some way' articles are tagged with that. then just open a ticket at http://admin-trac.openmoko.org and tell us the url of your xml-feed (for that category!) and we will add it to the configfile of planet.openmoko.org you can see the used config for examples here: http://admin-trac.openmoko.org/trac/browser/trunk/planet.openmoko.org/home_planet_planet_openmoko.org/config.ini such a project planet can be used in two ways: For all posts, even non-openmoko or non-technical, from members of the community, for the community spirit, or only for on-topic posts. planet.debian.org for example has the former policy. And there ought to be a language policy (english only, or anything) the current policy is: add a feed of a category, not the whole blog. that way everybody can decide if he/she thinks its related to om or not. about languages, currently not., if we have enough posts in multiple languages we can still think about splitting that again. Anyways, I’d be interested to join. just taken a look at your blog.. nice.. please add a category like Openmoko, tag your articles in and we are good to go. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tester please?
Joel Newkirk wrote: [...] When all is said and done, I suspect the better solution will be a standalone single-binary dns cache, but I looked at dnsmasq and decided to stick with what I was familiar with to start, and it turned out to be less resource-hungry than I'd feared so I may just stick with it if I can pare it down and polish it a bit further. nice work, i like djbdns and dnscache and use them myself a lot (on servers, routers etc) i hope somebody can add a nice recipe to oe/om-oe including some fhs compliance patches etc.. first i wanted to ask how you plan to solve the 'djbs licensing madness'-issue, but i see he placed all that stuff under public domain last december.. nice surprise ;) with djbdns you may not notice this for years, i still have installations with 4 year old binaries of it running kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
qrazi wrote: The test referred to are with the nettop version of the Atom, the Atom N230. That CPU is paired with a standard 945GC chipset, which consumes between 15 and 20 Watt. Hence the high power draws in those reviews. Intel also has the Z series, which include speedstep for even lower powerconsumption for the CPU itself, but they are also to be used with the Intel US15 mobile chipset. For a 1.6 GHz Z530 Atom, with the US15 chipset, a maximum draw of 5 Watt is reported. That is way lower then the combination that PC Perspective has tested. Although probably still not low enough for use in a phone. That however might come in future generations, since Intels plans are to include more, if not all, of the chipset functions into the cpu itself. thanks for summarizing it so well thats also my conclusion: x86 is not ready yet for really mobile use. we should evaluate it more when they can punch the '1W when in use' limit. for comparison: our cpu currently uses 90mA when in use. add the chipset, the lcm and interfaces (don't forget wifi, bt and gsm) and then see battery sizes and capacity - for a reasonable standby AND talk time we need to not peak far beyond 1W when in use and be far beyond that all the rest of the time. also things like high-clocked ram (ddr compared to simple sdram) or internal usb connections are energy suckers (thats why sdram with 200mhz and things like sdio/spi/i2c/cmoslevel-serial is preferred to usb and ddr ram. its always getting things into a tricky balance to have something usable at the end (and not a 'see how fluid it moves the icon' - 'oh.. batter is empty' - showcase ;) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What will be in GTA03?
Pritam, Ghanghas (IE10) wrote: Hi All I had put this wish list once but no one considered that I guess. Is it that stupid? At least give your review guys. OMAP3530 http://focus.ti.com/docs/prod/folders/print/omap3530.html I see lot of benefits from this shift Camera interface Two USB one of them OTG On chip 2D/3D accelerator -- I didn't get much info about glamo 3362 still TI looks better Host of other goodies that you can look in the page And I don't see drivers to be a very big problem, seems like we will get another community working simultaneously http://beagleboard.org/ and TI is in mood of cooperating in this venture. nice chip.. basically.. but see this thread: http://www.gp32x.com/board/index.php?showtopic=42144 and try to find any specs or documentation about the included powerVR SGX530... have fun... its closed. thus also pandora will probably not have open drivers. search for statements about that. i haven't found anything that states about how open that machine will be at all. in short: the whole 2d/3d accel in that chip would currently be useless for us. openmoko took opensource serious till now, pushing boundaries further where we could. we want debuggable architectures. means no binary drivers on the app cpu for anything for sure. not in userspace, and for sure not in the kernel. this was nagging many people on gta01 with gps before we got rid of that with gta02. hopefully we will never make that error again. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Andy Green wrote: [...] Hey don't lose hope. There are two issues. First is just some big cards are too slow to respond at default 16MHz clock with Glamo 16-bit clock count timeout counter. See this https://docs.openmoko.org/trac/ticket/1743 Suspend / resume (partition overwrite is only a suspend / resume issue) has been fundamentally broken on GTA02 since before I got here last December, it didn't work at all until a series of deathmatches with it. ~ The biggest deathmatch of all to clean and fix it is going on at the minute on 2.6.26 branch here and it exposed the biggest underlying problem for us which is Glamo behaviours. Assuming I kill it before it kills me, we will have a far less racy and more complete suspend and resume ordering situation then. yay! Other projects using Linux also have that problem of partition overwrite on resume, but I suspect resume ordering and racing is behind their problems too. When we clear that in the 2.6.26 branch we stand a chance to synthesize random or moving delays in resume action and try to flush out where it comes from. i played with it a bit and came to the conclusion that it eats exactly 1024byte from the beginning of the 'physical' blockdevice. atleast when i backup these to nand, write them back via dd after loosing it and do a ioctl via fdisk /dev/mmcblk0 - press w to trigger the block layer rereading the device i am fine. sounds weird.. is a buffer getting nulled on suspend, and gets written back to disk even if it shouldnt? -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems when upgrading the kernel with opkg / HELLO PLEASE NUKE BROKEN KERNEL PACKAGES
Andy Green wrote: Somebody in the thread at some point said: | Today's kernel package appears to be busted. As someone else pointed | out, it is only 1104 bytes long, which is such significantly better | compression than normal we can only be suspicious. | | Maybe someone can nuke this package... | | http://buildhost.openmoko.org/daily-feed/om-gta02/kernel-image-2.6.24_2.6.24+git25+8533927964761f4e2078ccd8607b90f5acc60b93-r0_om-gta02.ipk removed. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new list for wiki (and other documentation) maintainers, and anyone interested in helping them
ian douglas wrote: Michael, Can you alter the mailing list so the list's address is set as the default Reply-To value like the community list? please not. Simply hitting Reply (instead of Reply-to-All) seems to send replies to the authors of the posts. thats how it needs to be. thats what your reply-to-all button is for. Might as well keep things uniform in that regard. it mostly is: all lists besides community@, which is the only list which is _misconfigured on purpose_ (due to the much higher ratio of 'beginners'. and no, i will not start this senseless discussion again. there is a reason you do not get a direct mail as well now: reply to breaks that i have 3 nice different reply buttons here on my mailclient: reply, reply list, reply all. so if you really want that i do not read your mails on that lists anymore, please continue with that nonsense. read up http://www.unicom.com/pw/reply-to-harmful.html if you haven't. please especially take care to read the sections 'It Makes Things Break' and 'Coddling the Brain-Dead, Penalizing the Conscientious' the result is _more_ work for people who try to help, not less. (need to copy paste around mailaddresses manual). but read yourself... perfectly good example this list.. just search the archives... we also have quite some occurrences of mails which got sent to the list by accident, because of this breakage. but i will stop now. read yourself. its really nicely described. ps: ever asked yourself why so much crud which seems just commentary from user to user ends up on the list? -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM Antenna Connector part of Closed System?
Scott wrote: I know its the same connector as on a Razr or Motorola C168i, so I think its the same that Motorola uses. could be, just checked with a razrV3i, and on visual inspection it looks similar. but just to make sure we all work on a basis of real informations: i've taken the liberty to look that socket up, and when i am not totally mistaken the socket in question (GSM, behind that deep hole) is a Murata MM8430-2610 its a rf (test?)socket with switch and rated about 500cycles. can be used up to 6ghz it seems googling after the 2 strings above brings up diverse supposedly existing plugs which could be used to attach a external antenna. sorry, no clue about a supplier. but let us know if you find one who likes to sell small amounts of that stuff directly to customers. ;) kind regards. ps: the socket on our wifi module looks quite like the same, but i couldn't find a bom right away. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
Michele Renda wrote: Thank you Tony. You did a very great work and you putted me to love more this phone. Only one question: which type of capacitor I have to put? I see it is not a electrolitic one :) little too small for that (electrolytic) ;) 0402 is the package format. i guess all caps in that size are ceramic ones. i used a cap from a dead gta01 board which had a job near a rtc crystal in his earlier life. since the only new job is eating the rf which doesn't belong there, it seems uncritical which type it is as long as the value is somewhat in range. Here is the fix: http://www.openmoko.org/wiki/Image:Gta02_gps_10pf_rework_sop.pdf This fix could give almost same performance with SD card out of case. But this work still not suggest do by yourself, also, this fix need proper size capacitor (10 pf with 0402 package), and some solder technique. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery Lifetime
arne anka wrote: I'm thinking of getting out of this mailing list because it fills up my inbox each day. Can someone please create a forum instead. I've been part of a lot of mailing lists and this one is too much. please, check the archives and the wiki -- there are fora already. else you could follow the list through gmane or markmail (i think), which both provide a forum-like gui. please also test http://lists.openmoko.org/nabble.html its a first test. it allows browsing and searching also it allows users which have an account at nabble and are subscribed to the list also to post from there (haven't tested that yet) this is not an extra forum but an additional view onto 4 of the mailinglists: - openmoko-community - support - devel - hardware if you like it, please speak up. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem in logging in freerunner through ssh
for people who often reflash and thus have new host keys on their mokos i can share this ~/.ssh/config snippet: Host moko HostName 192.168.0.202 StrictHostKeyChecking no UserKnownHostsFile /dev/null User root the result is that one can just 'ssh moko' press return and be done (logged in) every time. but beware: it ignores changing host keys completely then. (one could tap you usb cable!!1!) ;) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wishlist Re: Can OM's wiki be used offline?
Yaroslav Halchenko wrote: Dear Syadmins, look below I, like others, agree that a mobile version of the OM wiki would be invaluable. I can't imagine the strain on the wiki server from everyone suddenly doing recursive wget launches ;o) well... google does that all the time (indexing) ;) exactly my point. unfortunately mokopedia * was wikipedia DB dumps oriented (thus cannot be applied to OM wiki) * is pretty much dead and ad-hoc from what I see ? sorry, i would say josch would disagree ;) see http://mokopedia.mister-muffin.de/ wget, wwwoffle etc spider downloaders are not an option even if someone would craft very careful set of options to don't download wiki diffs,logs,etc. I just installed wwwoffle to see what is the beast... in few minutes it started caching wiki.openmoko.org, I said cool, but then I saw that it sceduled massive amount of diffs of wiki pages (which sure thing are available) -- so I had to kill it. yeah, would like to avoid that too ;) not that we couln't still take mor e load, but somehow i like efficiency ;) what i do not see is a 'standardized' format in which wikis like this mediawiki can be dumped, diffed and synced. the plugins into mediawiki seem stale, old and not applying on recent versions of mediawiki. we use a quite recent 1.12 some advice from people deeper into mediawiki than us admins would be nice. I guess we should direct this question to the admin of OM wiki... who take care about the website according to http://admin-trac.openmoko.org/trac where I was trying to comment on https://admin-trac.openmoko.org/trac/ticket/1435 which is pretty much what we need for offline support but got ,-- | Oops⦠| Trac detected an internal error: | | OperationalError: database is locked | | There was an internal error in Trac. It is recommended that you inform your local Trac administrator and give him all the information he needs to reproduce the issue. | | The action that triggered the error was: | | POST: /ticket/1435 `--- thus I am informing them in this email that I was trying to comment on that 1435 with ,-- | I would love to have dump service available. | Recently I inquired community mailing list on either there is a | reasonable way to get offline copy of wiki | http://lists.openmoko.org/pipermail/community/2008-July/021713.html | and sure thing first advices were 'to use wget' ;-) so, having official | dumps (in a digestable format by some other tools, or even in pure DB, | thus requiring LAMP setup) and may be incremental bin diffs to them (for | a week or two) would help to avoid waste of bandwidth if someone needs | an offline copy of wiki, which is pretty much the only source of | information on howto/wtf/rtfm/anything about GTA phones. | `--- please try again. this should not happen. couldnt find a error in the logs. weird tho. if it doesn't work, afain, write me a direct mail and we debug it off list kind regards -- Joachim Steiger Openmoko Central Services ___ 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: freerunner unable to work with 3G SIMCards?
steve wrote: Michael and Brenda. I want a Page on the wiki showing which carriers have issues, a table by country by carrier. hi steve, michael, brenda, community. that does not make real sense. the issues we are seeing with some sim-cards are not carrier-related, but related to which specific model of sim-card they bought. currently it seems that old gemplus sim-cards have this issue, but we need more people with and without problems to submit pictures of the contact-side if the sim. the only universal way we currently have to identify which manufacturer and model the sim really is, is to have a scan/sharp photo. the numbers on it are not unified and thus cannot be universally used to look up which type it is. also carriers tend to have multiple types of sim in use over the years and also switch manufacturers from time to time. see the attached pictures on ticket 666 http://docs.openmoko.org/trac/ticket/666 at the moment i am not yet sure if we have a electrical or mechanical problem, but the current state from my point of view is: 'some type of gemplus simcards (the 2 different types with round edges/ contact plates) give trouble/do not work. This is vital for solving those cases where folks have problems and for advising people prior to purchase. indeed. also this needs more samples of which sims work and not work to finally know whats going on and what to tell people to do as workaround. so please do a shot like this: http://docs.openmoko.org/trac/attachment/ticket/666/sim1.jpg sharp, contact side. label the file as 'sim working' or 'sim notworking' and attach it to this ticket in the wiki. also would be nice to have some comment about which carrier, and when it was given out, if you think its a '3g sim' and, if you want, the numbers on it. but thats 'cream on top', not essential, since this is a carrier-independant problem it seems. kind regards. ps: because it seems a often asked question: the numbers of the sim are not directly 'secret' or need to be kept confidential. one cannot clone or locate your sim/phone with knowledge of these. only the carrier who gave the sim out could identify or duplicate the sim, and would not need the numbers on the original for that because that information which one could look up is in their databases already. so no harm done by having them in a photo. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Internal Connections
Charles Pax wrote: Is there any way to commmunicate with the Freerunner through an internal connection (USB or serial, not I2C)? This would be useful in creating a bar code/RFID tag reader into the back cover. If not, is something like this planned for a future version? planned not afaik. too many different standards yet incompatible with each other... (eg. 15.56MHz or rather 125kHz?) but of course you could add one yourself. we have added i2c, spi and a the debug serial not only on the debug connector, but also on the golden testpads surrounding it on gta02, so access via soldering or flatcable is easy and possible. only VCC is not. (because there were no free ldo with enough spare current or so) for the pinout see this picture: http://wiki.openmoko.org/images/a/a4/Gta02a5_pcba_ps.JPG the print on the pcb in the middle shows the arrangement of the golden pads around the debug connector (right lower corner) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freerunner unable to work with 3G SIMCards?
Chaosspawn23 wrote: [unlurk] Having the same problem with my O2 SIMCard, I too would like to offer my help in tracking down the problem. Just tell me if I can do something to help. [/unlurk] hey there i've done a few quick tests with a borrowed O2 3G-sim and ran into the same problem. BUT since this sim is from a gsm-geek we quickly tested a few things: this sim had the pin set to 'off' (not asking, just do register) and the FSO milestone1 which i used for testing still was asking me for a pin. obviously the previously used pin was not accepted. then we put the sim into another phone, set the pin from 'off' to '' and swapped it back to the FR. after booting FSO asked for a pin again, and this time it took the and registered fine. a quick call worked fine from that point on. so: if your O2 3g sim does not want your (supposedly correct) pin, check if the pin is really needed with a second phone, and if not, set it to or so. if this works for more people than just me, we might just have found a workaround. ps: i have photos of the 'tricky' O2 sim, so if youre unsure or find yours does the same, we should be able to identify the manufacturer by a nice high-res shot of the 'chip' (the layout of the pads is somehow 'characteristic') kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freerunner unable to work with 3G SIMCards?
thanks for testing that, even if it didnt help. after reading shawn lin's testreport i believe we really have a problem with the 1.8V sim cards then. too bad the one i tested has no voltage printed on (some sims have, this sadly doesnt). will try to find out next time i get near that sim. regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Webshop Reopen NOW!!!
Michael T. Dean wrote: On 07/03/2008 02:55 PM, Michael T. Dean wrote: I'm getting a Gateway Error 500 before I even get a chance to enter my credit card info--i.e. when it says, Forwarding you to Hi_Trust... Full text of the message is: Error from the Hi Trust gateway: TrustLink Server is closed. Or Merchant Server IP is not consistent with TrustLink Server setting. Seems this one has something to do with my NAT'ing firewall/router. When I tried from a computer with a direct connection to the Internet, it went through without a problem. I tried all combinations of Firefox 2, Internet Explorer, and Firefox 3 and the only difference in the systems was the network connection (and the fact that the one that worked--with the direct connection--was running Windows, but I'm pretty sure that's not the issue). i can assure you that this is not the case. in all cases we had this error it was the sending bank blocking the transaction till the card was activated for international billing or some similar automatic protection mechanism. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Webshop Reopen NOW!!!
Michael T. Dean wrote: Which could /not/ happen before I've been given a chance to type in my credit card information--i.e. before they know which card/bank to ask for authorization. sorry i doubted you. just sounded like another thing we were seeing. BTW, this is 100% repeatable (even still) on any computer on my network. do you have any special nat features, a transparent proxy in use? ah.. and is JavaScript enabled? lets track it down. regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: motorola usb-3.5-headset: compatibility?
arne anka wrote: hi, the other day i saw from motorola an adaptor changing a mini-usb into a 3.5(?)mm headset jack. http://www.amazon.com/Motorola-3-5mm-Stereo-Audio-Converter/dp/B001A1IKFK/ref=pd_sim_cps_1_img/002-7641246-5084844 does anybody know whether it works with motorola phones only? afaik yes. means it only works with motorola devices. motorola has 8-13 different 'functions' on the 5pin mini-usb-b connector, including mono headset, stereo headphones out, high and low voltage programming mode, usb-masstorage, usb-acm, serial debugport and some others. but thats only possible since they build them in such massive volumes that the high initial cost for the custom-asic which contains pmu+codec+usb-py+serial+mux makes any sense at all. besides that, i would like to charge or speak ip to my phone while its playing music, so i do not really favor too much muxing anywhere. 4-ring 3.5mm jack + usb for charging as well as data gives one the biggest number of reasonable use-case combinations while still keeping it simple. after all we do not want bags full of adapters anymore, just because everybody uses a different plug for the same thing. if not, it easily could solve the issues with audio jack of the freerunner (whose impact i still fail to understand). sadly not. see above. regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community Initiative GTK
Marcus Bauer wrote: Hello, I'm wondering if there is any interest in maintaining the GTK software stack? would be nice. e.g. take the last gtk-based ui apps, rip out all libgsmd and neod dependencies and start communicating with the new middleware from FSO. this would basically solve all 'call stability' problems from gsmd times and give you the same, maintained middleware which in the future hopefully all openmoko devices will use. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: rationale for ASU (and change from GTK to Qt)
Esben Stien wrote: Ron K. Jeffries [EMAIL PROTECTED] writes: the rationale for the decision to switch from the original GTK based OpenMoko its not really switching from gtk to something. gtk is still included and supported. there is 'just' no app which uses it in some of the images by default. the real change was from everything gtk to 'a mixture of libs which get used for what they're good at e-foo for custom-ui and qt-foo because its gsm-middleware works for now till the FSO is 'complete' and 'some people like it' (qt).. also some people 'like gtk'. linux on the desktop would never have been as big as it is now when there would not have been gtk AND qt. gnome AND kde. its not a total friendship everywhere, but also not a enmity. its something which makes both parties want the same thing, but try different ways. who follows which way doesnt matter, aslong as both want the same thing: write some app. in the end its an evolutionary process to better, free software (atleast on the idealistic side ;). so: gtk is still there and fully supported in openmoko. just install some app like tango-gps. its gtk and should 'just work' There will be a fork here at one point. There's a good bunch of us who wants a standard GTK+ environment as the main guis' for the phone. There's even some that don't want any QT on the phone, at all;). i can understand that. but there is no need to fork. just submit patches. we do not bite. on the contrary. I just hope that the existing applications has been properly engineered, separating the core from the UI (MVC, three tier, PCMEF) so that it's just a matter of speaking a common protocol. me too ;) that would revamping them to fso middleware easier. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OEM market,any thoughts about that??
David Samblas Martinez wrote: I'm curious about If when released, if a volunteer makes a detailed photoguide of where/what/for what/how about the hardware. Can count with openmoko help? that depends on which part of the hw. most of the generic soc is kinda 'public documented' anyways. the gsm modem and the gps in case of gta01 for example will need to stay blackboxes for what i know. It's recommended to no distribute those kinds of docs? or better do it under openmoko supervision? i do not really know what you mean. our policy for hw-informations needs to differ depending on the questions you're asking (due to 3rd parties). so it was much easier and less time consuming to document whats obviously of interest and let the rest open for 'on request'. if you want to do a exact and detailed photostory, draw stuff and do proper documentation and so on, be sure nobody will stop you aslong as you try to keep gps and gsm a 'blackbox'. in the end people without a high-end-lab can't do much with the pure hw of a 'well-hung' gsm chipset. in case you're unsure if one should publish a specific information, just ask. we do not bite Only to talk about it, meanwhile the freerunner arrives, ... waiter, another beer, please. just have fun. be sure we will give you a note before you trip any lines we need to keep ;) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Shipping details
Simon Matthews wrote: What courier companies/the postal service and shipping options (express versus normal etc) will you be using to ship the phones (only UPS or others as well?) ups. Will you be offering the option of having the shipments insured? Do you know how much the insurance will cost. I can't find much information on the UPS web site on insurance. dunno, but i guess they are. What payment options will you have. visa, master, jcb or so.. no amex, no paypal atleast thats what i know and whats prepared. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Trac down?
Roland Häder wrote: Hi OpenMoko team, it looks like your Trac at http://docs.openmoko.org/trac/ is down? thanks for noting. fixed. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: USB connectors on FreeRunner Hostmode
Jeremiah Flerchinger wrote: It's my understanding that the SC32442B in the FreeRunner has a host controller that can support 2 peripherals (I found a link to the manual today updated in the wiki). Is there just the 1 external connector or are there additional pins or connectors internal to the FreeRunner that can be easily used to connect a second peripheral device? its used for bluetooth. its connected via a flexible pcb and fixed on top of the soc-shielding. the flexible part the wraps around the mainpcb and connects to it from the lcm side. see http://wiki.openmoko.org/images/a/a4/Gta02a5_pcba_ps.JPG the connector labeled with 'H-BTFPC01' since usb is kinda 'point to point' you could/must add a hub to keep bt working. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yummy new CPU/GPU combo
Carsten Haitzler (The Rasterman) wrote: On Mon, 2 Jun 2008 23:12:30 -0400 Lally Singh [EMAIL PROTECTED] babbled: the day nvidia comes with open drivers for this... we can begin to take an interest :) yeah.. sounds nice.. shortly after hell has frozen over and nvidia started supporting any free and or open driver development at all ;) btw.. did you see any total power ratings anywhere? guess why they are missing... anyways... kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Question about future devices (GTA03,04)
Stroller wrote: Yeah, but you're the guys who can just slip the odd extra chip into the design without anyone else noticing. ;) don't think so ;) If questioned just tell management that Classic FM is required to soothe the kernel penguins. well.. it adds power, space and cost and complexity to the whole thing. and quite ugly rf validation and eventually even certification requirements depending on where you plan to sell it i guess ;) it was already discussed in detail last year i think. to sum it up: OM does know that _some_ people want a fm radio. same as for electronic (magnetic) compass, a rfid transceiver/nfc stuff, embedded micro-beamers, fm transmitters, dvb-t/h receivers, dab/drm receivers etc. or a camera. others again do not want some parts with a reason (price, size, usage constraints (some companies forbid entering with a cameraphone) we just need to make the best out of it for all involved parties: * om needs to build and sell hardware * the community wants to get a device which is not vaporvare and not in development forever. so we need to find a nice compromise and be careful what to add, in which configuration and for which product to please us all (the community when it comes to features and availability as well as price and size) and om in the cause to survive by building real free and open designs. not easy all the time, but i think it helps us all, if everybody knows that its 'not that easy' to add some part just like that, but hard work. to find components we can and want use, which are available and please om as well as the community due to price, availability, features and size AND open documentations or drivers is sometimes very time consuming. as for fm.. its kinda borderline for me, (personally, not that my opinion counts more than yours) since i never listen to fm radio anymore. its more important to have the 3.5 mm jack for reasonable headphones, and a solid and good quality audio electronics in front of that, for me. lets all thank joerg, that he has already taken care of that ;) kudos. regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Our new Main page of wiki
Joerg Reisenweber wrote: Am Mo 5. Mai 2008 schrieb steve: Received: from localhost ([127.0.0.1] helo=sita.openmoko.org) by sita.openmoko.org with esmtp (Exim 4.50) id 1K32Dg-0001Yg-F5; Mon, 02 Jun 2008 07:04:32 +0200 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]) by sita.openmoko.org with smtp (Exim 4.50) id 1Jt5nq-0005hh-NB for community@lists.openmoko.org; Mon, 05 May 2008 20:52:59 +0200 WOW! yahoo is great ;-) nope, we are, the mail hung in the mailman for quite a while because often nobody finds the time to log into its webui and ack through messages which landed in moderation.. e.g. not sent directly to the list, but as bcc, or with huge attachments for example (as in this case) since some public lists have quite a lot subscribers i think we should keep this limits in place there. (and rather find a more systematic process to work such stuff down. ;) -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Induced hardware issue with 01?
Lon Lentz wrote: I have an 01BV4, which I may have banged around one too many times. Just started having a problem where if I put a little pressure on the back just below the battery, the unit cuts power. I have to remove the battery for a minute or two before I can boot it back up. Just handling the phone is enough to do this. Has anyone else experienced such an issue? Just curious before I pull it apart and start looking for a broken solder joint. do you have a simcard and a transflash inserted? if not, try putting something non-conductive like a folded piece of paper, a corner of a businesscard or a real sim/flash in and test again. the simcard holder/micro-sd socket used on gta01 was known to be able to short when pressure is applied, so this is probably a good thing to avoid. regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
bugzilla migration complete, now trac
hi there just a short notice, the bugzilla is now gone and got replaced by trac. all bugs including the history got migrated see http://docs.openmoko.org/trac/report to add/modify bugs you need to log in. if you do not yet have an account, please register one. after logging in, please set your email-address and fullname by klicking on preferences in the upper right corner and filling our the fields in the 'general' tab and save changes. this is important if you want to receive email-notification of ticket changes. i also added some redirects which should help old links to bugzilla to reach the right ticket in trac. right now i think we have too many different 'components' to choose from when adding a bug, so this will get cleaned out a bit soon. please test and report bugs on this new setup via http://admin-trac.openmoko.org kind regards your admin team -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo as cellular modem?
Michael Shiloh wrote: Alexey Feldgendler wrote: On Wed, 28 May 2008 02:15:16 +0200, Matt Mets [EMAIL PROTECTED] wrote: It might also be cool to have the Freerunner act as a wireless router! Instant (slow) internet anywhere... In ad-hoc network mode only. AFAIK the WiFi chip used in the Freerunner doesn't support AP mode. Please someone correct me if I'm wrong, but I thought the WiFi chip in fact _can_ do AP mode, but that mode is not allowed in the open source driver. its a firmware. the wifi module has its own firmware and does the 802.11 handling there autonomous. that concept is called hardmac and was there earlier, e.g on the old 'orinoco silver' aka hermes pcmcia cards. that firmware can currently do client mode and ad-hoc. _in theory_ every wifi radio can do ap-mode, its just a question if you can send packets at a low-enough layer in the right format. this is controlled by firmware on the wifi module in this specific case. = ap mode would need another firmware which we do not have and not know if it exists at all from atheros to be loaded into the wifi module. so there is nothing we could do on the driver front to change that. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Available Encryption algorithms
just as a sidenote: see http://en.wikipedia.org/wiki/A5/2 as well as http://en.wikipedia.org/wiki/A5/1 and http://en.wikipedia.org/wiki/A5/3 seems one doesn't want A5/2 anyways and its deprecated, thus eventually the network doesn't allow using it anymore? just guessing.. would need to work through a pile of calypso docs for more details, and still not know whats implemented in that specific revision of the ti-libs anyhow.. but after reading that i think a5/1 and 5/3 will need to be enough till we need 3g anyhow. (when gsm gets phased out, somewhere in the future or THC is successful ;) -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Europe Distribution
Steven Le Roux wrote: What about Europe distribution ;). Let's come back to the subject :) well.. i think that was already answered somewhere in the thread in other words, but here my short version: afaik there will be 2 possibilities: - order at the openmoko us based webshop. - pay in us$ - pay the (to europe quite high but not unusual) higher shipping fee - if not in the us: pay the VAT/sales tax of the target country on recieving the package to the ups guy (usually in cash) - use a CC (currently JCB, VISA, MASTER. _no_ AMEX afaik) - order at a local distributor - pay the local currency - pay for shipping if you do not pick it up yourself - pay the regional tax/vat of your county directly with the device and shipping so the bottomline is: us customers as well as worldwide can very easily order directly at openmoko. but if you do not want to have the hassle of transatlantic shipping, different currencies etc or want local warranty, buy at a local distributor. i guess due to the shipping costs its cheaper and less hassle to order single devices directly at a distributor. also these could have different payment methods, but thats their decision. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo 1973 sales
Kosa wrote: Hi everyone, does anybody know the aproximate quantity of 1973 Neos were sold in every country? I mean, according to the article sent by Samuel [1] Germany was the country that bought more Neos, but I don't know how many did they (or you) bought. I don't even know how many of them were sold all over the world. well.. thats what openmoko internal statistics say... well.. they say in absolut numbers per country and germany was the most _shipped_ to country in europe ;) i didn't calculate back onto per-capita quotes, but it seems solid. so its an 'ACK' if thats what you wanted to know. (and nothing surprising to me, knowing the activity of the opensource community here in europe) i can't give you any more specifics, these are under nda. such stuff is up to steve. ;) -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko codebases with Linux Cross Reference (LXR)
Andy Green wrote: | currently i would rather like to put that onto the 'todo when we have a | bit more time again' list. Never, then :-) didn't say that. but we have to prioritize stuff, else we will sink that boat pretty fast by drilling to many holes without proper plugging em. ;) | also i think there are some important questions IF we do that: | | - which of our many source repos do we want in such a thing? There's only one source repo for kernel, git. It only makes sense to have stable branch I guess, since that is what most people will have on their device. | - how and when do they get updated/synced? Just do it once a day should be fine. My google method often gets me 2.6.17 and even that is OK for many things, like which include file is such and such struct defined in... grep is very noisy for popular struct names but lxr understands the definition action and lists it separately. so we basically have only one kernel 'version' in there which is git 'stable' and delete and regenerate that every night? | besides that it seems atleast 'do-able' (even if i really do not like | perl code anymore ;)) I read it was ugly to set up, but CPAN is the man for the perl stuff. still... perl is and will stay ugly ;) (just my own view).. too much 'write only', not intended for reading by people != the author. i have it on my wishlist ;) -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko codebases with Linux Cross Reference (LXR)
Andy Green wrote: Somebody in the thread at some point said: | Greetings all, | | I wonder if it would be useful for devel purposes to have the OM | sourcetree imported into LXR (http://lxr.linux.no/) so folks can have an | quick method to access code via HTTP, which I have personally found to | be much quicker than trying to large trees of C, espically better than | learning code via $EDITOR/grep. | | Any comments..? Would only of the openmoko.org folks be willing to set | this up..? I use this a lot myself, Google random APIs or structs with keyword lxr appended. It's meant to be a bit of a beast to set up and run, but I think it would be great. Gismo is this insane to hope for? -Andy currently i would rather like to put that onto the 'todo when we have a bit more time again' list. also i think there are some important questions IF we do that: - which of our many source repos do we want in such a thing? - how and when do they get updated/synced? it seems that stuff needs a lot of perl, postgres as db and a few other components, most important a search engine called 'xapian' i would like to have the time understanding it before using it. besides that it seems atleast 'do-able' (even if i really do not like perl code anymore ;)) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: microSD support
Giorgio M. wrote: I know that freerunner will support MicroSD memory. yes I want know wich capacity it will support?can i use 8GB microSD?? yes. all SD and SDHC compatible cards should work. tested with 4gbyte myself. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: questions for steve regarding group purchases
hi michele Michele Renda wrote: For openmok there is no difference, except than to pay x9 more payment fee. i beg to differ. the whole handling would make the gain of readily packaging 10-packs and ship these en bloc to one dest. vanish. so larry is right. thats like requesting 10% generic discount the whole point of it is: we are no escrow company, we are no bank, we are not paypal. we build the free and open mobile phone. and we want to focus on that. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is anyone else getting 2 or 3 copies of every mails?
hi, i would really like to get this issue resolved if it is one. but for that i would need some _complete_ mails with _all_ headers of the dups. (both dups) so if it happens again, please create a ticket at http://admin-trac.openmoko.org/ and attach both raw mails, so we admins have a chance to track down whats happening. kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki is down
Steven ** wrote: Myself and several others cannot reach the wiki. http://www.openmoko.org gives a 404 error (it redirects to http://wiki.openmoko.org/wiki/Main_Page which is Not Found) http://wiki.openmoko.org redirects to http://bugzilla.openmoko.org/cgi-bin/bugzilla/index.cgi hi steven. sorry for any inconvenience. we did a major mediawiki version update today in combination to some server restructuring and it seems some dns servers are still not in sync. unfortunately these are the ones between us and you, so it could take a few minutes to some hours till they refresh the caches. the switch is done and everything works as expected, and it will for you too as soon as these caches are all refreshed. we decided against letting the old installation keep running not to confuse people 'where their edits are gone' or 'accounts vanishing'. for a quick fix you could add 88.198.93.221 wiki.openmoko.org to your /etc/hosts for today. tomorrow/later everything will be fine by itself. ;) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki distorted in Firefox 3?
please retest, ive added a small patch, courtesy of abraxa. thanks for testing (most of us is till on FF2 here) ps: please use http://admin-trac.openmoko.org/ for any site, infrastructure, webservices issues from now on. the product and software/openmoko distribution issues will also move from bugzilla to a trac soon. will write up about it as soon as we are done (do not worry, no bugs should be lost at all, we will migrate them) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Request for stable, automated build process
Bobby Martin wrote: What I mean by a label (sometimes called a tag) is that your build process uses your revision control systems' commands to apply a label to all files before the build process starts. In svn, you use the svn copy command to tag files, like so: svn copy file:///tmp/repos/test/trunk file:///tmp/repos/test/tags/building -m tag tree (see http://svnbook.red-bean.com/en/1.1/re07.html) Unfortunately, I think OM uses three different repositories (svn, git, mtn) so you would issue at least three different commands to apply the label. Then when you're done with the build, you would relabel it with a build-successful tag, e.g.: svn copy file:///tmp/repos/test/tags/building file:///tmp/repos/test/tags/build-success-2008-05-02-13-47 -m tag tree (If the build happened at 13:47 on 2008/05/02) Then you run your tests and relabel with test-success-2008-05-02-13-47 if those pass. When the build is done, you delete the building tag so you can re-use it for the next build. You probably also want to tag those same files with build-success-latest and test-success-latest. That way people can pull that label from the repository and know what to expect. You can also look at the labels and see when good builds happened and when things broke. sounds nice, but i think due to the reasons you named it makes only very limited sense to tag it in any repo. (besides that buildhost shouldnt have write access. its executing scripts which 3rd partys released as software packages so its not on my 'trusted' list) after all we are building a complete distribution here, not only one software project which would be clearly contained and propably only in one repo. also we use loads of upstream stuff from different svn, cvs, git repos as well as tarballs via http or ftp. in addition to that these are cached and again exported by the buildhost. A good CI system will also email some set list of people when the build is bad with the files that changed since the last good build (this set ideally including the list of people who checked those files in) so the build tends to get fixed quickly. yeah. thats what i would like to have. Being able to retrieve the build products from good builds is obviously very important, but it's not necessarily very helpful for people doing development work. For them, being able to get the very latest code from the project they're working on, and the latest good code from all projects it depends on, is typically what they want. for that we manually cherry pick known to be usable builds after kevin dean tested these. they are at http://downloads.openmoko.org/recommended/ I have used trac a bit, but probably not enough to be helpful without studying up on it. I wasn't aware it provided much Continuous Integration support. I will do some research on it. nice. its a plugin into trac, not a base feature, but thats how it works. very simple skeleton with basic features, the rest is a plugin Thanks! Bobby btw: we still want to hire a web_developer_ (needs to know python i say);) -- Joachim Steiger developer relations/support ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Request for stable, automated build process
Michael 'Mickey' Lauer wrote: This is all good and well, however there's one inherently problematic issue to consider here. Continuous integration is very good and very possible (and we need and will to use it to improve quality), however where it really shines is, when the complete stack is under your control. Unfortunately (or rahter, luckily?), 80% of the Openmoko distribution actually is not under Openmoko's control and we do not want to go and open a repository and (effectively) fork all upstream projects. indeed. i thought of something more generic like bitbake invoking make check and put patches to add tests into the upstream packages into OE for now, with the goal for these to move upstream. after all, thats where tests belong and should be maintained. too bad the usual FOSS has a rather bad testcaseratio also i believe true CI will be problematic since the checkin rate is sometimes much higher than what buildhost could build. (cron triggered) -- Joachim Steiger developer relations/support ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Request for stable, automated build process
I haven't been on a project where we pulled a significant amount of code from repositories not under our control, and I agree that changes things slightly. It seems to me that it's more reason, not less, for CI, though. (Really, I think you're already on the same track...) atleast for QA reasons. yeah. Assuming that the outside repository doesn't already have a way to find the latest good build, just use a dated pull from the repositories outside your control, and record the label in a file. Use the latest good build date for the external code as your label to use when building the code that *is* under your control. well.. much easier than that: we just need to know the head revision of the OE repo which we use to build since all the revisions for regular packages should be fixed to known good ones. dates are a really bad idea as tag, since they break due to timezones. only real revisions should be used for pinning. you can also disable this pinning in OE with something called autorev, which would for example get the svn fetcher to use head instead of a pinned version. afaik we only use that 'feature' for our own stuff, and not upstream packages. You would probably want a separate CI process for each externally controlled repository, plus one for all the OM controlled code. Also, certainly for external code you would need to build on a schedule, rather than restarting the build when new checkins happen. Really, you should probably do the same for your internal code, too, though. (With the caveat that you only build your internal code at the scheduled time if changes have been checked in). this isn't really a concern due to the pinning i described above. means without anybody changing the revision to be used of some upstream code in OE it will stay the same forever. this enables incremental builds being quite fast while oe still should know when to rebuild if somebody updates the recipe with a new(higher) PR or a new version. but i think our OE crowd can explain these details much better than i can. -- Joachim Steiger developer relations/support ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Request for stable, automated build process
Bobby Martin wrote: On Thu, May 1, 2008 at 11:50 AM, Thomas Wood [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Well, there is buildhost.openmoko.org http://buildhost.openmoko.org which builds images nightly. I've been asking for the toolchain to be fixed and updated and I believe Julian has this on his TODO list. Regards, Thomas Thanks for pointing that out. Does it apply a label to builds that succeed? Is there documentation of what this hypothetical label might be, and also documentation of the build process that buildhost.openmoko.org http://buildhost.openmoko.org uses? (Hrm, reading over that, it looks like I'm trying to be sarcastic with the thanks. I'm definitely not! The thanks, and the questions, are real, not rhetorical.) -- If it doesn't make you smile, you're doing something wrong. i do not really get what you mean by labels. when buildhost successfully finished a build there is a new image. else, there is not. if it cannot compile all dependencies then it logically cannot package it. i think i know what you really want in the end. a full CI representation of what buildhost does build and what not. i have found http://bitten.edgewall.org/ recently and since we are currently in the process of moving to trac it is very interesting for me. whats missing is the glue between that and the openembedded build system. and to make it really usefull at all we would need unit tests for all 'packages', not only a 'built something' 'did report exit=!0' yes i want that. but let us finish work on getting trac first please ;) if you know your way around trac, python and OE i am happy about everyone who can help me there. -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Charging Neo Freerunner via USB port
Michael Shiloh wrote: Flemming Richter Mikkelsen wrote: - Ohh, and a valid charger ID would be a resistance between res_min and res_max. - Several pins could be probed You can only probe the pins that have the appropriate hardware interface to them. This may be all, but can't be taken for granted. One of the hardware people can tell us which pins are capable of this, and how you select which one you want to measure. there is only one pin to measure. the 'id pin' is pin number 4 directly beneath pin 5 which is gnd. pin 1 is vcc (5V) 2 and 3 are D- and D+ for usb data. thus all pins are 'taken' by standard besides the 'id pin' on gta02 its connected to an adc inside the pmu. details: the id pin is connected directly to pin9 of the pmu (adcin1) in addition to that there is one resistor of 100k(1%) to gnd and one of 39k(1%) to pin8 of the pmu (accsw) now everyone should be able to do the math while looking at the pmu datasheet. ;) motorola chargers have a 200k (pretty exact, shows 200.0 on my not-that-cheap-but-chinese multimeter) resistor to gnd. in addition to that they short D+ and D- to each others (read about that too in some usb-charging-spec), but i think we can ignore that because detecting that would propably quite some hacking if possible at all (dunno the usb-hw-if of the samsung enough) and also not that helpful. i wouldn want to have a 'range' of 'recognized valid resistance' but rather a table.. means * 48k - moko charger (2A) - 1A mode * 200k - motorola charger (550mA) - 500mA mode * ... if no resistor or short is detected - if it speaks usb and does enumerate us as 500mA - 550mA mode if it does not speak usb at all or only enumerates us as 100mA - 100mA mode the nice thing is: this whole feature doesn't affect the hw going to mp. its a software needs to have more (to be found out) values and fitting modes coded in. the code to measure the pin should be in uboot and kerneldrivers. didn't have a look at both yet. but yes. a nice small (can be console) way to find out the adc value would be practical to build the table of known to be valid chargers. -- Joachim Steiger developer relations/support ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: High Resolution Openmoko logo
OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Also you'll notice the OpenMoko community mailing list... should that be Openmoko? Andy it does. fixed. see below ;) -- Joachim Steiger developer relations/support ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008: Call for ideas
Lally Singh wrote: For middleware, it looks like all that's really needed is an OM version of Cocoa's NSNotificationCenter. IMHO I think it's a great place to start -- just a filtered event channel with a C-callable API for publishing/listening for events. I'd prefer a design that's simple reliable for small data packets over one that's overdesigned for the 1% of the time when you want to transfer bulk data. thats there already. its called d-bus and used by lots of gtk/gnome/glib apps already please take a look at http://www.freedesktop.org/wiki/Software/dbus thanks for your suggestion anyways kind regards -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Interview with Raider Realm
Ortwin Regel [EMAIL PROTECTED] 02/12/08 3:22 PM It sounds like Michael was talking about GSM in general. The area not covered by that indeed does seem negligible in the US. You have got a different issue. From what I picked up, it is not reasonably possible to change the hardware in a GTA01 to support the 850 Mhz band. The best option you have is probably to sell your GTA01 and get a GTA02 that supports 850 Mhz when they become available. Ortwin this is correct. due to limited resources we had to decide to rather focus on gta02 and make 850MHz possible there instead of finding a reasonable process on reworking gta01. the point is that ((shipping and manhours doing it) + (the time to set the whole logistics and process up / number of possible wanted reworks)) just gives a very unrealistic number which makes it even cheaper to directly go to gta02-850 and sell the gta01 to somebody who can use it in 900mhz-land. reworking requires lots of time due to the high packaging density inside a phone and also measuring equipment which we only have in asia. (which generates hassle with customs, taxes, etc.. you really do not wanna know ;) its not only changing firmware in gsm and exchanging a few parts. it also needs to be recalibrated. to sum it up: the status is that a 850mhz rework for gta01 for 'the masses' is not possible. please bear with us that this was not a decision taken lightly. -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: support for using yyyy-mm-dd (2008-01-31) date format in Wiki and elsewhere
Ian Darwin wrote:
No, they cannot. That is always, always year-month-day. It is an ISO
standard, is used in many countries (see the Wikipedia link in the OP),
and has been standard that way (maybe not de jure, but widely used) for
at least thirty years. The other is very commonly used both ways, split
between the US and other parts of the world.
i fully agree.
lets use -mm-dd
its totally clear to use it since it gives the slowest changing number
first and the fastest changing last (especially when adding a time (in
UTC of course ;) ) AND it also gets sorted correctly by machines.
ps:
please do not get me started about how chinese do count years (its '97
now, you know?) or how germans do it ('/' instead of '-' and starting
from the other end) ;)
kind regards
--
Joachim Steiger
developer relations/support
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki - confusion
Pietro m0nt0 Montorfano wrote: JW ha scritto: Hi Openmoko community The wiki needs to present clear information. There is one area where it is pretty bad at the moment and that is in all the confusing references to neo's and GTA01s and GTA02s. It seems to me there is now a clear structure 1) Neo1973 has internal codename (GTA01xxx) 2) Freerunner has internal codename (GTA02xxx) [snip] Hey, i think that you are a bit confused, asi've understood the names are: Neo 1973 - the phone, gta01 or gta02, is always the neo 1973 gta01xxx - first version of the phone for devs gta02xxx - second version of the phone that has to be released soon (oh we are waiting for it... :D) FreeRunner - another name to refer to the gta02xxx just to have a friendly name instead of GTA02 Is it right? yes. also all the drivers got fixed just recently to reflect that original naming scheme. Neo1973 is a class of devices, not only one specific model. gta01 and gta02 are models. FreeRunner a synonym for gta02 release version kind regards -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update: The 850 MHz issue
polz wrote: [...] Why were the phones shipped from the US, then ? Perhaps it would have made more sense to ship them from the EU where they seem to work fine and help many people save some dollars. thats simple: we had no shipping directly to customers at all before and we could get that service from a fic branch on quite short notice. at the factory there is no logistics which is suited to single pieces at all. so all the phones went to the us and got distributed from there. kind regards -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 52, Issue 11
rakshat hooja wrote: The product page still says that it is quad band http://openmoko.com/products-neo-base-00-stdkit.html thanks for pointing me to it. seems i missed to update one of the servers. - it should be fixed now. I think they will make the 850 version for the us market though I would prefer an operational quad band neo 1973 finally (as in 2008 atleast) we are considering that for sure. currently we need to work out the necessary details and test that before we know exactly if it works as we imagine, so please stay tuned, we will tell you more when we know it ourselves. -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qemu-Neo doesn't seem to work Ubuntu 7.10
Brad Pitcher wrote: The Ubuntu equivalent to setenv is export. Maybe you can just change them? please don't i will not help you the setenv call is on the uboot shell. that has nothing to do with the shell on the hostsystem. but to make sure you do not run into any problems there, check if /bin/sh points to /bin/bash and NOT /bin/dash (see also http://wiki.openmoko.org/wiki/Using_QEMU_with_MokoMakefile ) kind regards -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Gabriel Ambuehl wrote: On Saturday 13 October 2007 07:05:19 Michael Shiloh wrote: We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. So does this mean we now have GPS hardware that outputs NMEA on a serial port (or something similar) without having to run a closed source daemon? yes. it can also be switched to UBX protocol, but in default it speak NMEA and the regular gpsd can (and will be) used. so the last closed source component on the app-cpu is gone for gta02 -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: neo schematics for i2c access
hi mike, please take a look at http://wiki.openmoko.org/wiki/Neo1973_Hardware#Debug_Connector or http://people.openmoko.org/roh/Debugport_GTA01bv4.png for the pinout of the debug connector. the testpoints for i2c (which can be used for direct soldering) are located below the display on the same side of the pcb as the debug connector. you can see them on http://wiki.openmoko.org/wiki/Image:Gta01b_v4_back.jpg in the middle between the right hand 2 quadratic golden gnd planes also the upcoming debug board v3 will add a new pinheader with these signals on it ( http://wiki.openmoko.org/wiki/Neo1973_Debug_Board_v3 ) if you have further questions, please do not hesistate to contact me directly. kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
Krzysztof Kajkowski wrote: 2007/9/23, Dr. H. Nikolaus Schaller [EMAIL PROTECTED]: The standard Open Source Web Shop is OSCommerce (http:// www.oscommerce.com/). The only requirements it does not solve are * it is witten in PHP * it has its own database model Hi! Recently I'm running a one-person project on oscommerce and the deeper I get inside the code the more I see what a piece of ugly written software this is... Each file is a mixture of HTML, PHP and even SQL. There are no templates, no MVC nor other model, code is buggy, unmaintened and uses PHP classes like tables. It's a software that stuck in time five years ago... I would never do anything in oscommerce again. regards cayco thanks for that abstract. i couldn't say it better. in fact we had developed a web shop even before the gta01 sales started and in the end put it into a deep, black hole. yes it was based on oscommerce, but as soon as you tried to get it maintainable or even secure, every competent person does run away or is not ready to take any responsibility. for example: oscommerce does not run with register globals off. everybody with even a glimpse of clue about php should now know that this is totally unacceptable to run and use when you have respect for your users and feel some kind of responsible not to put their cc data into an sql-db which gets read out from obviously unmaintainable php. so please spare us further mails with 'why no oscommerce' 'why no php' there are 4 major important facts for you to know: - it has to be secure by concept. not only by clean work. - it has to be maintainable code. which means less is sometimes more (we do not believe in paying by lines of code) - it has to perform. which does not mean we rule out scripting languages - the code has to and will be audited before put into use by a professional team who knows all the stuff a usual webcoder gives them.. so beware ;) this mail should de-motivate anybody. but i think it is important that we already took a punch at it and got a bloody nose. we really know what we want and what we don't, now. -- roh ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
sorry.. this of course should read Joachim Steiger wrote: this mail should NOT de-motivate anybody. but i think it is important that we already took a punch at it and got a bloody nose. we really know what we want and what we don't, now. first caffeine, then mail ;) -- roh ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo Base/Advanced
Shachar Shemesh wrote: pHilipp Zabel wrote: work and JTAG, which you need if you have busted the bootloader (be it by hacking or it or entering nand erase on the console). Does the JTAG also support single-stepping (ICE)? jap. only makes sense in kernelspace / uboot due to the mmu, but thats where you need it. userspace is mostly better debugged with a gdb running on the device. the software used on the host side is openocd which gives you a console to the jtag (halting, stepping, etc) and a gdb stub to connect gdb on the host to. for more informations please take a look at this page http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_configuration the debug board is pin-compatible with the amontec jtagkey tiny, just with different usb-ids the essential config is: ft2232_vid_pid 0x1457 0x5118 ft2232_layout jtagkey Shachar kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo Debug Board Schematics or Pinouts
Heilpern, Mark wrote: Are these signals TTL level or are they already RS-232? If they are TTL, is there any reason I could not use the BrainStem from Acroname (http://www.acroname.com/robotics/parts/S13-SERIAL-INT-CONN.html) to overcome this? (That device only uses TXD, RXD, and of course power and ground). it is 3.3V cmos logic so NO RS-232 levels. you could use that board you linked to connect to the serial console of a moko, i think. at least in theory because you still need to build an adapter for the fpc. and supply it with 3.3V (the specs of the brainstem say it can be used with 3.3V) you just need to keep in mind that the serial is getting switched on and off by GSM_EN and some latches on the debug board. kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo Debug Board Schematics or Pinouts
wee.kiampeng wrote: Hi folks, I will like to to have a peek at the Neo debug board's schematics or pinouts. I need to access the uarts as well as the jtag. Does anyone have any idea? we already are in the process of releasing the neo debug board schematics since we believe that it would be useful not only for the moko, but for a lot of different usecases for the embedded hacker community. please give us some more time do do this properly. if you need to access the serial of the ftdi via the 2.54mm spacing port ( J10 ) the pinout is as follows: 1 TXD 2 RXD 3 RTS 4 CTS 5 DSR 6 DTR 7 DCD 8 RI 9 GND 10 VCC (3.3V) remember, this is the port B of the ftdi2232D so the mapping is BDBUS0-BDBUS7 pin 1 to pin 8 to get a serial from your linux kernel do this: modprobe ftdi_sio vendor=0x1457 product=0x5118 then you get 2 serial of which one will vanish as soon as you start openocd to use portA as jtag J1 on the debug board is JTAG in regular arm 20pin out kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
openmoko at the chaos communication camp 2007
hi there. for those who do not know yet: there will be a huge open air hacker gathering in germany finding place at an old airfield near berlin for more details please click here http://events.ccc.de/camp/2007/Intro/ some people from openmoko and hopefully many interested hackers will gather in the gsm village http://events.ccc.de/camp/2007/GSM_Village discussing and doing hands-on-hacking on diverse devices. hopefully it will be a productive but relaxing time and i look forward meeting some of you there. if you have any questions please do not hesitate to contact me directly. kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ...Order shipped: OpenMoko direct order
Shachar Shemesh wrote: [...] Meanwhile, is there any way to run the OS only in an emulator? On another ARM platform, perhaps? take a look at http://wiki.openmoko.org/wiki/OpenMoko_under_QEMU that qemu emulates the GTA01bv4 hardware or at least does that to a degree which is enough to boot unmodified firmware, intended for the real hardware on it and work on apps for example. kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: this phone, with WiFi
Mikko Rauhala wrote: ti, 2007-07-17 kello 21:47 +0200, Visti Andresen kirjoitti: And finally one more sour lemon, as far as I remember this version of the Neo only has USB 1. That will limit the maximum network speed to 11Mb/s and that even before deducting USB protocol and driver waste of bits... I don't know if you were planning on transferring large files routinely to and from the Neo, but for most purposes this really wouldn't be a major bottleneck. Actually, I wonder how the AR6K chip is going to be interfaced in GTA02. The BT is currently behind the SoC's USB interface. I could see the WiFi part accompanying that perhaps. Or not. (Hmm, couldn't find specs for the new SoC right now to check its USB capabilities.) Incidentally there are also downsides to having the BT behind USB, since the SoC apparently needs not to be in low power mode when it's in use. Probably usually not a biggie, since you're often actually doing something when you need it, but eg. using the Neo as a BT GPS probably would apparently be otherwise feasible with a bit less of a drain. thats why the ar6k module will be connected via 4bit wide sdio -- kind regards Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
wiki write access limited
due to a lot of spam/edits by bots we now have limited the write access to users who have registered a working email-address. were sorry for that. please report when there are any new bugs due to this. regards -- roh ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Disconnected LCD
Hans van der Merwe wrote: Will the phone still work - bootup and function as normal - if I disconnect the LCD? It for an experimental, low power, vacuum environment. yeah, it should work. [...] http://www.sunspace.co.za/emaildisclaimer.htm the only question it leaves me with is: what do you want to do with an gsm phone in high orbit? ;) kind regards -- roh ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
