Re: still having trouble getting Neo to boot Qtopia from SD
Hi Ian, I have to admit I have not had time to out this on my SD card yet but I have booted it from the neo normally. On 27/09/2007, ian douglas [EMAIL PROTECTED] wrote: So to recap what I've tried, that doesn't work to get Qtopia on my SD card and boot from SD: I went to http://www.qtopia.net/modules/devices/openmoko.php and downloaded the three files under Qtopia for the Neo1973 Downloads, and unpacked them onto a 2GB microSD card, formatted as ext3: # mount /dev/sdc1 /media/sdcard # tar -C /media/sdcard -zxvf \ /path/to/qtopia/ficgta01-qtopia-developer-rootfs.tgz # tar -C /media/sdcard -zxvf \ /path/to/qtopia/arm920t-eabi-ficgta01-toolchain.tgz # tar -C /media/sdcard/boot/ -xzvf \ /path/to/qtopia/qtopia-4.3.0-preview-neo-flash.tgz ... the last step of course placed the uImage file and the rootfs file into the SD card's /boot/ folder (there's no documentation anywhere that describes where else to place these, so I was guessing as I went) Looks like your problem is that you do not need the developer rootfs or the toolchain to boot into qtopia from the sd card. Inside /path/to/qtopia/qtopia-4.3.0-preview-neo-flash.tgz as you noted is the rootfs and the uImage. These are the only two you need. uImage in /boot/ and rootfs in / If I have time tonight I will confirm this for you. always too busy with work... -Pete ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Unified PIM
Think, at current state of cooperation between projects (OpenMoko Qtopia) synchronization with server is one of the very few ways (I'd prefer to see SyncML; there are few of free and commercial servers supported this protocol already). But also it is possible to synchronize different databases by using local files - just export/import procedures, maybe even automatically (on each start/stop for example). What do you think? VC [EMAIL PROTECTED] wrote: I guess my only comment is that while I don't really care which interface people use on their phones, it seems like the data interfaces should be the same... If I open up qtopia phone edition and look at my contacts or maybe even edit them and then close it down and open up my OM interface and look at them, they should be the same. All edit are visible.. No double entry. Agreed, but I'd take it one step further. Given the neo has an internet connection, why can't PIM data be stored on a web server and just cached locally. Couldn't you then integrate that into desktop PIM applications too? Ok, so this isn't a new idea. :-) Evolution Data Server supports integration to groupware backends, but from what I've seen, these are enterprise-class groupware servers designed for corporations. I can't seem to find anything designed for the consumer, an internet-accessible groupware server I can sign up to and store my contacts in a single place. The problem is not local - I'd be surprised if Embedded EDS couldn't be adapted to store it's data on a server and just use a cached dataset locally. The problem is that this requires some server infrastructure and so far I've yet to find something which will do it. Has anyone else seen this done? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: OpenMoko 2007.2 on Palm TX
Hi... ...yesterday I solved the problem with the dpi settings so that the font size is big enough to read something... ;-) look here for screenshots and video: http://zefanja.blogspot.com/2007/09/openmoko-20072-on-palm-tx.html .:zefanja:. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS accuracy
Sven Klomp pisze: On Friday 21 September 2007 21:43:45 Krzysztof Kajkowski wrote: 2007/9/21, Sven Klomp [EMAIL PROTECTED]: Hi, Hi! Check out picture in this article: http://www.openmoko.org.pl/node/41 I had my Neo on the buttom of my back pack while riding a bike. Accuracy was up to about 2m. It was realy good. This sounds (and looks) very promising. I added Geocaching as possible application to the Wiki. BTW: Nice blog with interesting (and for me some new) details. But unfortunately in Polish :-) The latest articles are bilingual or if they don't they are surely directed to Polish OM Community. Openmoko.org.pl co-director :-) Best regards. -- *Bartlomiej Zdanowski* Programmer Product Research Development Department AutoGuard S.A. Place of registration: Regional Court for the Capital City of Warsaw Registration no.: 287629 Share capital: 1 059 000 PLN Polish VAT and tax ID no.: PL1132219747 Omulewska 27 street 04-128 Warsaw Poland phone +48 22 611 69 23 www.autoguard.pl http://www.autoguard.pl ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo Developer Version
Hello Andreas, On Wed, 2007-09-26 at 17:02 +0200, Andreas Hennig wrote: Some more Phase 1 Neo's will be shiped end of september. Does somebody now, whether they will be GTA02 or GTA01? GTA01. GTA02 cannot be ordered yet and they will be more expensive (thus they will probably not be shipped to cover GTA01 orders). Regards, Daniel -- Daniel Mewes ([EMAIL PROTECTED]) Phone: 0800 DAMEWES (3263937; from inside Germany, I call back) Mobile: +49 (0) 160 8577603 Pager: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
R: Qtopia coming for Neo1973
Also agree with you there, there are pros and cons to having an X server I was just answering to the people pretending that there are no cons at all, which is untrue. But qtopia is written with qt, isn't possible recompile it with the support for X? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Unified PIM
Joshua Layne schrieb: On Wed, 26 Sep 2007 18:49:43 +0100, [EMAIL PROTECTED] wrote: I guess my only comment is that while I don't really care which interface people use on their phones, it seems like the data interfaces should be the same... If I open up qtopia phone edition and look at my contacts or maybe even edit them and then close it down and open up my OM interface and look at them, they should be the same. All edit are visible.. No double entry. Agreed, but I'd take it one step further. Given the neo has an internet connection, why can't PIM data be stored on a web server and just cached locally. Couldn't you then integrate that into desktop PIM applications too? I would prefer to not have a network dependency on PIM data. It might be a nice extra feature, but I would like to see the core data held on the phone supported by the different front-ends. I may want to switch frontends without resyncing all my data. It seems like LiPS might be a good start for this shared architecture. As one being involved in LiPS I feel obliged to reply here ;) Yes, with the LiPS approach both sides could be satisfied... the LiPS PIM API is devided into an upper layer service API for applications to use and a lower layer Enabler API for connecting backends. So what an application would do is to use the service API and then you can use any application that conforms to that API without resyncing your data. Also for the backend, the application does not need to know where the data comes from, be it a network remote calendar or a local EDS contacts database. So for me it would make perfect sense to use the LiPS APIs and bring some flexibility to the applications. In the event of a non-compliant implementation, perhaps wrapper/abstraction scripts could be built to make it transparent to the end user? I would prefer to use a standardised API... make things a lot easier. Regards, j. Cheers nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: still having trouble getting Neo to boot Qtopia from SD
Yeah, I can flash it to the Neo and use it that way, but I was hoping for the dual-boot feature that others have talked about. -id Peter A Trotter wrote: I have to admit I have not had time to out this on my SD card yet but I have booted it from the neo normally. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Buglabs
Anyone know about this company? http://www.buglabs.net/products There is a Yi-Tan conference call about them in 5 minutes but I've never heard of them. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: System developers ask for project
Vittoria Cozza wrote: Thanks, it could work. but... we are more interested in contribute in the improvement of openmoko framwork adding some lowlevel functionalities and not in an application level projects. It depends what you mean by application level. I'd say getting some of the interfaces done to important services (like sending SMS text messages or playing music) is pretty important. Then those of us with access to test subjects can start doing usability testing, while others continue working on the hardware interfacing problems (like sharing one UART between different modems). Who knows what has more priority in opemoko to do list and can be done from a small group of students? This also depends on what course the students are doing. Is is an electronics/hardware focussed one, one centred around the O/S, or do they learn more about graphical interfaces? -- Dr. David R. Newman, Queen's University Management School, Belfast BT7 1NN, Northern Ireland (UK) Tel. +44 28 9097 3643 FAX: +44 28 9097 5156 mailto:[EMAIL PROTECTED] http://www.qub.ac.uk/mgt/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 4 GB SD flash card does not work
Ole Tange [EMAIL PROTECTED] wrote : It does not show up in /dev. Sounds like kernel/driver or hardware issues. Probably best to log a bug in the bugzilla and supply your dmesg output. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: still having trouble getting Neo to boot Qtopia from SD
ian douglas pisze: [...] So Piotr, could you maybe please post your bash_history for us to see what exactly you did, to get this going? I'd be happy to edit the wiki page for Qtopia on the Neo for booting from SD if I can just get this going -- but experimentation is just frustrating when others obviously have already tried Qtopia on the Neo. Thanks, Ian I have repeated all the steps once again, and below is everything I had to do (as I wrote earlier, I didn't have to add uboot menu). I have verified that both Qtopia from SDcard and Openmoko from nand memory are booting. Still don't have working sound in Qtopia and no time to play with it now. Please notice that I used kernel not from Qtopia site, but most recent I have downloaded for Openmoko. [root: ~] # modprobe mmc_block [root: ~] # modprobe mmc_core [root: ~] # modprobe sdhci [root: ~] # [root: ~] # ls -l /dev/mmcblk0* brw-r- 1 root disk 252, 0 wrz 27 20:08 /dev/mmcblk0 brw-r- 1 root disk 252, 1 wrz 27 20:08 /dev/mmcblk0p1 [root: ~] # [root: ~] # [root: ~] # [root: ~] # mkfs.ext3 /dev/mmcblk0p1 mke2fs 1.38 (30-Jun-2005) Etykieta systemu plików= Typ OS: Linux Rozmiar bloku=1024 (log=0) Rozmiar fragmentu=1024 (log=0) 123952 i-węzłów, 495460 bloków 24773 bloków (5.00%) zarezerwowanych dla superużytkownika Pierwszy blok danych=1 Maksymalna liczba bloków systemu plików=67633152 61 grup bloków 8192 bloków w grupie, 8192 fragmentów w grupie 2032 i-węzłów w grupie Kopie zapasowe superbloku zapisane w blokach: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Zapis tablicy i-węzłów: zakończono Tworzenie kroniki (8192 bloków): wykonano Zapis superbloków i podsumowania systemu plików: wykonano Ten system plików będzie automatycznie sprawdzany co każde 33 montowań lub co 180 dni, zależnie co nastąpi pierwsze. Można to zmienić poprzez tune2fs -c lub -i. [root: ~] # [root: ~] # [root: ~] # [root: ~] # mount /dev/mmcblk0p1 /media/card [root: ~] # [root: ~] # [root: ~] # [root: ~] # ls -l /media/card/ razem 12 drwx-- 2 root root 12288 wrz 27 20:17 lost+found [root: ~] # [root: ~] # [root: ~] # tar -C /media/card/ -xzf Download/ficgta01-qtopia-developer-rootfs.tgz [root: ~] # [root: ~] # [root: ~] # [root: ~] # [root: ~] # [root: ~] # ls /media/card/ bin boot dev etc home lib lost+found media mnt opt proc sbin sys tmp usr var [root: ~] # [root: ~] # ls /media/card/boot/ zImage [root: ~] # [root: ~] # [root: ~] # cp Download/uImage-2.6.22.5-moko11-r2-fic-gta01.bin /media/card/boot/ [root: ~] # [root: ~] # [root: ~] # cd /media/card/boot/ [root: /media/card/boot] # ls -l razem 1608 -rw-r--r-- 1 root root 1637614 wrz 27 20:29 uImage-2.6.22.5-moko11-r2-fic-gta01.bin lrwxrwxrwx 1 root root 22 wrz 27 20:27 zImage - zImage-2.6.21.6-moko11 [root: /media/card/boot] # ln -s uImage-2.6.22.5-moko11-r2-fic-gta01.bin uImage [root: /media/card/boot] # [root: /media/card/boot] # [root: /media/card/boot] # [root: /media/card/boot] # ls -l razem 1608 lrwxrwxrwx 1 root root 39 wrz 27 20:30 uImage - uImage-2.6.22.5-moko11-r2-fic-gta01.bin -rw-r--r-- 1 root root 1637614 wrz 27 20:29 uImage-2.6.22.5-moko11-r2-fic-gta01.bin lrwxrwxrwx 1 root root 22 wrz 27 20:27 zImage - zImage-2.6.21.6-moko11 [root: /media/card/boot] # [root: /media/card/boot] # [root: /media/card/boot] # [root: /media/card/boot] # cd [root: ~] # [root: ~] # [root: ~] # umount /media/card [root: ~] # [root: ~] # and that's it... Piotr P.S. sorry for output in polish, but it is nothing important... good luck ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS (was Re: gpsd and AGPS)
On Tue, 04 Sep 2007 17:27:18 +0200, Harald Welte [EMAIL PROTECTED] wrote: Just to clarify this: We have both GTA02 prototypes with GL/Broadcom and with a a competing firmware-based AGPS solution. Will the choice between them have settled by the time GTA02 becomes available to order? Would be a disappointment to order a device and be unable to develop/test/use GPS software on it because the other kind of chip has been chosen. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: At the risk of being flamed : State of software
On Tuesday 28 August 2007 17:05:20 Attila Csipa wrote: On Tuesday 28 August 2007 16:39:54 Gabriel Ambuehl wrote: No they didn't. But TT employees keep pushing the idea at the very least. This is their good right, but I reserve mine to call them on it ;) Can you give some references on this (just out of curiosity) ? Look around, there's TT employees in this very thread (not overly pushing it, but at the very least, TT seems interested in OM)... And occasionally some remark spills onto PlanetKDE. an end-user device, for which they apparently hope to get commercial interest from mobile phone vendors (in which they admittedly haven't been all that successful as of yet). Exactly, but partly because of a chickenegg issue which they could perhaps tackle with an OpenMoko port of Qtopia... signature.asc Description: This is a digitally signed message part. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Forum? (Was Re: Neo Sound and USB Questions)
On Tuesday 21 August 2007 15:06, Dr. H. Nikolaus Schaller wrote: Am 21.08.2007 um 12:46 schrieb Harald Welte: I am from the community ;) And not in my 10+ years of FOSS community development have I seen any project that had problems with properly using mailinglists. By deciding not to have a forum, you will loose some participants. And those who remain will have no problems. So, this argument is not a proof... Show me a single succesfull opensource project which uses *both* mailing lists and a forum *for development*. Just one. So far the lack of proof is on your side of the argument. Well, I don't know how old you are but I did send my first e-mails approx. 1984 and wrote my first UNIX programs at that time. Nevertheless I would prefer a forum. I was 5 years old in 1984, my first email account was a webmail account. I never used the internet before grahical browsers existed. Nevertheless I whould prefer a mailing list. So what? If personal perference has to be the norm you will get all kind of things, but never a community. I'd use the forum if that was where the action was. But i'd *never* try to split up an active development community over the choice of communication medium. That might be an unwise decision - but you are the decision taker :-) Thats a very wise decision. There is *no* reason at all to split the developers into two groups, forum users and mail users. That is a very stupid idea. Regardless of wich is supposedly better you should never split a community over several different communication mediums, and you should not try to radically change the medium either. For that reason alone Harald is right to oppose against forums (for developer usage, that is). AVee (I've said it, I won't be dragged into discussions about this) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM Radio
Brad! :) neo uses a csr bluecore4 chip. there's a bluecore5-mm which includes an fm radio. It might even work where the bc4 currently sits. otoh, the bc5-mm is starting to show up in bluetooth headsets. As long as you didn't need to record the radio for some reason or expect to get sideband data, this takes the phone out of the loop nicely. Brad On 8/23/07, Brad Arnold [EMAIL PROTECTED] wrote: That information is not entirely correct. The NXP TEA5766 has FM, RDS, and I2C. It can be implemented in a 36 mm square area with only 11 external components (other than the IC). It Operates at 2.7V, 15mA, and consumes 40.5 mW. The size of the IC itself is 3.3x3.3mm. Sounds appealing, doesn't it? Brad On 8/23/07, Ian Stirling [EMAIL PROTECTED] wrote: Tilman Baumann wrote: Giles Jones wrote: Ian Stirling [EMAIL PROTECTED] wrote : It's valuable if it's very cheap or free. But it's another chip on the already large board. Agree DAB radios are more useful given the number of extra channels. Agree. Definitely more geekish. :) There's no end of features you could implement, mobile TV would be another feature now that the EU have standardised on a format. A DAB receiver could also supply you with DMB data. Which would be for example video compressed for mobile use... DMB is DAB with oder codecs used in the data streams. A FM radio (using the above mentioned chip) can be implemented in under 10mm*10mm board space, and under about 10mW power. A DAB radio takes (ballpark) 50mm*50mm, and 500mW. Not to mention that in the UK, the sound quality is often worse. The regulator recently dropped the requirement for 128kbps, and lets the broadcasters drop the bitrate as far as they like. And this is Mp2, not even mp3. As to why not carry a seperate radio. It's another thing to lose, charge, and get tangled in my pocket. It doesn't vibrate to remind me when my favourite show is on. It needs batteries charged. It can't timeshift programs. It can't broadcast sound over bluetooth. Calls can't break into radio I'm listening to. It can't compress quiet programs to a high average volume. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia coming for Neo1973
I also prefer GTK+ and have invested some time developing an application on my Neo with it. I find it very easy to develop and test on my GNOME based desktop (Ubuntu) and re-compile for the Neo. I hope OpenMoko continues down the same route. John (putting a vote in for GTK+) Joshua Layne wrote: Michael Schmidt wrote: Hi, great news, but what does this mean? We need a posting of the projekt management, will Neo s Menue switch to QT? This means a GTK application will not work? Or: Any QT-Applicaiton will work now automatically? We need this info, for a decision, to stick to the library either a GTK-Gui or the existing QT-Gui. To not saddle on the wrong horse.. please send a notice Applications for Neo, should have a GTK or QT gui? Applications for the _Neo_ can have whatever gui the developer wants to build (or as many - there are several apps that support multiple rendering environments) Applications for _*openmoko*_ should have a GTK+-2 gui. openmoko isn't switching to QT. there is just now another gui available. for myself - I much prefer GTK interfaces. and will be sticking with GTK on the Neo (when I buy) Rgds, j. thanks On 9/18/07, Mauro Iazzi [EMAIL PROTECTED] wrote: before someone beats me to it. http://trolltech.com/company/newsroom/announcements/press.2007-09-17.9260755578 and http://www.linuxdevices.com/news/NS5429713730.html In short: Qtopia is going to be fully GPL'd (telephony applications included, which weren't) and is being ported to Neo1973. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardiness/Sports Use
Baxter Kylie wrote: take repeated jarring up and down? Also, is it too heavy or too big for an armband strap? Hmm. I think it really depends on your size. It seems pretty hardy to me. One of mine has suffered a slight drop with no problem. Assuming the unit is up to these tasks I fully intend (with a gen2 in hand) to try to get an app up and running for logging this type of info ... anyone who thinks this is a good idea or has any additional thoughts, I'd love to hear them! I'm an avid cyclist and I am also thinking about a similar app. Something that integrates track data to a site like http:// www.motionbased.com (by Garmin though) would be very cool. It handles the mapping and data analysis. I think this is where my GTA01 is going to head once new hardware revs come out. I don't want to strap my shiny Neo on my handlebars just yet, but as soon as I get my grubby hands on a new one, the GTA01 on my bike can start bluetoothing GPS data to my desktop and onto the web. :-) -E PS. I've CC'd this to openmoko-apps since that where it belongs I think. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: still having trouble getting Neo to boot Qtopia from SD
well, it is very simple to make sound to work, I need to update kernel modules for this... :-) Piotr Duda pisze: [...] Still don't have working sound in Qtopia and no time to play with it now. Please notice that I used kernel not from Qtopia site, but most recent I have downloaded for Openmoko. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Message duplicates (was: Changes between GTA1 and GTA2?)
Hello, On 8/27/07, Harald Welte [EMAIL PROTECTED] wrote: that would really be easy. unfortunately it just locks up, doesn't die. Is there any way that this lock up could be detected programmatically? If so, then you could a) have a service monitor restart spamassassin or b) alert an admin )via e-mail, sms, whatever) HTH -- Regards, Torfinn Ingolfsen ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
