Re: USB host
Marcin Domanski wrote: Yep it shouldn't be a problem - let's take an usb hub with external power supply - connect it to neo and then connect the device to the hub. I dont know how's the support for it but its an idea :) That relies on the USB hub recognising a non-powered host. Many do not. (the first two I tested, a belkin tetrahub, and something else) On 8/12/07, Ian Stirling [EMAIL PROTECTED] wrote: assistivetechnology wrote: Did anyone ever try to use the USB host with power supply, or build a HW workaround to supply USB devices with power? I'm contemplating the latter. The kernel does not currently support USB host - it needs a patch. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Isn't this a little early?
I sent the following to [EMAIL PROTECTED] The domain freeopenmoko.com which is in your IP range is giving false information. The worst of it is that the testimonials claiming to have received a Neo 1973 phone were up on the website before the phone was even released. The website also does not say that the device is not a fully operational phone, it is a developer preview which is not suitable for daily use, which is why its less expensive than comparably specced models. The site should also say it is not affiliated with the openmoko project, the openmoko company or FIC. Please ask them to correct it or kindly take down their site. I'll post any follow up with them ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Linux embedded dev board
2007/8/13, Edwyn Stapel [EMAIL PROTECTED]: nice dev kit.. but the neo is $150,- cheaper though and looks like it has more supported with their openmoko framework. Edwyn ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: User Interface idea
2007/8/12, Derek Pressnall [EMAIL PROTECTED]: One of the things that I've found on most pda-phones/smartphones is that they make the phone capabilities feel like just another application. But when you want to use the device as a phone, it would be nice for the rest of the features to melt into the background. The Motorola A780 does this nicely; it is a pda-phone when the flip is opened, but with the flip closed it becomes a regular feature-phone. So, that gives me an idea for UI layout. First, have the interface support two virtual desktops, most likely via the window manager. The primary desktop (PDA desktop) would remain how OpenMoko has it currently laid out. The second desktop (PHONE desktop), however, should resemble the face of a normal phone. The bottom half (or two thirds, whatever) of the screen would have a permanent phone keypad displayed (the keypad app), includuding directional buttons and several special-purpose buttons (answer/disconnect, function-A, function-B, Menu, OK, etc.). Any application running in the Phone desktop would only be able to write to the window in the upper part of the screen, and they would receive their input through the keypad app runnin in the bottom. The keypad app could have an API so that apps can request that certain keys be re-labled when that app is in the forground, but other than that the keypad would always display a similar layout for any running app. This would enforce a consistant feel among the various apps. Now any app that wants to use the secondary Phone desktop would have to be specifically coded for it; I'm thinking that apps such as the Dialer would be running in the background, and have an active connection to the Phone desktop along with the PDA desktop. The list of apps that should have Phone desktop capabilities would include the Dialer, SMS/Email, Media player, Calculator. I'm in agreement with all what quoted above, and for obtain this I think that must be implemented at least three things: Multitouch screen, Tactile feedback via buzzer, and a good input method like these: http://wiki.openmoko.org/wiki/Wishlist:Text_Input#New_input_methods (for me finger splash could be very good). Substantially, IMHO the finger use of principal functions of the phone joined with a good text input interface is basically for the real usability of the terminal as a phone. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: User Interface idea
On 8/12/07, Derek Pressnall [EMAIL PROTECTED] wrote: snip I'm thinking that apps such as the Dialer would be running in the background, and have an active connection to the Phone desktop along with the PDA desktop. snip um, do realize that we are working on a resource constrained system, and probably will be for the forseeable future... I don't see this as TOO much of a problem, as long as those apps unload most of themselves from memory when they're not running, and they spend almost all of their time sleeping... but watch out for that. We'll have to see what people can come up with for this before I run this on my system -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: User Interface idea
On 14 Aug 2007, at 00:02, Jeff Andros wrote: um, do realize that we are working on a resource constrained system, and probably will be for the forseeable future... I don't see this as TOO much of a problem, as long as those apps unload most of themselves from memory when they're not running, and they spend almost all of their time sleeping... but watch out for that. We'll have to see what people can come up with for this before I run this on my system Exactly why the iPhone is very responsive and Windows Mobile phones aren't. Apple keeps things simple. You need not worry about getting lost in applications if you have a button hardwired to the home screen. Windows Mobile has this on the smartphone edition, trouble is it's very fiddly to get back into any application you've come out of. Being able to see a list of what is open and being able to switch to them is important for usability. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: User Interface idea
On 8/13/07, Jeff Andros [EMAIL PROTECTED] wrote: um, do realize that we are working on a resource constrained system, and probably will be for the forseeable future... I don't see this as TOO much of a problem, as long as those apps unload most of themselves from memory when they're not running, and they spend almost all of their time sleeping... but watch out for that. What I meant was that apps that would be in use would be split into a piece that runs in the background, and a forground part that talks to the display / input. And the background part would only be running when needed. Now the phone app would always have a module running since it has to listen for incomming phone calls. The UI portion of the phone app that uses the phone desktop would be the default / primary app that is always available on it when nothing else is running (so that when you switch to the phone desktop, you can start dialing out without having to launch a phone app). This UI would be smaller than the pda-desktop version of the phone UI, since it doesn't have to worry about drawing input buttons, etc; it talks to the already running keypad app taking up the bottom half of the phone-desktop display. However the UI frontend that is used from the pda-desktop side would have a bit more code since it is responsible for it's own keypad, and possibly takes care of more display items. The Media player app could have a background piece that only run when it is in use. Again, it doesn't have any user interface components, only an API for a frontend to talk to it. The user can still exit the app for both the frontend and backend to exit memory, but it will go into pause mode if a higher priority app (such as the phone app) needs a shared resource (the speaker). This way, only the modules that are needed to be in memory are taking up ram, and launching the (small) frontends seperately / in parallel can give a snappier performance feel. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: User Interface idea
On 14 Aug 2007, at 00:48, Derek Pressnall wrote: What I meant was that apps that would be in use would be split into a piece that runs in the background, and a forground part that talks to the display / input. And the background part would only be running when needed. It's sorta done like that already, we have GUI applications and runtime libraries. Now the phone app would always have a module running since it has to listen for incomming phone calls. gsmd handles the calls, there's a library too. The UI portion of the phone app that uses the phone desktop would be the default / primary app that is always available on it when nothing else is running Sounds like you use the phone a lot? while that's right for you, other people use messaging or PDA functions more. You might find additional clicks to launch a dialer annoying, if you make dialer default someone else may think multiple clicks to browse their files annoying. Lets not hardcode any form of functionality into the device, let people choose. Having a default desktop handler or a homescreen which can display plugins is the way to go about it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Linux embedded dev board
On Monday 13 August 2007 22:22:24 Joe Friedrichsen wrote: It has more than a handful of similarities with the Neo (ARM9, touchscreen, USB, JTAG, but no GSM or GPS), and may help scratch some itches for new ideas and toys that have been floating on the list for It's more of a PDA spec, if you can live without the screen, roughly the same spec can be had with a NSLU2 for well under 200$. If you add in a cheap GSM module via the serial port, that would be the poor mans Neo1973 (possibly could be even made to work with OpenMoko). But since it's not exactly pocket sized and needs HW hack to be battery powered it's not really much of a competition for the Neo :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Login Manager
On 8/10/07, t3st3r [EMAIL PROTECTED] wrote: snip I see no effective way to combine these 2 different goals.One is prevents access to data but this will enforce bad guys to do full reflashing.Killing your (unusable) data but getting working (usable) phone.Another approach makes guys to believe phone is not defends itself and not secured.While it really silently tracks evildoers. /snip simple... display contact info(email, friend's phone number, etc) to return the phone at the login screen... I think my old(~2000 ish) WM PDA had an option to do that... people can't get into the phone itself, but they can figure out how to get ahold of you -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Chinese input for OpenMoko
On 8/8/07, Shu Hung (Koala) [EMAIL PROTECTED] wrote: Hello, OpenMoko is developed and produced in Taiwan. And I live in HK. Both places uses Chinese as the common language. I'm just curious if there is any plan for Neo1973 to support Chinese input? If so, in what way? Hand-writing input? Or keyboard input method? Koala Yeung ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community If you look real closely at the input panel, it shows a chinese mode input... it doesn't work yet, but I'd guess it's planned -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Debug Board JTAG Programming with openocd
I have been unable to coerce my Neo to charge batteries, so I have a feeling it has to do with the uboot image I flashed. Should I manually charge the batteries some other way? or continue trying to reflash the original uboot revision? (Can you even use the debug board if the battery is dead?) My current uboot revision: u-boot-gta01bv4-r11_e80955f07de03fef0196353e77534b2300193c1c_0_2348.bin What I am trying to do right now is get up and running with openocd, but I cannot get around this one error: # openocd -f /etc/openocd/openocd.cfg Info:openocd.c:84 main(): Open On-Chip Debugger (2007-01-31 12:00 CET) Error: jtag.c:1181 jtag_examine_chain(): JTAG communication failure, check connection, JTAG interface, target power etc. I know this means that it has found the debug board, but I am unsure what I should do to initialize the phone. (Simple as power?) I have my Neo wired up to the debug board, (2.7v) dead battery inside. Here are the steps I used to get where I am on Debian Etch: - moved 099_neo1973_debugboard.rules to /etc/udev/rules.d compiled/installed libusb-0.1.12 compiled/installed libftdi-0.10 add file usr-lib.conf to /etc/ld.so.conf.d/ insert line /usr/local/lib run ldconfig compiled/installed openocd from svn: svn co -r 137 http://svn.berlios.de/svnroot/repos/openocd/trunk openocd_137 ./bootstrap ./configure --enable-parport_ppdev --enable-ft2232_libftdi make; su; make install made /etc/openocd/openocd.cfg with: telnet_port gdb_port interface ft2232 jtag_speed 0 ft2232_vid_pid 0x1457 0x5118 ft2232_layout jtagkey reset_config trst_and_srst jtag_device 4 0x1 0xf 0xe daemon_startup attach target arm920t little reset_run 0 arm920t working_area 0 0x20 0x4000 backup run_and_halt_time 0 5000 ft2232_device_desc Debug Board for Neo1973 - Some information I grabbed from here: http://wiki.openmoko.org/wiki/Debug_Board http://wiki.openmoko.org/wiki/OpenOCD#OpenOCD_and_Debug_Board http://svn.openmoko.org/developers/werner/notes/openocd Thanks, Kyle ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debug Board JTAG Programming with openocd
-Update: I guess the debug board charges the batteries, because I checked the voltage after typing the previous email and it's ~3.29v. I still cannot get the Neo to turn on though... -Kyle On 8/14/07, Kyle Bassett [EMAIL PROTECTED] wrote: I have been unable to coerce my Neo to charge batteries, so I have a feeling it has to do with the uboot image I flashed. Should I manually charge the batteries some other way? or continue trying to reflash the original uboot revision? (Can you even use the debug board if the battery is dead?) My current uboot revision: u-boot-gta01bv4-r11_e80955f07de03fef0196353e77534b2300193c1c_0_2348.bin What I am trying to do right now is get up and running with openocd, but I cannot get around this one error: # openocd -f /etc/openocd/openocd.cfg Info:openocd.c:84 main(): Open On-Chip Debugger (2007-01-31 12:00 CET) Error: jtag.c:1181 jtag_examine_chain(): JTAG communication failure, check connection, JTAG interface, target power etc. I know this means that it has found the debug board, but I am unsure what I should do to initialize the phone. (Simple as power?) I have my Neo wired up to the debug board, (2.7v) dead battery inside. Here are the steps I used to get where I am on Debian Etch: - moved 099_neo1973_debugboard.rules to /etc/udev/rules.d compiled/installed libusb-0.1.12 compiled/installed libftdi-0.10 add file usr-lib.conf to /etc/ld.so.conf.d/ insert line /usr/local/lib run ldconfig compiled/installed openocd from svn: svn co -r 137 http://svn.berlios.de/svnroot/repos/openocd/trunkopenocd_137 ./bootstrap ./configure --enable-parport_ppdev --enable-ft2232_libftdi make; su; make install made /etc/openocd/openocd.cfg with: telnet_port gdb_port interface ft2232 jtag_speed 0 ft2232_vid_pid 0x1457 0x5118 ft2232_layout jtagkey reset_config trst_and_srst jtag_device 4 0x1 0xf 0xe daemon_startup attach target arm920t little reset_run 0 arm920t working_area 0 0x20 0x4000 backup run_and_halt_time 0 5000 ft2232_device_desc Debug Board for Neo1973 - Some information I grabbed from here: http://wiki.openmoko.org/wiki/Debug_Board http://wiki.openmoko.org/wiki/OpenOCD#OpenOCD_and_Debug_Board http://svn.openmoko.org/developers/werner/notes/openocd Thanks, Kyle ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
