Re: proprietary firmware
On Friday February 15 2008 13:54:27 Brandon Kruse wrote: > In that case it is not an open phone or platform. It is well worth the > investigation to go fully open somehow IMO. > > But I guess we could be like olpc and have a MOSTLY open platform > (wifi chip is not, as you could have guessed) > Basically what I thought was: a customer buys a phone with whatever firmware is in it and what ever mechanism the OS uses to upload it to the hardware on startup if necessary; if a customer wants to update/upgrade firmware then one has to download a binary update app (say from OM website) and the firmware update itself (from OM or a hardware vendor). Then install the app, the firmware and be happy about new features/speed and the fact that there is a (small) binary module on his/her system he/she knows nothing about. Alternatively, one can send the phone to OM and request an firmware update; Alternatively, one can refuse to put anything non-FOSS on the phone and live happily with (presumably buggy/malfunctioning) existing firmware and try to fix any problems the FOSS-way. I do not think OM can achieve *completely* (=absolutely) open OS with any sensible effort. Let's be realistic. What OM/community needs to decide is the degree (or ratio) of open to non-open soft. I would not even demand a certain, community decided API from firmware vendors -- just that they *open* whatever API they have. The greatest problem for community to produce software is not that some API has changed: it's when API is not available in the first place. So, let's get the functioning hardware in our hands -- there is plenty of things to do beyond firmware updates. M. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
joerg ??: Am Fr 15. Februar 2008 schrieb Brandon Kruse: In that case it is not an open phone or platform. It's a philosophical question, where "open" has it's limits. E.g. you probably consider a plain vanilla x86 GNU/linux desktop system to be pretty much "true open". However i guess you have no idea at all of the firmware that's managing your harddisk in this system. That's for a simple reason: IDE interface is age old (and so all HD's (SATA, SCSII) inherited this way we are looking at these devices), it is "just working", and it's well documented. Virtually nobody cares about the firmware behind this interface, mainly because it doesn't have a chance to stop you from doing anything you like on the _main_system_. I'm almost certain there's a hacker somewhere out there, who likes to mod his HD so the head motors will produce funny sounds, and another one thinks he can tune transfer rates even another 10k/s. However i never seen FOSS HD firmware. When things down to that low level, it's not only firmware issue. It also about chip selection for specific design. For example, every HD has some write cache mechanism in firmware, but some of read/wirte acceleron also chipset related, some chip vender's read/write cache command for SDRAM just faster and stable than others. And you will need these details specification to do the hardware ans firmware design. Chip selection also is the balance of performance/usability/price/marketing, especially for mass production products like hard disk, user won't even notice the changes on chips and cause of change chips. And transfer rate is a myth: means write into cache/or write on the disk and then verified it write correct. It has some many detais for a single bit from keyboard to your hard disk. If anyone could get 10% transfer faster algorithm for any hard disk, no vendor would refuse it :) It is well worth the investigation to go fully open somehow IMO. Sure. But it's a silly idea to try and force the subsystem manufacturers by refusing to support their closed source firmware updates. When Seagate comes with a DOS-only firmware updater to add some cool new features to their drives, OM says "No, it's not FOSS!". Seagate (or here, the chip fabs) don't care. But OM deprives NEO owners of any means to have a new firmware for these subsystems. If a user doesn't like to have closed source on his device, she is free delete or not install it. But OM will not achieve anything by refusing to provide closed source drivers. I think all they get is a huge number of returns, or less sales (at least for me). And OM(!) isn't willing or able to provide circuit diagrams, so any open drivers are extremely hard to develop. In my opinion they can't do both, refuse to support closed source updates *and* keep the hw specs closed. Not if they care about their customers. Not to mention, NEO will not be "open" at all as long as the hardware is a 'big mystery'. A laugh to start with closed firmware topic. Most function on GTA was exist in module format, and do a lot negotiation with vendor to open their document or firmware update utility. It is not OM say: We want this open. Then the vendor say: no problem, just open it. Usually comes with the answer that: Well, we need to ask our legal department first, and what's the quantities you want to buy. I think if we could buy their whole company, the openness should not be an issue anyway. But before that happens, we have to through long negotiation for each of the components for better hardware openness. I think GTA is not as complex as ps3 or close hardware as Aphone, you could almost ask any question in the kernel development mailing list for the details for hardware related except ask for full schematics directly :) I could not speak for OM, but open anything we did is the target, also the times we spent to talk with vendors, and we will keep persuade hardware vendor/industries anyway :) But I guess we could be like olpc and have a MOSTLY open platform (wifi chip is not, as you could have guessed) I'd like it more to see OM pushing manufacturers to provide a guaranteed API, which is specified by community, and not to care about _how_ the mfactrs achieve to fulfill this contract. Than to nag manufacturers to open the sources of firmware, "because we can do better, and do not want to use what we paid for". Maybe you imply a open standard for each hardware module access here :) Tony Tu ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't power on my neo1973
Ian, There is a good possibility that your neo is in deep discharge. Plug it into the USB port and let it charge a couple hours, then try and boot it, dont press the power before at least an hour, if you have pressed the power button, remove the battery for 5 seconds and replace it, charge at least an hour before booting up. If this is not the problem I do not know. >>> "ian chu" <[EMAIL PROTECTED]> 02/15/08 11:10 PM >>> hello~ I have the problem that sometimes I can not power on my neo1973. I use the usb to charge it, but it seems no response that I could not make sure the charging works. Even after usb-charging about 20 mins, sometimes I still can not power on it. Is it broken? what problem does my openmoko have? thx Ian ___ 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
Can't power on my neo1973
hello~ I have the problem that sometimes I can not power on my neo1973. I use the usb to charge it, but it seems no response that I could not make sure the charging works. Even after usb-charging about 20 mins, sometimes I still can not power on it. Is it broken? what problem does my openmoko have? thx Ian ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Second hand neo page
There is already a page for people interested in purchasing a second hand Neo. Maybe this could be used. http://wiki.openmoko.org/wiki/Interested_in_second_hand_neo I managed to get a Neo advanced kit ( to unbrick my neo- could not find anyone with a debug board in India)at a reasonable price ($ 350 inc shipping) after listing on this page. Rakshat From: Michael Shiloh <[EMAIL PROTECTED]> > To: List for OpenMoko community discussion > Date: Fri, 15 Feb 2008 14:16:58 -0800 > Subject: Request for assistance: Need a wiki page for buying and selling > GTA01 > Hi Community, > > I need your help. > > Having completely sold out of GTA01, we are still getting a large number > of requests for them. > > On the other hand, many of you intend to purchase a GTA02 and perhaps > feel you have no use for your GTA01. > > Some of you might have other reasons to sell your GTA01. > > I'd like a wiki page to allow these buyers and sellers to find each other. > > We have a wiki page for GTA01 owners who lived in 850 MHz-only areas to > sell their units; perhaps this page can be repurposed for this broader > issue. > > Perhaps we call this the OpenMoko flea market. > > Anyone? > > Michael > > > > > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
PS3 Logitech Wireless Keyboard and Moko
I bought a PS3 wireless keyboard, this BTKB has a mouse pad and buttons, its a full qwerty keyboard. This Works Great with the GTA01, the mouse pad even works, only issue is that it has a timeout that causes moko to disconnect , which i will fix with a script. just thought I would let everyone know --KrisAbsinthe on irc ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Request for assistance: Need a wiki page for buying and selling GTA01
I run a website (Frimp.net) that lets people post & search for things to sell. The branding is not exactly attractive for a technical audience, but it does let you specify your zipcode so people can find items for sale near one another. It is, of course, all free to use. So sellers could create an account on Frimp.net (I don't collect any personally identifying information, except your email address, which I need to forward purchase requests) and list their neo. I recommend putting the word neo1973 in the item title. Buyers can search for neo1973 and their zipcode to find sellers near them. The site is targeted at US sellers, but other sellers could enter a zipcode of 6 to sign up. I know it's a kludge for non-US sellers, but it would at least let US sellers find each other, and it's certainly easier to use than a wiki page whether the seller is in the US or not. If someone wanted to put together the CSS and images, I could create a site running on frimp.net code that looks more neo-ish. Bobby aka wurp2 Subject: Request for assistance: Need a wiki page for buying and selling > GTA01 > Hi Community, > > I need your help. > > Having completely sold out of GTA01, we are still getting a large number > of requests for them. > > On the other hand, many of you intend to purchase a GTA02 and perhaps > feel you have no use for your GTA01. > > Some of you might have other reasons to sell your GTA01. > > I'd like a wiki page to allow these buyers and sellers to find each other. > > We have a wiki page for GTA01 owners who lived in 850 MHz-only areas to > sell their units; perhaps this page can be repurposed for this broader > issue. > > Perhaps we call this the OpenMoko flea market. > > Anyone? > > Michael > > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Unable to find repository location
Hi, I am trying to build openmoko using the MokoMakefile I get that error: svn: Unable to find repository location for 'http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/config' in revision 3801 So I tried : svn co -r 3801 http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/config config and it fails. Any ideas? Also I would like to know how/where to specify the revision to use. I tried changing the OPENMOKO_SVN_REV variable in the Makefile but no luck. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
On Feb 15, 2008, at 3:49 PM, joerg <[EMAIL PROTECTED]> wrote: Am Fr 15. Februar 2008 schrieb Brandon Kruse: In that case it is not an open phone or platform. It's a philosophical question, where "open" has it's limits. E.g. you probably consider a plain vanilla x86 GNU/linux desktop system to be pretty much "true open". However i guess you have no idea at all of the firmware that's managing your harddisk in this system. That's for a simple reason: IDE interface is age old (and so all HD's (SATA, SCSII) inherited this way we are looking at these devices), it is "just working", and it's well documented. Virtually nobody cares about the firmware behind this interface, mainly because it doesn't have a chance to stop you from doing anything you like on the _main_system_. I'm almost certain there's a hacker somewhere out there, who likes to mod his HD so the head motors will produce funny sounds, and another one thinks he can tune transfer rates even another 10k/s. However i never seen FOSS HD firmware. Point taken. My opinion is versus things that COULD change and things that will never change, good point though. It is well worth the investigation to go fully open somehow IMO. Sure. But it's a silly idea to try and force the subsystem manufacturers by refusing to support their closed source firmware updates. When Seagate comes with a DOS-only firmware updater to add some cool new features to their drives, OM says "No, it's not FOSS!". Seagate (or here, the chip fabs) don't care. But OM deprives NEO owners of any means to have a new firmware for these subsystems. If a user doesn't like to have closed source on his device, she is free delete or not install it. But OM will not achieve anything by refusing to provide closed source drivers. I think all they get is a huge number of returns, or less sales (at least for me). And OM(!) isn't willing or able to provide circuit diagrams, so any open drivers are extremely hard to develop. In my opinion they can't do both, refuse to support closed source updates *and* keep the hw specs closed. Not if they care about their customers. Not to mention, NEO will not be "open" at all as long as the hardware is a 'big mystery'. A laugh to start with closed firmware topic. Also agreed. I would love an API decided by the community, not sure that would ever work but would be great. Point above, stallman uses an OLPC (open hardware) and for the things that are availinle as open (orinoco wireless) he has the on board wireless disabled. If there is no way to open what we want, our option is to sit and die in wait of such, or move on with an API decided by us (which pooint you made and I agree, would be great) But I guess we could be like olpc and have a MOSTLY open platform (wifi chip is not, as you could have guessed) I'd like it more to see OM pushing manufacturers to provide a guaranteed API, which is specified by community, and not to care about _how_ the mfactrs achieve to fulfill this contract. Than to nag manufacturers to open the sources of firmware, "because we can do better, and do not want to use what we paid for". jOERG ___ 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: Request for assistance: Need a wiki page for buying and selling GTA01
I am down, and do not think anyone will abuse this here. I am worried that scams might go on and how to protect this (escrow is a good option) With that regard, it would be great for people that have 01's to put that cash towards an 02. Brandon Kruse (bkruse) On Feb 15, 2008, at 4:16 PM, Michael Shiloh <[EMAIL PROTECTED]> wrote: Hi Community, I need your help. Having completely sold out of GTA01, we are still getting a large number of requests for them. On the other hand, many of you intend to purchase a GTA02 and perhaps feel you have no use for your GTA01. Some of you might have other reasons to sell your GTA01. I'd like a wiki page to allow these buyers and sellers to find each other. We have a wiki page for GTA01 owners who lived in 850 MHz-only areas to sell their units; perhaps this page can be repurposed for this broader issue. Perhaps we call this the OpenMoko flea market. Anyone? Michael ___ 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: Request for assistance: Need a wiki page for buying and selling GTA01
Why not just have a wiki page with a link to ebay.com so buyers and sellers have a degree of protection when trading?. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Request for assistance: Need a wiki page for buying and selling GTA01
Hi Community, I need your help. Having completely sold out of GTA01, we are still getting a large number of requests for them. On the other hand, many of you intend to purchase a GTA02 and perhaps feel you have no use for your GTA01. Some of you might have other reasons to sell your GTA01. I'd like a wiki page to allow these buyers and sellers to find each other. We have a wiki page for GTA01 owners who lived in 850 MHz-only areas to sell their units; perhaps this page can be repurposed for this broader issue. Perhaps we call this the OpenMoko flea market. Anyone? Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Battery Capacity (Was: Re: More about the GTA02)
Hi Bradley, This is all being discussed extensively on the kernel mailing list (ML). Yes, there will be ways to reduce consumption by turning off unnecessary stuff. There are multiple levels of "suspension", each with a range of components turned on or turned off. Of course once the structure is in place, we will all be free to customize this to our hearts content. As a hacker, I can do this all in code, but as a user, I would hope to see menus which allow you to create a new mode at run time and to select in quite high resolution which components you wanted powered or unpowered. If this is a topic that interests you, I urge you to join the kernel ML, or at least to look through the archives of the past few days. Michael Bradley Hook wrote: How much juice does the display eat up when it's active? I assume it's a considerable amount. Could we have the ability to drop the phone into a minimalist mode, where all the "fluff" is disabled but bare-basic features continue to work? For example, kill the wifi, GPS, bluetooth, and even the display. If you are in a crunch and want to extend your phone's call-time capacity, you could probably deal with approximating a 3 col, 5 row standard phone keypad on the touch-screen WITHOUT the screen displaying anything. Maybe it's a silly idea, but I know I find myself stuck all the time in a situation where I wont be able to get my phone back on a charger like I had planned to. When it comes down to it, the Neo is a phone first, and I'd rather have it act as such when I'm in a bind. ~Bradley Michael Shiloh wrote: Nick Guenther wrote: On Feb 8, 2008 4:04 AM, Michael Shiloh <[EMAIL PROTECTED]> wrote: Hello, I've researched this a little, and this is what I've learned: 1. We are still looking at a number of different batteries, so there is no "final" capacity or feature set determined yet. 2. The capacity will most likely be around 1200mA. If you find any place on the wiki that says something other than 1200mA, can you please make the correction? You may reference this email. Oh. That's... really disappointing. The battery life is already unusable, and the faster processor and wifi will just make this even worse. We are well aware of software changes we need to make in order to improve battery and have simply not had the time to do this. You can expect much better battery life when we implement these changes. In fact if you look in the archives of the kernel mailing list you will see that a tremendous amount of progress has happened over the past few days. I think the current SVN code supports a much improved suspend mode that my very simple testing suggests should last for well over 12 hours. And work continues. Michael ___ 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: proprietary firmware
Am Fr 15. Februar 2008 schrieb Brandon Kruse: > In that case it is not an open phone or platform. It's a philosophical question, where "open" has it's limits. E.g. you probably consider a plain vanilla x86 GNU/linux desktop system to be pretty much "true open". However i guess you have no idea at all of the firmware that's managing your harddisk in this system. That's for a simple reason: IDE interface is age old (and so all HD's (SATA, SCSII) inherited this way we are looking at these devices), it is "just working", and it's well documented. Virtually nobody cares about the firmware behind this interface, mainly because it doesn't have a chance to stop you from doing anything you like on the _main_system_. I'm almost certain there's a hacker somewhere out there, who likes to mod his HD so the head motors will produce funny sounds, and another one thinks he can tune transfer rates even another 10k/s. However i never seen FOSS HD firmware. > It is well worth the > investigation to go fully open somehow IMO. Sure. But it's a silly idea to try and force the subsystem manufacturers by refusing to support their closed source firmware updates. When Seagate comes with a DOS-only firmware updater to add some cool new features to their drives, OM says "No, it's not FOSS!". Seagate (or here, the chip fabs) don't care. But OM deprives NEO owners of any means to have a new firmware for these subsystems. If a user doesn't like to have closed source on his device, she is free delete or not install it. But OM will not achieve anything by refusing to provide closed source drivers. I think all they get is a huge number of returns, or less sales (at least for me). And OM(!) isn't willing or able to provide circuit diagrams, so any open drivers are extremely hard to develop. In my opinion they can't do both, refuse to support closed source updates *and* keep the hw specs closed. Not if they care about their customers. Not to mention, NEO will not be "open" at all as long as the hardware is a 'big mystery'. A laugh to start with closed firmware topic. > > But I guess we could be like olpc and have a MOSTLY open platform > (wifi chip is not, as you could have guessed) I'd like it more to see OM pushing manufacturers to provide a guaranteed API, which is specified by community, and not to care about _how_ the mfactrs achieve to fulfill this contract. Than to nag manufacturers to open the sources of firmware, "because we can do better, and do not want to use what we paid for". jOERG ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Battery Capacity (Was: Re: More about the GTA02)
How much juice does the display eat up when it's active? I assume it's a considerable amount. Could we have the ability to drop the phone into a minimalist mode, where all the "fluff" is disabled but bare-basic features continue to work? For example, kill the wifi, GPS, bluetooth, and even the display. If you are in a crunch and want to extend your phone's call-time capacity, you could probably deal with approximating a 3 col, 5 row standard phone keypad on the touch-screen WITHOUT the screen displaying anything. Maybe it's a silly idea, but I know I find myself stuck all the time in a situation where I wont be able to get my phone back on a charger like I had planned to. When it comes down to it, the Neo is a phone first, and I'd rather have it act as such when I'm in a bind. ~Bradley Michael Shiloh wrote: Nick Guenther wrote: On Feb 8, 2008 4:04 AM, Michael Shiloh <[EMAIL PROTECTED]> wrote: Hello, I've researched this a little, and this is what I've learned: 1. We are still looking at a number of different batteries, so there is no "final" capacity or feature set determined yet. 2. The capacity will most likely be around 1200mA. If you find any place on the wiki that says something other than 1200mA, can you please make the correction? You may reference this email. Oh. That's... really disappointing. The battery life is already unusable, and the faster processor and wifi will just make this even worse. We are well aware of software changes we need to make in order to improve battery and have simply not had the time to do this. You can expect much better battery life when we implement these changes. In fact if you look in the archives of the kernel mailing list you will see that a tremendous amount of progress has happened over the past few days. I think the current SVN code supports a much improved suspend mode that my very simple testing suggests should last for well over 12 hours. And work continues. Michael ___ 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: proprietary firmware
In that case it is not an open phone or platform. It is well worth the investigation to go fully open somehow IMO. But I guess we could be like olpc and have a MOSTLY open platform (wifi chip is not, as you could have guessed) Brandon Kruse (bkruse) On Feb 15, 2008, at 1:22 PM, Mikhail Umorin <[EMAIL PROTECTED]> wrote: I am not sure if this made it to the list... How about a closed-source firmware update application/startup module and a specification of an API (not necessarily constant, just public) for each chip with closed firmware? Mikhail. ___ 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: proprietary firmware
I am not sure if this made it to the list... How about a closed-source firmware update application/startup module and a specification of an API (not necessarily constant, just public) for each chip with closed firmware? Mikhail. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Battery Capacity (Was: Re: More about the GTA02)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: >> *-USB-host power shortcircuit...? Will it blow my battery or whole NEO up in >> smoke? ;-). > > http://www.analogictech.com/products/digitalfiles/AAT1275.pdf and http://www.richtek.com/www/Docs/DS9711-04P.pdf - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHtVnnOjLpvpq7dMoRAp9EAJ0cwCa3XSpIkB3txvBoX4Olghlm5gCgk8Hk AYePHuOMURmW7LlTqroZ1tA= =HuPz -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: topic for next community update [was Community Update Wed Feb 13 2008]
For apps, personally (ie, this is just my opinion) I think its fine if we target providing solid very minmal apps initially, again we can point at the memory on the device (it is stacked with memory), the standard X and libs provided, and its upgradability with package granularity to convincingly (well it convinces me :-)) say more apps are coming. It convinces me too, and I'm participating in OpenMoko solely for the reason that I want to push out some end-user apps, developed new and fresh, for the platform. When it becomes more widely available, that is, I will be quite happy targetting it as a major platform for my music apps .. as it stands right now, its very rewarding to be doing daily builds that can run on both EEE PC and OpenMoko with very little fuss, and it sure is going to be interesting keeping this party going for the next few months .. ; -- Jay Vaughan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Battery Capacity (Was: Re: More about the GTA02)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: > Am Fr 15. Februar 2008 schrieb Andy Green: >> Still for quite a few embedded tasks I2C or LVTTL UART -- >> let's not forget USB OTG 12Mbps host from the mini USB B connector -- >> will be enough to make a practical solution though. > Good point! If i need additional GPIO, so what. I got I2C, so i just chain up > some with a dirt cheap chip. > The interfacing of the smart battery in GTA01 shouldn't be a big thing this > way. > Homebrew I2C->GPIO driver, patching GPIO_Bat DEF in src for GTA02 smartbat > driver. Well you need a bit of caution on that particular one because the smart battery uses a "1 wire" type protocol called HDQ that is reasonably time-sensitive and uses a "width of 0 level" encoding scheme to define the bit state. So ~~~._.~ can be a '0' and ~~.__.~ can be a '1' for example. The crisis comes with that when you receive the data back from the battery, you have to sample it in a fairly stable way to assess the '0' length on the wire. See the bq27000 datasheet link I posted before for details and timing. In Linux, the I2C stack has a nasty gotcha, it cannot work from interrupt context, and in fact if you have interrupts on you are screwed anyway because other interrupts like USB or whatever can come take take the CPU for considerable periods making your IO crazy jittery. If you try to get around that by using a workqueue so it is out of interrupt context, then your IO is insanely jittery at scheduler granularity and depending on userspace load :-) So sampling that HDQ '0' length becomes difficult. You can square the circle by disabling interrupts and doing your own I2C bitbang via GPIO from CPU, and spinning for the right period between I2C actions, but the owns the CPU for many ms each time. Its probably okay since one doesn't read the battery very often. But you can see it is a bit more of an advanced project. On GTA02 I used a single CPU GPIO with a FIQ driver triggered off a timer, with the HDQ protocol implemented in a state machine in the FIQ ISR to beat these restrictions. The patches for both the FIQ driver and the HDQ and BQ27000 drivers are in the kernel mailing list archives. If people want to provide patches to reuse ANY GTA02 work that is done for GTA01, that will be really welcome. > So real issue left for some projects is "which power should i use" > (especially > for those devices that don't do their own power-down). Its going to depend on the current you need. IO_3V3 is unswitched but high current. Really I think for most projects, the real answer is the USB OTG Host connector. You don't have to open the case and it provides switched power for you. > And i wonder whether there will be *good* (near circuit diagram) specs for > the > connectors. I.E.: Well I am under NDA, but some of these datasheets are available in the world and the answers may not be a million miles away from the typical application circuits in there. > *-what kind of OverVoltage-Protection (clamp-diodes etc) / HF-blocking / > ground potential..., can i expect behind any external connector. I have to leave that, but there is EMC and ESD protection considered on them all. > *-What exactly is the impedance (R, C) of headset out, what are the absolute > maximum ratings (so i may figure out e.g. whether the headset out makes for a > high-quality (HiFi) 1,[EMAIL PROTECTED] line out, or should i plan for a 56R > load > instead of the standard 10k-50k). http://www.national.com/ds.cgi/LM/LM4853.pdf > *-USB-host power shortcircuit...? Will it blow my battery or whole NEO up in > smoke? ;-). http://www.analogictech.com/products/digitalfiles/AAT1275.pdf - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHtUkWOjLpvpq7dMoRAmveAJwOGn6/xI8lsJG1GVWCwQvrvEnJjwCeMOhX G9Y1XHll5F3kGnvKxBbCnaM= =9u9l -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
