Re: New Life in Openmoko Phones
On Fri, May 22, 2009 at 12:31 PM, Nils Faerber nils.faer...@kernelconcepts.de wrote: Werner Almesberger schrieb: Nils Faerber wrote: Wouldn't it be more fruitful to create a project that is only concerned about providing the best possible tools, hardware and software, for braking into and reverse engineering existing devices? There are already a number of projects that do exactly this, such as OpenEZX and gnufiish. There are a number of limitations to this approach, though: [...] Fully aggree about all the limitations - we have all been there, tried that and failed to various degrees. What I am wondering is if it would be possible by providing a single project putting together all the bits and pieces and developing the glue could solve the problems that reverse engineering usually suffers from. For example it is currently still a major pain to setup and configure OpenOCD correctly for your target. Would it probably be possible to develop a large part library and create proper auto detection? That will automagically detect the JTAG chain, parts on it and offer programming and debugging options? Collect and integrate tools for signal analysis, decoding, disassembling etc. in a manner like KiCAD - collect and integrate well along with simple hardware designs to attach to target devices. I also think that reverse engineering projects have become easier recently since many of the design houses and manufacturers do not reinvent the wheel everytime they make a new device. They rather base on reference designs and do only slight modifications. Not all of them of course, but enough to satisfy the open source community with a variety of devices. I think of devices like the HTC ones that have become easier and easier to hack over the years. There are of course beasts that are unlikely to be hacked anytime soon, like some of the Motorola ones or almost all Nokia phone devices (I don't know of any hack trying to break into a Series60 device though they should be able to run Linux). I've a phone not working properly that could be used for this purpousses. The problems are that i didn't know a lot about the Nokia architecture, and i'm not able to read some JTAG like interface. They have MDBUs ,but i didn't know f this is enough. In the other hand most of the hardware (at least CPU) are ASICS that make harder to develop anything over them. If you have any documentation or tip to start some hacking on these devices, i would be really happy to start it. Of course, none of this means that this approach is guaranteed to fail, there is the success story of the WRT54G, but that's also a much simpler and extremely long-lived device. So the bottom line is that I don't think this approach can only scale if you can convince the company whose phone you opened to cooperate with you. And it's unlikely that they would be able to open their design, even if you could convince them they should. This is indeed unlikely, for many good reasons. On the other hand, the approach where you own the design can be brought to mass-production with anyone's support. Even a small carrier or a consortium of interested parties could do it. Furthermore, an open design lowers the barrier of entry for people who want to make variants. Not only do they not have to license the design, but they also don't depend on a single company to support them. The setup cost is still very unattractive even if you want to build a project with a respectable number of devices. I would be extremely glad if a manufacturer would jump on such a train! But I am sceptical about it. Hardware is needed in the form of good debug adapters. Those would be much easier to have made than a complete phone device. Good software is needed for the hardware debuggers and also for disassembly analysis, protocol analysis etc. I think in terms of tools, both approaches can share a lot. A protocol analyzer will help you debug your own implementation just as well as it will help you to discover a vendor's mystery protocol. He :) The world could be so much better if mobile devices would be as open as PCs - then we could save so much effort and do what we all really like to do, develop software and not tools to develop software. - Werner Cheers nils faerber -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ hardware mailing list hardw...@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware Best Regards -- ___ Rafael Campos o0 Methril 0o http://openblog.methril.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Sean Moss-Pultz wrote: For sure. When you guys get ready for the first build, I'll find a way to help. I'm open to donating some parts and time. This is a great project! Wonderful, thanks a lot ! Access to parts is probably the single most important condition for the success of this project. The task is getting easier every day. Time to roll up our sleeves ! :) I just added a list of areas where help is welcome to the Wiki: http://wiki.openmoko.org/wiki/Gta02-core#How_can_I_help.3F - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Nils Faerber wrote: Wouldn't it be more fruitful to create a project that is only concerned about providing the best possible tools, hardware and software, for braking into and reverse engineering existing devices? There are already a number of projects that do exactly this, such as OpenEZX and gnufiish. There are a number of limitations to this approach, though: - there's always the risk that you can't forcibly open some important chips E.g. see the still large number of 0% items on http://gnufiish.org/trac/wiki/Project_Status - it's difficuly to get power management right without knowing exactly what goes on in the device - even if you succeed, there's no guarantee that the vendor won't make some changes for the worse (from the Open Source point of view) in new revisions of the product. E.g., OpenWRT got bitten by a radical change of the core system architecture of the WRT54G. Luckily, LinkSys/Cisco could be convinced to make a variant specifically targetted for Linux. - worse yet, considering the amount of time such reverse engineering takes and the short life cycles of these products, the product may already have been replaced by the time you catch up. This means that it will be very difficult to spread such opened devices outside a groups of very determined enthusiasts. E.g., consider the age of the hardware OpenEZX, being in fairly good shape as far as the software is concerned, uses. Of course, none of this means that this approach is guaranteed to fail, there is the success story of the WRT54G, but that's also a much simpler and extremely long-lived device. So the bottom line is that I don't think this approach can only scale if you can convince the company whose phone you opened to cooperate with you. And it's unlikely that they would be able to open their design, even if you could convince them they should. On the other hand, the approach where you own the design can be brought to mass-production with anyone's support. Even a small carrier or a consortium of interested parties could do it. Furthermore, an open design lowers the barrier of entry for people who want to make variants. Not only do they not have to license the design, but they also don't depend on a single company to support them. Hardware is needed in the form of good debug adapters. Those would be much easier to have made than a complete phone device. Good software is needed for the hardware debuggers and also for disassembly analysis, protocol analysis etc. I think in terms of tools, both approaches can share a lot. A protocol analyzer will help you debug your own implementation just as well as it will help you to discover a vendor's mystery protocol. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Wolfgang Spraul wrote: Hi everybody, Right now, if you want to join the revolution in open hardware development, read the gta02-core wiki page carefully (http://wiki.openmoko.org/wiki/Gta02-core), and join the mailing list (slightly confusingly named gta03 :-)) at http://lists.openmoko.org/mailman/listinfo/gta03 Then see where you can contribute - it's a wide open field with many possible tasks, no matter which background you are coming from. I'll see what I can do. I already put this on Wiki main page . I think that will be more easy to find this page. Brenda Wang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/New-Life-in-Openmoko-Phones-tp2934354p2955538.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Great news indeed! Are there plans to change uSD placeholder? Every single person I showed my phone to said that it's the most idiotic (that one of the most calm of used words :) design he\she ever saw. Personally I completely agree with that - making uSD unaccessible without disassembling half of the phone is beyond my understanding. best regards, Max. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Nils Faerber wrote: I also know from experience that some parts are really nasty to get - either you do not get them at all or you have to buy large quantaties of them. Oh yes. You wouldn't believe just how often we had that sort of thing happen to Openmoko. I've learned to treat sourcing with a healthy dose of paranoia. I know at least three such companies, one beeing in my home town. For such a large number of different components 10-20 units will be *extremely* expensive. Seems to be about EUR 200-300 for 10 units. With the PCBs costing around EUR 200 apiece, that would be around EUR 500 for the production. Okay, that's about what I would have guessed. Limited editions are always a bit pricy :-) Those are of course just very rough numbers. It also depends on type of parts, how many of which type, etc. But as a first rough figure it could do. Sure. Thanks a lot for the estimate ! 0402 is OK - we can do this in our work-shop, but that's smallest we can do ;) Density is indeed another critical issue. And pitily we cannot do any BGA at all. What we have is the Expert from Essemtec: Very nice equipment :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Max wrote: Are there plans to change uSD placeholder? No - changing uSD holder isn't part of the GTA02-core plans. In GTA02-core the intention is that the uSD card contains the full OS image including kernel. The NAND will only contain QI, and the expectation is that QI won't need to be re-flashed regularly. GTA02-core can't start if the card is missing, and there's no possibility of swapping out the card while the phone is switched on. Thus the uSD is rather like a standard PC's OS hard drive, and rather unlike 'removable' media types. This is how some folk are using the uSD at the moment, with one or multiple distro images on an uSD card. Upgrading a distribution, or fixing a broken install is then possible by removing the uSD and mounting it in a regular PC, without necessarily re-flashing through dfu. With GTA02-core, each distro can have a kernel ( modules etc) it's matched to, because the kernel is part of the distro's filesystem image. This also means that our internal storage is upgradable, as new uSD devices become economical etc. One thought is that future phones should include two uSD cards - one 'internal' for OS/kernel etc. and one that is 'removable' for data storage/exchange - although this is out of scope for GTA02-core. All the best, Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Dave Ball wrote: Max wrote: Are there plans to change uSD placeholder? No - changing uSD holder isn't part of the GTA02-core plans. In GTA02-core the intention is that the uSD card contains the full OS image including kernel. The NAND will only contain QI, and the expectation is that QI won't need to be re-flashed regularly. GTA02-core can't start if the card is missing, and there's no possibility of swapping out the card while the phone is switched on. Thus the uSD is rather like a standard PC's OS hard drive, and rather unlike 'removable' media types. This is how some folk are using the uSD at the moment, with one or multiple distro images on an uSD card. Upgrading a distribution, or fixing a broken install is then possible by removing the uSD and mounting it in a regular PC, without necessarily re-flashing through dfu. With GTA02-core, each distro can have a kernel ( modules etc) it's matched to, because the kernel is part of the distro's filesystem image. This also means that our internal storage is upgradable, as new uSD devices become economical etc. One thought is that future phones should include two uSD cards - one 'internal' for OS/kernel etc. and one that is 'removable' for data storage/exchange - although this is out of scope for GTA02-core. Or having a special USB HUB for the OpenMoko device that simultaneously can: - charge your device (via USB to laptop or via charger) by connecting master devices - connect slave devices as memory sticks and keyboards - connect with mini USB to the OpenMoko device and normal USB to master and sleve devices All the best, Dave ___ 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: New Life in Openmoko Phones
Am Mittwoch, 20. Mai 2009 schrieb Dave Ball: No - changing uSD holder isn't part of the GTA02-core plans. In GTA02-core the intention is that the uSD card contains the full OS image including kernel. The NAND will only contain QI, and the expectation is that QI won't need to be re-flashed regularly. GTA02-core can't start if the card is missing, and there's no possibility of swapping out the card while the phone is switched on. Thus the uSD is rather like a standard PC's OS hard drive, and rather unlike 'removable' media types. One reason I regulary remove my uSD card from the FR to put it in a card reader is the incredible slow USB 1.1 port. 1GB with 12 Mbit/s is more than 11 min (but 12 Mbit/s will never be reached) The PC world moves to USB 3, so it should be possible to include USB 2 to GTA02 successors... One thought is that future phones should include two uSD cards - one 'internal' for OS/kernel etc. and one that is 'removable' for data storage/exchange - although this is out of scope for GTA02-core. Great! If I compare the size of my Palm TX with my FR, even a SD would be possible. But uSD is probably more up to date and allows more compact cases. Regards, Martin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Martin Bernreuther wrote: One thought is that future phones should include two uSD cards - one 'internal' for OS/kernel etc. and one that is 'removable' for data storage/exchange - although this is out of scope for GTA02-core. s/should/could. Obviously there isn't any commitment to future phones at the moment, so while I may think two uSD cards is a swell idea, it may or may not happen. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
If you want any FPGA or CPLD work doing, I will do it. Been doing this kind of stuff since fuse blown devices with Palasm. (20 years!) Any glue logic, hardware acceleration, bus interfaces etc. If anyone has ideas about what we could put in a low powered CPLD/FPGA, please come forward, will have the time to do it in about a month. Me. On Mon, May 18, 2009 at 7:01 PM, Wolfgang Spraul wolfg...@openmoko.comwrote: Hi everybody, (sorry for the cross-posting, I thought spreading the word about gta02-core and new stuff from Openmoko was worth it...) Today Openmoko released additional pieces of documentation about Freerunner hardware: board outline, footprints and netlist. Same as all other releases before - under Creative Commons Share-Alike license. Available at: http://downloads.openmoko.org/developer/schematics/GTA02/gta02_outline_footprints_netlist.tar.bz2 What is this and who is it for? Well, definitely not for end users, not for software developers, not even the typical kernel hacker. The release contains cryptic text files containing data points about our hardware - basically additional information complementing our PDF-formatted schematics release last year. The reason we released this is to support an exiting new project that has emerged over the last few weeks - gta02-core. http://wiki.openmoko.org/wiki/Gta02-core gta02-core is a community project to create a new hardware revision of the gta02 hardware They chose a 100% GPL layout tool, KiCAD (http://en.wikipedia.org/wiki/Kicad), which uses only text-based files hence they can be checked into typical revision control systems. Since they are text, they are also 'scriptable', i.e. scripts can extract and process data from the layout files. Werner and Dave Ball got it rolling, and are currently working on the re-layout of gta02 (http://docs.openmoko.org/trac/browser/trunk/gta02-core ). The way I see gta02-core is that it opens up a path to new, fully open phone hardware. For the future of the software we are all working on right now - whether it's the kernel, FSO, Paroli/Ophonekit, etc., we either need to design new fully open hardware specifically for it, or we need to find ways to hack into phones that are 'closed' by default (either accidentally or on purpose). gta02-core focuses on the first option, and I hope will receive more attention from the community, and definitely from Openmoko the company. The path is long, even KiCAD itself may need improvements, but if a few more people get interested and join, we may have new fully open phone hardware in 6-12 months. No worries, in all this time of course the Freerunners will remain available (we have enough in stock and are ready for new production runs if necessary), and hopefully they continue to be an interesting development platform for mobile free software projects. Right now, if you want to join the revolution in open hardware development, read the gta02-core wiki page carefully (http://wiki.openmoko.org/wiki/Gta02-core), and join the mailing list (slightly confusingly named gta03 :-)) at http://lists.openmoko.org/mailman/listinfo/gta03 Then see where you can contribute - it's a wide open field with many possible tasks, no matter which background you are coming from. I'll see what I can do. Best Regards, Wolfgang ___ 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: New Life in Openmoko Phones
On Wed, May 20, 2009 at 3:35 AM, Werner Almesberger wer...@openmoko.org wrote: Q3) What is role of OpenMoko organization now? Sell remaining GTA02s? As far as I know, Openmoko is selling GTA02s and, besides that, concentrating on the project B. Openmoko is friendly towards the gta02-core project, and several people at Openmoko are trying to help us within their means. For sure. When you guys get ready for the first build, I'll find a way to help. I'm open to donating some parts and time. This is a great project! -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Nils Faerber nils.faer...@kernelconcepts.de writes: Wolfgang Spraul schrieb: Today Openmoko released additional pieces of documentation about Freerunner hardware: board outline, footprints and netlist. Same as all other releases before - under Creative Commons Share-Alike license. Available at: http://downloads.openmoko.org/developer/schematics/GTA02/gta02_outline_footprints_netlist.tar.bz2 This is in general great! But sorry to be a little sceptical here - but hardware != software. What I mean is that collaboratively developing software is pretty easy since we have the internet to share and most of us have a PC to develop upon. But with hardware development the situation is a little bit different. Even if the collaborate development effort succeeds, i.e. KiCAD is sufficient and a hardware design becomes ready, it still needs to be produced - and here troubles start, from buying the parts, making PCBs etc. running up the whole stack to asembling the whole device and testing it. This cannot be done as open source effort with volunteers. Here real money is involved - a lot of real money. And this needs to be done several times, for prototypes, small A-series, probably a B-series and then final devices. But you should know better than me about this process (at least by now). What are the plans or ideas to enable later on production? Pleas eget me right, I would love to see such a project succeed and maybe even contribute to it but I really cannot imagine any possibility how such a hardware production should work in the end without a big sponsor in the background. It was many years since I did any serious electronics work, but from my uninformed viewpoint this seems to be workable because: - The case is not changed and can be reused - no parts are changed so existing inventory at OM can be used for prototyping I dont know what making a PCB and populating it costs these days, but if it costs a couple of hundred euros per populated board, I would sponsor at least one out of my personal curiosity. I used to be good at electronics assembly, maybe I could even put it together myself if I find a SMD oven etc. Cheers nils faerber -- Joakim Verona ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
For me, I think you've hit the nail on the head. We're trying something new with gta02-core, and by working on the small changes we've proposed we can focus on the tools that we use, the organisation of individual contributors and the stages we need to go through to get functional hardware. Doing gta02-core means that we should be able to move forward fairly rapidly and shake out any problems as we go. For that aim, the specific changes we make are almost arbitrary - and as stated on the wiki we don't expect this to turn into production hardware. That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? Is it that having two accelerometers introduces layout difficulties? Is it that there aren't enough interrupt lines on the SoC to properly support the two accelerometers? ... Since it was decided to remove it, there must have been some kind of expected benefit. I actually have the same question for the audio-amp: why remove it? But that one is a bit more complicated, because I'm not sure what is this audio-amp anyway (is it the thing that drives the headphone plug?) Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
On Tue, May 19, 2009 at 10:52:22AM -0400, Stefan Monnier wrote: That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? I only use one for omnewrotate because that's all I need to infer the position in order to call xrandr for rotating the screen accordingly. There are possible uses for two, the least of which are redundancy and double checking. Since it was decided to remove it, there must have been some kind of expected benefit. I'm curious about the expected benefits as well. But the wiki only states facts and not the reasoning behind them... Rui -- Frink! Today is Prickle-Prickle, the 66th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
The wiki says: # Remove one accelerometer and connect both interrupts of the remaining one Is connecting both interrupts of the remaining one an expected benefit? Do both current accelerometers only have one interrupt connected? What does that even mean? Cheers, Joseph 2009/5/19 Rui Miguel Silva Seabra r...@1407.org: On Tue, May 19, 2009 at 10:52:22AM -0400, Stefan Monnier wrote: That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? I only use one for omnewrotate because that's all I need to infer the position in order to call xrandr for rotating the screen accordingly. There are possible uses for two, the least of which are redundancy and double checking. Since it was decided to remove it, there must have been some kind of expected benefit. I'm curious about the expected benefits as well. But the wiki only states facts and not the reasoning behind them... Rui -- Frink! Today is Prickle-Prickle, the 66th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ 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: New Life in Openmoko Phones
Nils Faerber wrote: This would be one of the details I am interested in, i.e. would OpenMoko Inc. help in making (read as producing) this new design? With its part stock, manufacturing capabilities, etc.? Access to components is currently under discussion, yes. There are at least some logistical issues, i.e., the GTA02 components seem to be at a place where it's difficult to move them. But we're working on it ... The idea is indeed that we can get most of the components from Openmoko. It's not only about the cost of the material but also the difficulty of sourcing certain parts and the errors that could be introduced in the process. Many of the parts in the GTA02 cannot be reasonably placed by hand. There are almost a dozen (or more?) BGA chips which are extremely hard to handle (you do not see if the balls match the pads). Hehe, this reminds me of the usual SMT sucks, where can I get this chip in DIP ? discussion. This question is usually followed by someone suggesting some more or less crazy scheme that actually does yield a DIP component, and a number of people explaining their techniques for soldering SOIC and even SSOP. Then usually someone chimes in describing how to solder QFN and the like with often grossly inadequate equipment. And often enough, this ends with hints for how BGAs can be done with kitchen utensils :) I'm not sure where exactly the line between unusual skills and know-how and (not very hard) science fiction lies. There's scary stuff out there, though, e.g., http://www.youtube.com/watch?v=HdqVt0jCBHk http://www.youtube.com/watch?v=__dEMKzkLYc Anyway, back to reality. I agree that this needs a real SMT production line. There are some parts that can be difficult to SMT (buttons, connectors) that are better hand-soldered, but for most of the items, you want a properly quality-controlled and automated process. Please bear in mind that the objective of gta02-core is not to make a design that's immediately ready for mass-production but to set up the process and make a small number of prototypes. If some company should find the result appealing enough to turn this into a real product and make the corresponding inventments, that would of course be very welcome. But we can't count on this happening so far. If you have contacts with companies that make prototype SMT runs, it would be interesting if you could get rough cost estimates from them. Let's assume the following parameters: - 150-200 different components, all of them in reasonably common packages, on tape. - most difficult component is a 332-FBGA with 0.5 mm pitch (the S3C2442B MCP) - 500-600 components in total. - 10-20 units produced. Then there are almost microscopic parts like resistors and capacitors - which pitch? 0402 at least if not even 0201 or smaller. 0402 is the smallest. For manual soldering (e.g., rework), size is less of a problem than density. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Nils Faerber nils.faer...@kernelconcepts.de writes: He ;) Many of the parts in the GTA02 cannot be reasonably placed by hand. There are almost a dozen (or more?) BGA chips which are extremely hard to handle (you do not see if the balls match the pads). Then there are almost microscopic parts like resistors and capacitors - which pitch? 0402 at least if not even 0201 or smaller. So populating the board is almost impossible by hand without highly qualified tools (and no, a tweezer and a stereo-microscope will not suffice). But the problem you will encounter beforehand is printing the solder paste. Stencil printing such high density with even and correct paste distribution is not exactly easy even if you have proper stencil printers. Adjusting them, having the right paste to print etc. is high art of SMT manufacturing. And finally you need a really proper nitrogen flooded full convection reflow oven for good quality soldering of such delicate parts (different heat absorption of parts, proper heat profiles, good energy distribution, etc.). Well this just goes to show that the last time I did serious electronics we prototyped with wire wrap guns and stuff :) At least we made vlsi:s with vhdl. So what you really need is a modern manufacturing line, with auto-placer for almost all parts. I do not know how many different parts there are on the GTA02, probably 100, or even more? This means very high initial effort for setting up the machine to pupulate a board. If you then run 1 or 10 or 100 does not make much difference for the machine cost anymore (you just need more parts). The setup effort is the thing that makes prototypes or small series such expensive. I just visited another electronics maker here in Germany and they have a placement machine which can set up to 85000 parts per hour. Compared to something like a day for setting up the machine, the time placing the parts is almost irrelevant. The smaller the parts have got in the past the more difficult it has become for hobbyists to catch up with technology. It will not take very long until home-grown PCBs will be almost impossible to do because all the interesting chips come as bare-die only (just the silicon, no case or pins). So what is needed is the real commitment by some professional hardware manufacturer to put the new design on one of his lines and care for the prototyping and small initial a-series. After the design has proven to work a small first production run should be easier to setup since you can then give proove that it will work and persuade potential customers to pay up-front for the device - or at least a part up-front. That would enable buying the parts and paying for setting up the production. I think the Open Pandora people did it quite similarly, i.e. they sold devices and had them made after sales. If your customers trust you enough this can work. So in the end hardware making is more a matter of money than motivation or man power, pitily... Cheers nils faerber -- Joakim Verona ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Ron K. Jeffries wrote: Q1) So, OpenMoko has not committed to building the 10-20 protos? No, and Openmoko wasn't actually asked for such a commitment, as it would not fit with the current focus of Openmoko. If Openmoko or some other company might be interested at some point in time to produce devices based on gta02-core, I can't predict. I expect that PCB and SMT are within the reach of many a hobbyist's budget. If we can find sponsors who can contribute money or services, that would of course make things even easier. Q2) What is design goal? a simple clean up re-do of GTA02 (less Glamo...) in an open source hardware context? Yes, that's basically the idea. I wouldn't even consider the cleanup per se as such important, but since we're redoing things anyway, we wouldn't want to miss the opportunity to right a few wrongs. Q3) What is role of OpenMoko organization now? Sell remaining GTA02s? As far as I know, Openmoko is selling GTA02s and, besides that, concentrating on the project B. Openmoko is friendly towards the gta02-core project, and several people at Openmoko are trying to help us within their means. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Hi, On Tue, 19.05.2009 at 17:02:52 +0100, Rui Miguel Silva Seabra r...@1407.org wrote: On Tue, May 19, 2009 at 10:52:22AM -0400, Stefan Monnier wrote: That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? There are possible uses for two, the least of which are redundancy and double checking. I guess that everyone who intends to use the device as a navigation system would welcome the two accelerometers for improved precision, and to better and longer guess the position/orientation of the vehicle while not having GPS, eg. in a tunnel. I'm curious about the expected benefits as well. But the wiki only states facts and not the reasoning behind them... Yes, and that's imho not really motivating. Kind regards, --Toni++ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
On Tuesday 19 May 2009, Toni Mueller wrote: Hi, On Tue, 19.05.2009 at 17:02:52 +0100, Rui Miguel Silva Seabra r...@1407.org wrote: On Tue, May 19, 2009 at 10:52:22AM -0400, Stefan Monnier wrote: That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? There are possible uses for two, the least of which are redundancy and double checking. I guess that everyone who intends to use the device as a navigation system would welcome the two accelerometers for improved precision, and to better and longer guess the position/orientation of the vehicle while not having GPS, eg. in a tunnel. Except that they aren't sensitive enough to rotational acceleration for that. If that's what you want to do then you should be asking for one accel to be replaced with a 3-axis gyro and/or magnetometer. You might like a USB CAN bus adaptor too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
On Tue, May 19, 2009 at 10:52:22AM -0400, Stefan Monnier wrote: That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? Is it that having two accelerometers introduces layout difficulties? Is it that there aren't enough interrupt lines on the SoC to properly support the two accelerometers? ... I don't think so. We already have both EINT8/GPG0 and EINT16/GPG8 reserved for the second accelerometer, but not connected it to EINT16/GPG8 (R1547 = NC). Last time I counted[1], there wasn't a shortage of interrupt or GPIO pins. [1] http://lists.openmoko.org/pipermail/gta03/2009-April/74.html If we're really going to mess with the accelerometers, why not move them off the SPI1 bus and onto GPIO pins? We're currently using the bitbanging GPIO_SPI driver anyway. That way, we could keep a GTA01/GTA02 compatible debug connector (because WLAN could use SPI1 instead of SPI0). I actually have the same question for the audio-amp: why remove it? But that one is a bit more complicated, because I'm not sure what is this audio-amp anyway (is it the thing that drives the headphone plug?) It drives either the headphone speakers or the bottom handset speaker, depending on the presence of the headphone plug. It's the LM4853 (U4101 on page 7 of the schematics). IIUC, the GTA03 was going to drive both from the WM8753L sound chip directly as suggested in the WM8753L datasheet. I wanted to compare the output power of the two, but I can't find the exact LM4853 variant we're using. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
On Wed, 2009-05-20 at 02:11 +0200, Rask Ingemann Lambertsen wrote: On Tue, May 19, 2009 at 10:52:22AM -0400, Stefan Monnier wrote: That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? Is it that having two accelerometers introduces layout difficulties? Is it that there aren't enough interrupt lines on the SoC to properly support the two accelerometers? ... I don't think so. We already have both EINT8/GPG0 and EINT16/GPG8 reserved for the second accelerometer, but not connected it to EINT16/GPG8 (R1547 = NC). Last time I counted[1], there wasn't a shortage of interrupt or GPIO pins. [1] http://lists.openmoko.org/pipermail/gta03/2009-April/74.html If we're really going to mess with the accelerometers, why not move them off the SPI1 bus and onto GPIO pins? We're currently using the bitbanging GPIO_SPI driver anyway. That way, we could keep a GTA01/GTA02 compatible debug connector (because WLAN could use SPI1 instead of SPI0). I actually have the same question for the audio-amp: why remove it? But that one is a bit more complicated, because I'm not sure what is this audio-amp anyway (is it the thing that drives the headphone plug?) It drives either the headphone speakers or the bottom handset speaker, depending on the presence of the headphone plug. It's the LM4853 (U4101 on page 7 of the schematics). IIUC, the GTA03 was going to drive both from the WM8753L sound chip directly as suggested in the WM8753L datasheet. I wanted to compare the output power of the two, but I can't find the exact LM4853 variant we're using. I've some questions: *will the sound quality be ok(is there a plan to correct the problematic capacitor that is between the sound card and the audio connector)? and will it fit into the same case than the GTA02...because if I understood well the sound problem can't or is too difficult to fix well(otherwise it's dangerous...) on the GTA02 *Does everything fit into the buses(GPIO,SPI etc...) because the removing the glamo removes some GPIO if I remember well *I bet I will need to buy the debug board if I buy such phone...because I'm afraid of bricking it(no NOR means only one bootloader...and I could have rendered mine unbootable if the nor was not present: I typed bad uboot command and that prevented the nand uboot from beeing used(no more usb-serial access and no more booting)) Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
GNUtoo wrote: *will the sound quality be ok(is there a plan to correct the problematic capacitor that is between the sound card and the audio connector)? and will it fit into the same case than the GTA02...because if I understood well the sound problem can't or is too difficult to fix well(otherwise it's dangerous...) on the GTA02 We expect to be able to get the 100uF capacitors in the space we gain from removing the audio amp and the u4401 (gsm upload) circuitry. Retro-fitting to gta02 boards is more complex, as there is neither board space or vertical height above existing components and below the can. *Does everything fit into the buses(GPIO,SPI etc...) because the removing the glamo removes some GPIO if I remember well Removing Glamo loses the SDIO interface currently used for the SD card. So we will be moving the WLAN to SPI, and the SD card to the SDIO interface on the SoC freed up by the WLAN It all fits so far. *I bet I will need to buy the debug board if I buy such phone...because I'm afraid of bricking it(no NOR means only one bootloader...and I could have rendered mine unbootable if the nor was not present: I typed bad uboot command and that prevented the nand uboot from beeing used(no more usb-serial access and no more booting)) The expectation is that QI and any build data will be written to NAND once, and then not over-written. QI's simplicity means that once it's working for the new board, it shouldn't need upgrading later. Combined with the kernel and OS images on the SD card, this should eliminate (or at least vastly reduce) any writing to NAND. This puts the gta02-core bootloader in a similar situation to the current GSM firmware, and many PC BIOSes - not normally field serviced, but can be if needed. Debug boards or other JTAG equipment will be needed for anyone hacking on the initial boot/bringup, which probably covers all of the handful of prototype boards we're currently expecting to produce... Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
http://wiki.openmoko.org/wiki/Gta02-core sounds interesting. could someone add background information why parts change? removing the glamo seems pretty plausible, but why removing one of the accelerometers? audio amp? nor? ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
On Mon, May 18, 2009 at 07:20:13PM +0200, arne anka wrote: http://wiki.openmoko.org/wiki/Gta02-core sounds interesting. could someone add background information why parts change? removing the glamo seems pretty plausible, but why removing one of the accelerometers? audio amp? nor? ... I don't see why to remove one of the accelerometers and have added so to the Discussion tab. Rui -- Pzat! Today is Pungenday, the 65th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Hi, On Tue, 19.05.2009 at 01:01:43 +0800, Wolfgang Spraul wolfg...@openmoko.com wrote: (sorry for the cross-posting, I thought spreading the word about gta02-core and new stuff from Openmoko was worth it...) much appreciated. I don't understand nor agree to all stated goals, however. If you have something that I could quickly read to get the rationale for the various proposed changes, I'd be really glad to go and read that. They chose a 100% GPL layout tool, KiCAD (http://en.wikipedia.org/wiki/Kicad), which uses only text-based files This sounds good, but you seem to require a certain minimum version of Kicad, right? Checking out from OM and running Lenny's Kicad produced less-than-satisfactory results... Either the repo is broken, or the software is. Some clarification would be nice to have! Kind regards, --Toni++ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Wolfgang Spraul wrote: Today Openmoko released additional pieces of documentation about Freerunner hardware: board outline, footprints and netlist. This is great. Thanks a lot to you and everyone in Openmoko who has helped to make this happen ! With these files, we'll be able to make a mechanically accurate board prototype and we can also do more extensive sanity-checking of the gta02-core design and layout before making any hardware. So again thanks a lot ! This will help our crazy little project a good deal. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
2009/5/18 Rui Miguel Silva Seabra r...@1407.org: On Mon, May 18, 2009 at 07:20:13PM +0200, arne anka wrote: http://wiki.openmoko.org/wiki/Gta02-core sounds interesting. could someone add background information why parts change? removing the glamo seems pretty plausible, but why removing one of the accelerometers? audio amp? nor? ... I don't see why to remove one of the accelerometers and have added so to the Discussion tab. For this you have the actual GTA02, I'm not an expert at all, but keep things simply is always a good Idea , and as they sayd is not pretended to have a production ready phone, but all the learning done in the way of do this simply phone can help to start a more complicated design, even with gyroscopes, compass, a full kitchen and swimming pool if it fit the case, but now I agree in do this a simple but powerful as they can, and even if they finish with something looks like this[1] but with functional GPS/WIFI/BT/GPRS/CIR/SIR/USB will worth the effort just my 0.2 euro cents [1]http://www.gsmarena.com/alcatel_hc_800-40.php Rui -- Pzat! Today is Pungenday, the 65th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Werner Almesberger wrote: Wolfgang Spraul wrote: Today Openmoko released additional pieces of documentation about Freerunner hardware: board outline, footprints and netlist. This is great. Thanks a lot to you and everyone in Openmoko who has helped to make this happen ! Ack - Thanks all! Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
On Monday 18 May 2009, Rui Miguel Silva Seabra wrote: I don't see why to remove one of the accelerometers and have added so to the Discussion tab. Is the second accelerometer genuinely useful? IIRC due to the small distance between the accels it can only be used to measure large angular accelerations, and then only on two axes. It might be useful to replace the accel with a 3 axis gyro or magnetometer though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
David Reyes Samblas Martinez wrote: 2009/5/18 Rui Miguel Silva Seabra r...@1407.org: On Mon, May 18, 2009 at 07:20:13PM +0200, arne anka wrote: http://wiki.openmoko.org/wiki/Gta02-core sounds interesting. could someone add background information why parts change? removing the glamo seems pretty plausible, but why removing one of the accelerometers? audio amp? nor? ... I don't see why to remove one of the accelerometers and have added so to the Discussion tab. For this you have the actual GTA02, I'm not an expert at all, but keep things simply is always a good Idea , and as they sayd is not pretended to have a production ready phone, but all the learning done in the way of do this simply phone can help to start a more complicated design, even with gyroscopes, compass, a full kitchen and swimming pool if it fit the case, but now I agree in do this a simple but powerful as they can, and even if they finish with something looks like this[1] but with functional GPS/WIFI/BT/GPRS/CIR/SIR/USB will worth the effort For me, I think you've hit the nail on the head. We're trying something new with gta02-core, and by working on the small changes we've proposed we can focus on the tools that we use, the organisation of individual contributors and the stages we need to go through to get functional hardware. Doing gta02-core means that we should be able to move forward fairly rapidly and shake out any problems as we go. For that aim, the specific changes we make are almost arbitrary - and as stated on the wiki we don't expect this to turn into production hardware. My hope is certainly that we'll be in a position to design a more interesting device once we've finished with gta02-core, having established a hardware community and process for making those design decisions. We'll also be in a better position to discuss part availability with suppliers (or project sponsors), if we've demonstrated our ability to 'create' as a community. There's definitely plenty to do, so it would be great to see anyone interested in helping with hardware construction or review on the gta03 list. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Toni Mueller wrote: They chose a 100% GPL layout tool, KiCAD (http://en.wikipedia.org/wiki/Kicad), which uses only text-based files This sounds good, but you seem to require a certain minimum version of Kicad, right? Checking out from OM and running Lenny's Kicad produced less-than-satisfactory results... Either the repo is broken, or the software is. Some clarification would be nice to have! I'm currently using 20080825 (latest ubuntu package), and Werner is on the svn bleeding edge - both seem to work with the current repo. It's early days, and we are still experimenting with KiCad to work out how best to use it collaboratively - so there may be things we need to change. Come over to the gta03 mailing list and we'll try to help with the specific problems you're having. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
