Re: WikiReader
Sean Moss-Pultz wrote: > Sales start today at http://thewikireader.com. Enjoy. Tell your > friends. And let us know what you think! My first impression of the device - it's a Palm IIIx with 1000 times more storage, but poorer connectivity and fewer applications. I have an electronic subscription to a couple of science-fiction magazines which I currently read on my old Palm IIIx. It's showing its age so I have been looking for a replacement for a while now. The Wikireader (with its sunlight-readable screen and AAA batteries) would fit this category as soon as an e-book reader application is available. Some other PDA applications like a calculator and a memo pad would be nice but I can live without them. If/when an e-book application is developed, it would be nice to have an SD-card image of the Project Gutenberg archive. I also have a question - what happens to equations and graphs in Wikipedia articles (e.g. http://en.wikipedia.org/wiki/Bessel_functions)? Are equations rendered graphically or are they only shown in markup language? Are SVG images supported? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: at command
Test wrote: > > I am playing w/ some AT commands. If you know what are these AT commands > for? let me know, and also how to use them? AT+CLVL sets the audio output volume from the Calypso (see for example http://docs.openmoko.org/trac/ticket/2121). I don't know about the others but one of the references linked from http://wiki.openmoko.org/wiki/Hardware:AT_Commands might have some information. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: some questions before buying FreeRunner
a dehqan wrote: > An important question about GPS signals ,Is not IRAN far from The > satellite that sends signals ?will not signals be weak in Iran ?How > can we be sure that GPS antenna is not needed in open area in Iran ? The main GPS satellites are in circular orbits around the earth, so the signal quality in Iran will be the same as any other place at a similar latitude (assuming that the US government isn't doing anything to intentionally degrade the signal in your part of the world). You are likely to be out of range of the geostationary "WAAS" satellites that broadcast additional information, but these signals are not required for basic GPS operation. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Cameron Frazier wrote: > Ahh, ok. Now things seem to be working correctly. One question though > what are the differences between usb_curlim and chg_curlim? I'm not > sure I fully understand what chg_curlim represents. chg_curlim controls the battery charger, while usb_curlim controls the total current that can be drawn from the USB port (charging + the current used by the Freerunner). The PCF50633 datasheet (linked from somewhere on the wiki) has more information. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Forcing fast-charge
Cameron Frazier wrote: > Does anyone know what the current means are to force fast charging at > 500mA and could they share it with the list? I don't know if there's a dbus/frameworkd way to do it, but the direct method is: echo 500 > /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] timezone broken again
Michael 'Mickey' Lauer wrote: > AT%CTVZ=1 just enables the unsolicited result code. There is no way to > actually _query_ the time from the network. I don't know what method it uses but my Nokia 3500 phone gets the current time+date automatically (operator is Fido in Canada). I've tested this by manually setting an incorrect value and then power-cycling the phone, and it goes back to the correct time as soon as it boots up. I did a quick test with 'mickeyterm' on my Freerunner and I haven't seen any %CTZV messages yet. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leather case for Neo freeruner now 29 Euros
David Reyes Samblas Martinez wrote: > Now the Openmoko leather case is at 29 Euros Vat included + Shipping costs > at www.tuxbrain.com/shop Do you ship to Canada, and if so what are the costs + payment options? If not, does anyone know of a similar product in North America? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how do i turn the phone off?
The Digital Pioneer wrote: > Universal phone shutdown instructions (works on any distro): > 1. Remove back panel > 2. Remove battery > 3. Replace battery > 4. Replace back panel > Done! 0. Unplug the USB power cable. The FR is capable of operating without a battery (although GSM and some other bits are not). The correct answer is of course to open a terminal and enter the command "shutdown -h -P now". :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Internal speakers: Stereo or mono?
arne anka wrote: > neo1973 had stereo, freerunner never had (and afair was never supposed to). IIRC the second speaker was removed from the Freerunner to make space for the WiFi module. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
Laszlo KREKACS wrote: > I can't express how sad I'm when I read Andy Green left Openmoko. > > I do not know why he left (and it is not my business anyway), but > I know since Andy was at Openmoko the kernel side began > to form shape, and got things work. (suspend? anyone?) You should have stopped here IMHO. It really is none of our (community's) business, and it would be a lot more productive to just focus on the question of "where do we go from here?" ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Data call (aka CSD) with QtExtended
Ed Kapitein wrote: > I am also looking for a way to make data calls, do you know of any other > method of making a data call with the FR? > ( direct AT commands to the modem etc)[...] > All pointers are welcome! First you need to make sure that your GSM carrier supports CSD (mine doesn't AFAIK) and that it is activated on your account. In the past people have mentioned that the Calypso performs similarly to an "Enfora Enabler" modem and there is some web-accessible documentation for that. The "AT+CBST" (select bearer service type) command seems to be involved. There's probably some overlap between the CSD commands and the ones used for GPRS so I would also look at http://wiki.openmoko.org/wiki/Manually_using_GPRS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Fernando Martins wrote: > 1) I got the date reset to 1970 a few times. I was not paying attention > but I guess this happens when battery is removed, i.e., there's no > battery specific for the clock? There is a backup battery. Make sure that the system time is being saved to the hardware clock, e.g. "hwclock --utc --systohc". ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debug Board in Vancouver, BC
Vasili Sviridov wrote: > Thanks, what's the good version of NAND uBoot to flash? I don't know - I haven't been keeping up-to-date with Openmoko development for several months. I'd try http://downloads.openmoko.org/daily/testing/gta02v5_and_up-u-boot.bin first. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debug Board in Vancouver, BC
Vasili Sviridov wrote: > Ok, that made it even worse :( > > Now I only have NOR uBoot and dfu-util still gives me only 1 alternate > there which is "USB Device Firmware Upgrade". > Cannot flash the NAND uBoot, since dfu-util does not see the required > partition... Don't pay too much attention to the "dfu-util -l" output - there are two different modes the device can be in, and in the default one you don't see the other alternate settings listed. When you run the dfu-util Download command it should automatically set the device into the required mode. If it fails then try running the exact same command a second time - sometimes it fails on the first try. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debug Board in Vancouver, BC
Vasili Sviridov wrote: > Hello All, > > Since both my previous posts haven't helped me to fix my phone looks > like I need to devirginate it. Unfortunately I do not have the debug > board, and paying $100 + shipping is a bit steep for just one thing to do. > > Is there anyone in Vancouver, BC that has one and willing to help me to > get my Moko working - please respond. I have a v2 (Neo1973) debug board in Vancouver, but you shouldn't need it if you have a Freerunner with a working NOR u-boot. I haven't read all of the previous messages in this thread so someone else might have already said this, but I would: - Boot into NOR u-boot - Erase the NAND ("nand erase" or "nand createbbt") - Exit from the u-boot console - Flash a new u-boot ("dfu-util -R -a u-boot -D /path/to/u-boot.bin") - Reboot into NAND u-boot, then enter the u-boot console - Execute "dynpart", "dynenv set u-boot_env", "saveenv" to set up the default environment variables - Reboot into NAND u-boot again - Download a new kernel + rootfs with dfu-util - Fix up the rest of your environment variables through the u-boot console. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: uboot version? wiki not accurate
Helmut Tessarek wrote: > What is gta02v5_and_up-lowlevel.bin? The "lowlevel.bin" file is used with the debug board, to initialize the Freerunner so that you can upload a copy of u-boot into RAM over JTAG. If you don't have a debug board then you can ignore it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner won't charge, and won't start anymore due to out of power
Alexander Frøyseth wrote: > Does anyone know WHY it don't charge when it is off? > My logic says that it is very important to have the option charge the > battery when it is flat. I can't give you a simple answer. Charging is controlled by the PCF50633 chip, based on configuration values that are written to it by u-boot, Linux, and userspace programs. Some of these settings are preserved across a power-cycle (the PCF50633 has a small backup battery that's also used to keep the RTC running) so the behavior at startup depends on the software that you used during your last session. Another complication is that some Freerunners are capable of starting up without a battery while others are not (possibly due to different capacitor values on the internal power rails). I can give a few hints: - The current u-boot has a bug that means it will not properly charge from the wall charger. Try a USB cable into a PC instead. - Try to boot into the NAND u-boot menu (hold power and then aux) and then select "power off". This may leave the device in a state were it will charge. Wait 15 minutes and then try to boot Linux. - Try booting through NOR u-boot instead (hold aux and then power) with either the wall charger or a 500mA USB connection, then try booting Linux. - If the device shuts off during one of the above attempts, let it sit for a few minutes and then try that same item once again I've written some u-boot patches that improve low-battery handling. Anyone who's interested can take a look at the openmoko-kernel list for more details, but be warned that the code is not yet ready for general distribution (i.e. anyone who tests it does so entirely at his/her own risk). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Getting rid of echo for callers.
Daniel Selinger wrote: > This settings removes the echo for the other person completely, at > least for my hardware. I didn't hear any buzz either on my final > testcalls, could be luck. With those settings, were the two of you still able to easily hear each other talking? Did you test in a quiet environment or one with some background noise? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Third request: what *is* the warranty on the Freerunner?
tokenwizard wrote: > Ok, well as soon as I have time to deal with it I'll have to try and > Frankenstein some type of power cable contraption to get this thing booted > to the point the USB charge can kick in. Seems a little premature for such a > function to kick in when the battery is only slightly less that half > charged. Effectively, halving the battery capacity. More likely, whatever was telling you that it was "half charged" was mis-calibrated or had stopped updating. By the time the internal cutoff circuit activates, the battery is drained. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dfu_util and preflash-Backup
Christian Weßel wrote: > Hello > > I tried to save my rootfs by wiki's way (./dfu-util -a rootfs -R -U > good-rootfs.jffs2) and failed after a lot of minutes and 246MB with > > dfu_upload error -108 Sorry, I don't know what that error means. However anyone wanting to use "dfu-util -U" should look at http://docs.openmoko.org/trac/ticket/676 - dfu-util upload seems to cause data corruption. I tested on a GTA01Bv4, so it would be useful if someone could repeat my test on a production Freerunner and then add a note to the bug. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel and Dual booting
Mikael Berthe wrote: > Or is there a way to prevent opkg from flashing the kernel? It would be > nice to upgrade /uImage.bin instead! I don't know of a way to do this at the moment, but it would be a nice enhancement. Perhaps the flashing script could check to see which device was mounted as the root filesystem, and only proceed with the flashing if it was a NAND partition (/dev/mtdblock?). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What's the latest stable u-boot image for FreeRunner?
Holly Lee wrote: > I just got one FreeRunner and want to flash its system to latest. In > buildhost.openmoko.org, there are only u-boot image for gta01 and it > was built on Aug, 07. So I wanna ask where can I find u-boot binary > for gta02? Look in the "daily" directory of buildhost, e.g. http://buildhost.openmoko.org/daily/freerunner/200808/20080809/u-boot-gta02v5-1.3.1+gitr54+dc633f4be2527f844158aa5085c278b0c3039d3f-r0.bin You can look up the git hash in the filename at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable to see whether or not the buildhost image is up-to-date (in this case it is not, as there was a new checkin an hour ago). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008 WTF??
Scott wrote: > Booting up... Could it be any more confusing?? First the OM screen, > then the standard linux text scrolling, then the boots, then blank, then > the boots again, then some more text, then blank again??? WTF over? > Can't we have just one damn boot screen? The first one ("OM screen") lives in a dedicated flash partition and is loaded by u-boot. It could be updated by the opkg that is responsible for the other splash screen, in the same way that the kernel opkg will re-flash the kernel partition when it is updated. This might be a good project for one of the community members (hint, hint). It should be possible to hide the linux text scrolling - OpenSuSE (for example) does it, but I don't know the details. I personally like to see the penguin and the Linux messages. AFAIK the remaining issues are because the splash-screen starts out by using the raw framebuffer, and then later X11 is started. I don't know what room for improvement there is in this area - maybe someone else can comment. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Om 2008.8 Release
Noah Romer wrote: > William Lai wrote, On 08/08/08 04:03: >> http://downloads.openmoko.org/releases/Om2008.8/Om2008.8.uImage.bin > > Is this not the u-boot image? I thought it was and tried to flash it > using `dfu-util -a u-boot -R -D Om2008.8.uImage.bin`, but that failed "uImage" is the kernel. You will need to re-flash a u-boot image to the u-boot partition. Try this one: http://buildhost.openmoko.org/daily/freerunner/200808/20080808/u-boot-gta02v5-1.3.1+gitr50+dc633f4be2527f844158aa5085c278b0c3039d3f-r0.bin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: any update on GSM interference issue
arne anka wrote: >> PLEASE NOTE: I'm going to move this thread to [hardware]-ml and join it >> with >> another thread of same topic from [support], in a few hours. > > then i won't read it anymore -- i am already subscribed to community and > support and it's almost more than i can read ... The hardware list has much less traffic than the community and support ones. You can also access the list through NNTP (Newsgroups) from http://dir.gmane.org/gmane.comp.handhelds.openmoko.hardware , or read the archive at http://lists.openmoko.org/pipermail/hardware/ , if you do not want to subscribe directly. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: wrong offset of mouse in landscape mode (and scummvm)
Dale Maggee wrote: > /bin/sh: /usr/bin/scummvm: not found > > which is very odd, because I can type "/usr/bin/scum[TAB]", and it > autocompletes to scummvm. the file is marked as executable. I can't see > anything wrong. > > does anyone have any Ideas? For binaries this may indicate an OABI/EABI issue. There are different binary formats for ARM; Openmoko now uses EABI but binaries built for other platforms may be OABI. If you have binutils you can run "readelf -l " and look for the "Requesting program interpreter:" line. If it's a shell script, then it may be a similar problem with the command interpreter, e.g. if the script's first line is "#!/bin/bash" but you do not have /bin/bash installed. p.s. I just checked the wiki page that was mentioned up-thread, and it looks like it's pointing to an old package from the "2007.1" days when Openmoko was using OABI binaries. There's a bitbake recipe for scummvm in OE so it should be easy to build an updated package if there's not one already available in the feeds. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firmware Re: IMEI
Learning It wrote: > What about reverce engineering? I saw that some ppl were doing their mobile > phones. It means somewhere exists such information. I wouldn't bother trying to reverse-engineer the GSM firmware itself. The technical and legal barriers are too high for this to be a practical approach. Just accept that it is a black box, like the hard drive in your PC. However, it would be useful to talk about "reverse-engineering" and documenting the AT command set through which the GSM chipset is accessed. Much of it is standard, but there are some proprietary commands. It would be very useful if we could find (for example) commands to control echo suppression/cancellation in the Calypso chipset. These wiki pages are a good starting point: http://wiki.openmoko.org/wiki/Hardware:AT_Commands http://wiki.openmoko.org/wiki/GTA01_and_GTA02_gsm_modem ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS application (was: Request for help: Would like community applications to show anddiscuss at LinuxWorld)
Ken Restivo wrote: > What is the point of having GPS anyway? One reason for GPS on a phone is to provide location information for "Enhanced 911" emergency services. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re:
Lynn Nguyen wrote: > I'm using the neo1973, so I don't think it has nand? Neo1973 and Freerunner both have NAND. Only Freerunner has NOR. > I tried using the debug board but I can't get openocd.cfg to work. It > complains about missing ftd.h. even though i followed EXACTLY all the > steps here: http://svn.openmoko.org/developers/werner/notes/openocd Try this page: http://wiki.openmoko.org/wiki/Neo1973_Debug_Board_v2/Unbricking ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner not charging?
Marcel "MadJo" de Jong wrote: > Uboot is: > (u-boot-gta02v5-1.3.1+svnr4297+gitb29661fc115106454288051bc9a488351ce8-r3.bin) That's old (even if it was built recently, it used the SVN patchset rather than the OM "u-boot.git" tree). Try this one: http://buildhost.openmoko.org/daily/freerunner/200807/20080730/u-boot-gta02v5-1.3.1+gitr6+ba029a1426bfca169572bf80d50a8b190a6b0e19-r0.bin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: uboot versions or a changelog?
William Kenworthy wrote: > Is there a list of uboot versions or a changelog? I would like to see > what changes have been done from that shipped with 2007.2? See http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable and the archives for the openmoko-kernel mailing list. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problem booting to NOR?
Steve Leung wrote: > http://docs.openmoko.org/trac/ticket/1568 > > I'm just not sure what I can do about it - I haven't got a debug board, > and I wasn't really planning on buying one. You could ask if there's anyone living near you who could lend you a debug board or do the flashing for you. If not, wait for an official Openmoko statement of how to repair/replace your phone. > This morning, it occurred to me that I might be able to throw in an SD > card to boot off of, which would allow me to flash NAND, but without a > safety net of NOR flash to use, I'll have to proceed carefully. A Freerunner without a working NOR flash is basically the same as a Neo1973. It's safe to flash a new kernel or rootfs partition; the risk of bricking the device is only if you update u-boot itself. You do not need an SD card as you suggested above. Flashing is done while you are in the u-boot menu, before you have loaded a kernel or rootfs. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: update to quickstart user guide adds "known issue" section
Michael Shiloh wrote: > Most importantly, the addition of a "known issues" section: > http://quickstart.openmoko.org/#knownissues [...] > (Duplication is evil because it almost guarantees that one is wrong, or > at the very least confuses the newcomer.) Note that there is a similar page on the wiki at http://wiki.openmoko.org/wiki/Freerunner_Hardware_Issues ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS, VMWare and question about bluetooth headset
Johan Badenhorst wrote: > At the moment > that is a bit tricky because of the echo and interference when making > phone calls, but I believe that these issues aren't insurmountable. The > reason I got an open phone is because when issues like these creep up I > have the option of getting in there and trying to sort it out myself. > > It is with that in mind that I will be installing XOScope to do some > tests of my own. > > Questions: > > 1. In ticket 1267 the following statement is made: > > /"With a few mixer tweaks it is possible to send a 1 kHz PCM tone out > through the call speaker"/ > > Can someone ellaborate on what these tweaks are? You may be able to use the "/usr/share/openmoko/scenarios/voip-handset.state" profile. Otherwise, it's a matter of studying the WM8753 diagram as shown on the "Neo1973 Audio Subsystem" wiki page and setting the appropriate mixer controls to route PCM audio to the speaker and to route the mic2 audio into the ADC. Note that the Freerunner has different audio wiring (and a different amplifier chip) than the Neo1973, but I don't think there's a dedicated wiki page for it yet. In addition to xoscope I have been using the 'jaaa' spectrum analyzer from http://www.kokkinizita.net/linuxaudio/ (which includes a sine-wave or noise generator). There's a bitbake recipe for it in the org.openmoko.dev branch of the Openmoko git repository. > 2. a) A bluetooth headset is mentioned as a possible workaround, has > anyone tested this, I've tried but failed to get a Plantronics 220 to work. One person on IRC said that he had managed to get headset audio to work, but I don't know any other details. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Updates
arne anka wrote: > >> Should I think of u-boot as the OpenMoko version of Grub? > > kinda. and some kind of bios, maybe. That's correct - u-boot is responsible for initializing the hardware (like a PC BIOS) as well as for loading and booting the kernel (like Grub). >> In which >> case why can't opkg update this? It should be possible to update it from Linux. The flash partitions are exposed as /dev/mtd* devices, and the kernel package updates its corresponding flash partition when installed. In the past there was a bug that interfered with writing to flash from Linux, and it was very risky to touch the u-boot partition because a mistake could leave you with a bricked device. Neither of these is a concern for the Freerunner, so it should be possible for someone to put an 'opkg' wrapper around u-boot. This wrapper would have to flash the correct u-boot for the revision level of the hardware (e.g. GTA02v4 vs. GTA02v5). >> Does flashing the root filesystem wipe out /home? > > yepp. that's a big disadvantage imho. Workaround: move /home to the SD card and then create a /home symlink on the root filesystem. Or just update your software with "opkg" rather than re-flashing the whole rootfs. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia Speakerphone
Joerg Reisenweber wrote: > There's some AT-command to send to modem > to stop sidetone path in modem. Mickey knows more on this. [EMAIL PROTECTED]"-26" Reference: http://wiki.openmoko.org/wiki/GTA01_gsm_modem ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SanDisk micro SDHC 8GB card under testing
ian douglas wrote: > and once on the unit's own Flash ROM as a comparison: > [EMAIL PROTECTED]:/media/card# cd /opt > [EMAIL PROTECTED]:/var/volatile/opt# /opt/iospeed2 testfile 50 > Size (MiB)Write (MiB/s) Read (MiB/s) > 501.577 9.530 Oh, another factor to consider is filesystem compression. I wonder if these are "real" I/O speeds or if jffs2 is squishing the test file down to a smaller number of blocks. I guess I should re-write my utility to fill its buffer with uncompressible pseudo-random data. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SanDisk micro SDHC 8GB card under testing
ian douglas wrote: > ian douglas wrote: > Mike, your binary is 420kb ... I'm guessing that you compiled your code > with the cross-compiler toolchain? Probably, but it was a while ago and I don't remember where I built it (I have a MokoMakefile cross-compile environment and a native toolchain on the Neo). Anyway, a natively-compiled version should be fine. > I moved the iospeed files to /opt/ so I could compare against the 512MB > card that shipped with the Freerunner, and ran Mike's utility three > times on the 8GB SDHC card: > [...] > [EMAIL PROTECTED]:/media/card# /opt/iospeed2 testfile 100 > Size (MiB)Write (MiB/s) Read (MiB/s) > 100 1.557 9.396 > > and once on the unit's own Flash ROM as a comparison: > [EMAIL PROTECTED]:/media/card# cd /opt > [EMAIL PROTECTED]:/var/volatile/opt# /opt/iospeed2 testfile 50 > Size (MiB)Write (MiB/s) Read (MiB/s) > 501.577 9.530 Those numbers are very similar, and given the numbers that you posted in your later email I would guess that the 8G card was not actually mounted for this test run. > Then tested /tmp which I guess is a RAM drive considering the speed boost: > > [EMAIL PROTECTED]:/media/card# cd /tmp > [EMAIL PROTECTED]:/var/volatile/tmp# /opt/iospeed2 testfile 50 > Size (MiB)Write (MiB/s) Read (MiB/s) > 5028.617 42.786 Yes, /var/volatile is a 'tmpfs' filesystem. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SanDisk micro SDHC 8GB card under testing
Federico Lorenzi wrote: > Makes sense, ext3 is journaled, and using a journaling FS on flash > memory is generally a bad idea. Could you also try ext2? By default ext3 only journals metadata, so it shouldn't have much performance impact for large files. SD cards are dirt-cheap these days, so I'm willing to accept a somewhat reduced lifespan in order to get the journaling feature of ext3. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SanDisk micro SDHC 8GB card under testing
ian douglas wrote: > Hey all, > > Got my 8GB SanDisk 8GB micro SDHC card [1] in a few minutes ago, popped > it into my GTA02v5 (beta tester model) Freerunner and running a few > tests on it. So far, so good. Cool. If you have time, can you post some performance numbers for it? http://members.shaw.ca/mmontour/neo/iospeed is a simple performance-test program that I wrote (source is "iospeed.c" in the same directory), or you could use something standard like "bonnie++". For my "iospeed", give it a path to the file it should create and a size in MiB, e.g. "iospeed /media/card/junk.dat 128". ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Slashdot post but no web store?
Jisakiel wrote: > - I understand the only problem precluding it as a DAP player is the > speaker not muting? Or *with headphones* it is mono? I understood GTA02 > to have a single speaker but to be stereo capable with headphones... I'd > be devastated if wrong, or if other severe quality issues existed (such > as perhaps a noisy codec, or an insufficient sampling frequency, or who > knows); the problem reported on the ticket sounds at least as "doable", > without knowing anything else. As I understand it the main problem is that a capacitor in series with the headphone output is too small, which means that low-frequency audio is cut off (the capacitor + the resistance of the headphones forms a high-pass filter). This is consistent with Kevin's observation that it sounded OK when connected to an Aux on another amplifier, because the resistance of that input is much higher than that of headphones. I don't know the actual cutoff frequency or how it compares to other products on the market. Also, I don't have a Freerunner so I'm just basing this on what I've read on the lists. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Convert Freerunner CAD Files - IGES or STEP?
Christmann, Hans C wrote: > I have access to Pro/E and am willing to convert the Wildfire 3 files > into something else. What do you prefer? IGES (Wireframe or Solid?), or > STEP (Wireframe or Solid?)? I don't have any need for the CAD files myself, but yesterday someone on IRC was looking for an open-source program that could view them. Blender apparently has the ability to import .slp files from Pro/E, so it might be nice to have that in addition to IGES or STEP. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Using gmane with openmoko mailing lists + thunderbird
Ben Burdette wrote: > I can't seem to figure out how to reply to messages using this interface > though. I was able to do it to the gmane.test 'newsgroup' (list?). > However, it doesn't really work for the openmoko lists. Anyone had > success with this? The first time that you post a message to a group, gmane sends you an email to confirm that your From: address is valid. You have to reply to that before your original message will be posted. If you don't see this message, check your junk-mail folder. You may also have to wait a couple of hours for posts to show up. I don't know if that delay is on the gmane side or if it's the Openmoko mailserver. (posted through gmane) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why not use forum?
Leonti Bielski wrote: > Personally I don't like mailing list because it's not that comfortable > and I can see no advatages of using mailing list instead of forum? I prefer to access the lists through the NNTP gateway on gmane.org, e.g. http://dir.gmane.org/gmane.comp.handhelds.openmoko.community . ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5mm or 3.5mm
Joerg Reisenweber wrote: WAAH, they're NOT compatible to usual headphones which have tip1=L 2=R, (3)=4=GND. I can't guarantee the accuracy of that web page - it would be good to find someone with an iPhone who can make a direct measurement. In fact we already did and will follow / stay close to: Nokia AV-connector spec. That looks OK. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner test
Joerg Reisenweber wrote: http://wiki.openmoko.org/wiki/GTA01_gsm_modem#Serving_Cell_Information_.282.2C1.29 you read this field during a call when actually transmitting audio (NO silence)? I called the Neo from my other (non-GSM) phone and listened to that other phone. The Neo was transmitting some audio, although it was only its "GSM buzz" and an echo of the audio from the other phone. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner test
Kevin Dean wrote: I'd like to reconfirm this before reporting, or at least kill my theory before reporting on it and creating a false lead. It seems that the SIM itself is important. Two likely factors affecting GSM buzz are: which band it's using (850 or 1900), and the transmitted signal strength (how far it is from the tower). If you had SIMs from different carriers I could easily see these factors being different. I can't think of a reason that two SIMs from the same carrier would differ, except for randomness in which tower it happened to use. It looks like one of the 'Engineering Mode' AT commands can at least report which band you're on and the base-station ID. There is also a "transmit power" field listed, but when I tested it a minute ago it was always 0. http://wiki.openmoko.org/wiki/GTA01_gsm_modem#Serving_Cell_Information_.282.2C1.29 I have a cheap microwave-oven leakage tester from Radio Shack, and I was able to put that next to my Neo to get a relative indication of its transmit strength. I could hear the level of the buzz go down at the same time that the needle on the meter went down. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5mm or 3.5mm
Joerg Reisenweber wrote: your link: that's it Thanks for sharing your thoughts and giving this link If you do choose a 4-pin 3.5mm connector to be compatible with iPhone (or with another major vendor), please double-check that you use the same pin assignments. This forum post: http://discussions.apple.com/message.jspa?messageID=5262651 says that the iPhone plug uses: tip=R, ring1=L, ring2=Common, sleeve=Mic (which is not what I would have guessed). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner test
Kevin Dean wrote: Unscientific testing, yes. The echo is still there. :) s/)/(/ Can you please add a note about this to bug #1267? How bad was the echo - enough that a normal person would complain about it, or something that would only be noticed if they listened carefully? I'm getting annoying GSM buzz on the Freerunner when using certain SIM cards (I need to confirm this with more SIM cards). A note about this on bug #883 would also be good. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5mm or 3.5mm
Joerg Reisenweber wrote: http://www.meritline.com/earphone-adapter-iphone-into-3-5mm-mic-038.html This one is completely off topic. I'm talking about STEREO headSET(=with mic), which usually commes with 2.5mm. We are planning to use a 3.5mm 4-ring connector, that complies with usual 3-ring headPHONES(=w/o mic), and I didn't see an adapter 3.5/4wire-male->2.5-4w-receptacle yet. So you probably have to DIY, to use "standard" headSETs with future OM devices. But you get benefit of plug-and-play for classic "Walkman(R)"-headPHONES. I don't see how it's "completely off topic" as it's an example of a commercially-available adapter with a 4-ring 3.4mm plug (even if the other end of it isn't what's wanted). I understand the benefit of "plug-and-play" for regular headphones - that's why I voted for the 3.5mm option. However I also feel that it is important to have at least one commercially-available headset (or headset+adapter) that can be used without requiring DIY cable assembly. I don't have an iPhone, but it looks like it uses a 4-pin 3.5mm connector that is electrically compatible with regular 3-pin 3.5mm headphones (just mechanically recessed so that you have to buy "official" adapters). If that is the case, then OM might be able to use a non-recessed 4-bin receptacle with a compatible pinout. That way, any iPhone adapters or headsets could be used with the OM phone. BTW I did a bit more searching and found another adapter that may be closer to what you are looking for: http://www.mac-pro.com/iPhone-Handsfree-Stereo-Adapter-3-5mm-White_2 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5mm or 3.5mm
Joerg Reisenweber wrote: B) classic 3.5mm headphones "Walkman(R)" connector, where you have to DIY an adapter for any standard cellphone headset? (or does anybody know of 3.5mm headSET standards or adapters?) This one, but with a 4-pin (stereo+mic) format that's compatible with at least 1 major vendor (so that "DIY" means "buy an adapter from a web store" rather than "fire up the soldering iron"). See for example: http://www.meritline.com/earphone-adapter-iphone-into-3-5mm-mic-038.html Offtopic gripe - Bluetooth headsets are OK if they work, but so far I have been unable to get my GTA01 to talk to one (it pairs, but I can't get audio through it). I posted a query on device-owners and did not hear any other success stories. I hope that OM has done enough QA testing to guarantee that this is only a Linux software issue and that the Freerunner (at least) will eventually have full BT headset support. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: echo (was: ASU software - pre-pre-release impressions)
Crane, Matthew wrote: > I've noticed that with GSM calls in general there is sometimes an echo. It > can be very pronouced or barely noticable. It may be hw or sw, but it may > not have anything to do with either caller's phone. > > If it doesn't happen consistently and is not reproducable, it's likely the > network. IMHO. In some cases it might be from the network, if it was using a buggy or mis-calibrated echo-cancellation algorithm. However the Neo itself is also quite capable of generating an echo - some of the sound coming out of its speaker is picked up by its microphone, and is then encoded and sent back to the other caller. In my tests the echo went away when I muted the Neo's speaker or microphone, so it did not seem to be a network issue. The audio coupling between the Neo's speaker and microphone can be measured independently of the GSM stuff, e.g. with the 'Jaaa' audio analyzer from http://www.kokkinizita.net/linuxaudio/ or with 'xoscope'. Various ALSA mixer controls will affect the level of the coupled signal, but these also affect the intended sound paths (loudness of the speaker and sensitivity of the microphone). The mixer settings have to be selected to give the best compromise between these factors. I hope that the overall audio quality will be "good enough" once the mixer settings have been optimized, but I am not yet confident of this. Audio-quality reports from other Freerunner owners would be appreciated. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU software - pre-pre-release impressions
Ian Darwin wrote: I have been using a FreeRunner for a few days with a pre-pre-alpha snapshot of the ASU software. [...] Short form: functionally, it works. Among other things, the phone wakes up reliably on incoming rings (assuming it's booted and suspended, of course), and GSM voice works after a resume. Thanks for posting your review. Perhaps you (or another Freerunner user) can answer a few more questions: How good is the audio quality when having a GSM voice conversation with another person? Can the other caller hear you clearly without being distracted by an echo of their own voice (as happens on at least some GTA01s, mine included)? Is the Neo's speaker volume loud enough for you to hear the other caller in the presence of noise (e.g. outside on a sidewalk)? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alarmclock puzzle
Robin Paulson wrote: if we're designing alarm clocks for the neo, i'd love to see something like this implemented: http://www.soleilsunalarm.com/ it gradually turns on a bright light, to simulate the sun coming up. I have basically the same thing with a lamp plugged into an X10 dimmer module, controlled by a cronjob running on a PC. The computer interface is a small wireless dongle that plugs into a serial port. A bit of Googling suggests that Bluetooth-to-RS232 converters exist, so it might be possible to rig up an X10 controller on a Neo. And on the subject of alarm clocks, it should be possible to implement this one on the Freerunner: http://www.thinkgeek.com/stuff/41/snuznluz.shtml :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Need a Cellphone now...
Jeffrey Thomas wrote: [...] and I am to the point where I am considering unsubscribing from the mailing list because there is no real information being written about. I don't mind that, and I enjoy the conversation, but it fills my email box with distractions while I work :) I find it easier to read the lists through the gmane.org gateway, e.g. nntp://news.gmane.org/gmane.comp.handhelds.openmoko.community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Booting from SD
Ortwin Regel wrote: The problem might be your u-boot version. Try this one: http://buildhost.automated.it/u-boot-good-for-sd-boot-r13_0_2632_0.bin It's what I've been using successfully. I never could get it to work with other u-boot versions I tried. SD-booting in u-boot was broken for several months but as of late January it is fixed (or at least worked-around; the root cause of the bug has not yet been identified). The link you posted will boot from SD, but it has other bugs that have been fixed in later versions. Regarding the original problem, it is likely related to the 2.6.24 kernel. The GTA01 SD-card driver was broken for a while. My understanding is that it is now functional, but that it is still configured to emit a large amount of debugging information. Things should work fine with a 2.6.22.5 kernel as long as you have the corresponding modules installed on your root filesystem. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA01 Gllin ipkg
Dan Staley wrote: I recently got my GTA01 and am trying to get the gllin ipkg from http://3rdparty.downloads.openmoko.org/gllin/ . However, everytime I download it, it says it is corrupted. Some people had similar problems in the past - they would download a copy of the EULA rather than the package itself. You might try it with a different browser, and make sure that it's passing the Referer: header correctly. The above URL works for me. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
Wolfgang Spraul wrote: Next we discovered that those reflashing tools had further issues: for example, they would only allow loading cryptographically signed firmware into the chipset flash memory. I don't see why the cryptographic-signing requirement is a problem. Sure it would be nice if every peripheral was fully open-source and hackable, but that's just not realistic. If you're loading a proprietary blob anyway, who cares whether or not it has cryptographic authentication? Furthermore, we see that for upcoming chipsets, vendors are switching from storing the firmware in flash memory to loading the firmware into RAM at run time. IMHO that's a good thing as long as they allow reasonable redistribution of those firmware blobs (i.e. so that OM can include them in rootfs images). In this case the firmware, whether original or updated, has to be loaded each time the device boots, requiring that the binary-only, restrictively licensed firmware updater be included in the OpenMoko distribution. If the device is designed to load its firmware on every boot, then there's no reason that it should require a binary-only tool. It should just be part of that driver's API. I have a MythTV box with a Hauppauge PVR-350 MPEG encoder/decoder card. It has proprietary firmware that's loaded on boot, but no proprietary tools are required. I just have to put the binary blobs into /lib/firmware/ and Linux does the rest. See the "ivtv-firmware.c" file in the kernel for details of how it's done. He suggested we treat any chipset with proprietary firmware as a black-box, a circuit. He suggested we ignore the firmware inside. If the firmware is buggy and the vendor needs the ability to update the firmware, we instead ask the vendor to reduce the firmware to the bare minimum, so that it can be very simple and bug free, and move the rest of the logic into the GPL'ed driver running on the main CPU. Did he have any real-world examples of vendors who have been willing to implement such a request? It seems like it would be a large change on the vendor's side and would require a lot of additional development and QA resources. It might even require the hardware itself to be designed specifically for that that usage model, e.g. the Hammerhead GPS used in GTA01. Also, as others have commented, the main CPU is a finite resource. It's not surprising that this is not a concern for the GNU project (their flagship text editor was known as "Eight Megs And Constantly Swapping" back in the days when that was a lot of memory) but it is a concern for users/developers like me. There are downsides: We will no longer offer reflashing tools to update proprietary firmware, under any license. For critical firmware bugs, we will accept returns, or in some cases fix the bug in-house. I purchased one of the original GTA01s with a "-Moko1" GSM firmware. At some point I want to have this updated to a more recent and less buggy version, but I am not willing to mail the phone back to another country to get it re-flashed (unless OM will cover the shipping + customs costs both ways). I might be willing to take the phone in to a local authorized service center, but I would prefer to do the update myself (even if it required a proprietary tool). We will push vendors to simplify the functionality of their proprietary firmware, so we can implement more of this on the main CPU as Free Software. Maybe some vendors will even open up firmware for Free Software development, that would be the ideal outcome we are working towards. I think that's OK to push as a long-term vision, but in the short term I think that the best approach is cryptographically-signed blobs that the GPL driver loads into RAM through a set of API functions. That gives us the ease of updates (just copy new blobs into the firmware directory) and gives the vendors regulatory compliance (since only signed blobs will be accepted). It also encourages the model of having a GPL'd Linux driver talk to their device through a documented API, and may help to convince them to move more of the functionality onto the "GPL" side in the future. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: noise while making a phone call: hardware or software?
Michael Shiloh wrote: I've been searching for this item but all I can find is bug # 883, which says it's a hardware issue, interference making its way into the GSM audio path one way or another. Does anyone recall any software explanation for this? I've started to play around with the mixer settings, and it seems that they can be tuned to reduce both the GSM "buzz" and the echo heard on the remote end of the phone call. I don't yet have a set of "working" state files - the Neo's mixer is quite complicated, and I don't have access to the proper test equipment (tone generators, spectrum analyzers, etc). However, I've found that a good first start is to set to 0 the mixer controls of all of the unused components. There are some that are physically not connected (e.g. Amp Mono), and others that are unused in certain ALSA profiles (e.g. "Mono Voice" in the gsmhandset profile). I will eventually get around to creating a patch for this, but if someone else wants to do it first I won't complain. There is also a hardware side to this issue - if the hardware was really good at isolating the audio path from the radio signal, then there wouldn't be an interference problem in the first place. However I don't think it's reasonable to expect perfection. I can hear a GSM buzz similar to the Neo's when my friend calls me from a Motorola RAZR, and in general GSM seems to be much more interference-prone than my current CDMA phone. p.s. I'm using http://wiki.openmoko.org/wiki/Neo1973_audio_subsystem and its linked pages as my reference. Another TODO for somebody would be to annotate the codec block diagram with the ALSA names of the corresponding components. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update, January 2, 2008
Thank you for the update. When do you expect to have results from the 850-MHz GTA01 testing? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email App (why openmoko-apps not on gmane?)
Lars Hallberg wrote: >> http://lists.openmoko.org/pipermail/openmoko-apps/2007-November/000279.html > > Is there a reason this list and others like the owner list is *not* > available on gmane? Would be far easier to follow. It is there - gmane.comp.handhelds.openmoko.apps (as are all of the others). That's where I read the lists - I'm only directly subscribed to "announce" and "device-owners". ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update: GSM firmware and GPS driver
Shachar Shemesh wrote: Regarding the GPS, please pay attention to the fact that the GTA-02 did not "solve" this problem. It merely moved the non open source component from the software to the firmware. This solves the "supporting libraries" problem, but does not allow openness. It solved the problem of requiring closed software to run on the host CPU, which is the most important threshold. In my opinion it is unrealistic to expect a device like the Neo1973 to use completely "open" hardware. A serial-attached GPS module with closed-source firmware is no worse than the hard drive with closed-source firmware in everyone's desktop PC. http://gps.psas.pdx.edu/OpenGnssProjects/ has some good links to open GPS projects, but I don't know of any that would be suitable for a mobile phone. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: developing C/C++ applications for OpenMoko -- where do we stand?
[EMAIL PROTECTED] wrote: I agree. When I look at the wiki page on how to develop a simple 'Hello World' application I get very concerned .. am I missing something? Why is this process so complex? Is there an easier way? If so, where is this posted? http://wiki.openmoko.org/wiki/Application_Development_Crash_Course There's also this page, linked from the "Crash Course" one: http://wiki.openmoko.org/wiki/Building_a_hello_world_application It can be as easy as: ./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c (once you've built the cross-compile toolchain with MokoMakefile) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community Update
Michael Shiloh wrote: The next issue was technical, and resulted from the switch from OABI to EABI. That issue has a number of workarounds (wrapper, chroot), but unfortunately all these technical solutions raise another set of legal issues. I personally would be satisfied with the original "bare" OABI binary, i.e. one that I could run if I rolled back my rootfs to a 2007.1 image. I also don't need any of the "Assisted" GPS features yet (i.e. the orbit-prediction data from Global Locate); all I want is to be able to take my phone outside and get a position fix. Is there any chance of convincing your lawyers to let you release an "as-is" version of the binary under the same sort of "developers only, you have been warned" disclaimer that we had to accept when we purchased the GTA01 hardware? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community Update
Michael Shiloh wrote: To save time, please refrain from re-opening previous discussions. "Re-opening" implies that there has been some previous closure, vs. a discussion that just trailed off into silence. Could you please provide regular updates on important items that are still open, even if it's just to say "no progress since my last update"? You obviously don't have to cover every issue, but I think that a "top 5" list would be reasonable. For example: - Progress of the GTA02 hardware production and qualification (which I see you have updated on the Wiki) - Delivery of the promised 'gllin' GPS binary to GTA01 owners (anything that can be made to work, OABI/EABI/chrooted/whatever) - The apparent lack of 850 MHz GSM support in USA+Canada (e.g. comment 24 on bug #256) - Delivery of a GSM firmware update for the 3G SIM bug (#666) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Update from OpenMoko
Michael Shiloh wrote: GTA02: -- We are entering the last phases of finalizing the design. From this point forward there are three key milestones in the life of a hardware platform: Prototype runs; a pilot run; and mass production. We have made three prototype runs to test various subsystems. Our best case analysis of the schedule indicates that GTA02 will be ready for shipment to end users in early to mid December. Can you provide an update on the GPS situation for GTA02? The most recent information I had heard was that two different chipsets were being evaluated. Has the choice been made yet? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA01 now or GTA02 later
Federico Lorenzi wrote: 1) Will the GPS licensing _eventually_ be sorted out? I don't know anything about the status of the official driver, but I am optimistic that it will be possible to figure out enough of the Hammerhead protocol to develop an open-source driver with at least basic GPS functionality (see http://wiki.openmoko.org/wiki/Hammerhead/Protocol). 4) Which would YOU choose, a GTA01 now, or a GTA02 in 5 months? I'd choose "both" - I have a GTA01 now, but I'm planning to upgrade to a GTA02 when it's available (for the WiFi). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't flash smaller root-fs through dfu-util?
Dr. H. Nikolaus Schaller wrote: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs Many thanks for your suggestions, but MacOS X has no cu command :-( You can use "minicom" from the Darwin Ports collection. I've added a section on the Wiki: http://wiki.openmoko.org/wiki/MacOS_X#USB_Serial ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community