Re: [gta02-core] Openmoko Beagle Hybrid
Dr. H. Nikolaus Schaller wrote: There is now a new Wiki page for the project: http://wiki.openmoko.org/wiki/Openmoko_Beagle_Hybrid Kewl. But where's the duct tape ? :-) I have received some questions why we did not put all this into a nice design. The main reason is that we can't redesign the Beagleboard (it has fixed dimensions) and we can't afford to build plastic injection moulds (if someone has an idea how to reduce cost this is very welcome). Low-volume injection molding should be quite affordable if you provide the cast (aluminium) or at least a machine-ready design. Of course, if you have to pay for the entire design work too, things will get expensive. However, you may also want to consider making the parts directly, without going via a cast. This is much more expensive for larger quantities, but if you only need a handful of cases anyway, it should be more efficient. The issue then becomes access to equipment and experience. I think making a simple case should be little more than a weekend project for someone who's set up to do such things. The challenge seems to be to find such a person, or - if you're looking for an exciting new hobby - to become one :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: Soldering experience is definitively required. The QFN chips (gyros and compass) are somewhat difficult to handle, but you can reflow-solder them in a pizza oven. An approach I found quite efficient for occasional DIY of QFN parts on home-made PCBs is to apply a generous amount of flux to the PCB's pads, coat them all with a thin layer of solder, clean up with alcohol, add flux again, place the component, then solder the component's pads one by one while tipping a tiny amount of solder on the traces leading to them. The solder under the pad will liquify and help to make contact. It's not perfect, so you still get all the joy of testing. But it doesn't require anything but the most basic SMT-capable setup, i.e., a soldering iron with a fine tip, solder, flux, and a good desoldering braid. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: why not xip?
Bartlomiej Zimon wrote: I want ask why we not use execution in place? At the risk of maximizing technical accuracy while minimizing usefulness of the response, this is of course precisely what happens when you boot from NOR :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: we are proud to release a hardware extension for our beloved Freerunner: a navigation board! Very impressive. Congratulations ! I guess the next level would be to make a board that fits into one of the Embedded Air (tm) pockets also have some RF transceiver ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: Well, I've got a lot of other crazy ideas to fill these pockets, I just don't have enough time to realize them all. Wow, I would have never imagined that anyone else could experience this problem, too ;-) Do you have any specific requirements which I should take into account? :) Hmm, how about must not interfere with GPS operation ? ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git.openmoko.org / GTA02 kernel sources?
Sean Moss-Pultz wrote: We [...] pay Gismo a monthly salary to maintain things for us. Thanks for clarifying and thanks for your continued support of the Openmoko community ! - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git.openmoko.org / GTA02 kernel sources?
Dr. H. Nikolaus Schaller wrote: That also raises more general questions: I asked Joachim. I hope I got the details right: - Openmoko Inc. still pays for the domain and the openmoko.org servers. - The openmoko.org domain is owned by Openmoko Inc. - the name servers serving the openmoko.org domain are Harald's or from the Netfilter project - As far as I could puzzle this out, the servers are owned by Openmoko Inc., however, Harald and/or Gismo would get notified if anything was to happen to the servers. - The openmoko.org servers are managed by Joachim and Gismo, in their spare time. (The physical machines are at Hetzner.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git.openmoko.org / GTA02 kernel sources?
Dr. H. Nikolaus Schaller wrote: Some fast guys were able to copy many files from the Googe cache but the Wiki war mostly lost. Somewhat unrelated, but I wonder how the git-wiki projects are doing. http://github.com/minad/git-wiki/network is supposed to give a clue where the action is, but I find it somewhat confusing. (I guess it would be much more useful if it only had a zoom ...) http://git.awiki.org/ looks quite nice. A git-based Wiki that also gives access to the repository would nicely solve the backup problem. If the Wiki content is stored as plain files and revision meta-data lives in git only (and its consistency is therefore ensured by git), this would even allow for editing of the local copy with commits from the command line, finally eliminating the evil Web-only interface. Not sure if the git-wikis work like this, though. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
of books and pads (was Re: community Digest, Vol 179, Issue 23)
[ Let's use a meaningful subject. ] Christoph Pulster wrote: The format Pad is no new idea. The industrial product range use it since many years. This is, by the way, one sector likely to be able to limit the complexity of tasks, as I described in my previous post. In fact, the possibilities and mechanical complexity of a laptop would just get in the way in many cases. I consider the idea, that the future of open source hardware could be this: taking high-quality hardware from big players like Apple, which are sexy and free of bugs. But jailbreaking/reflashing the bootloader, installing a free OS. That's the anti-vendor port approach. FSO had high hopes for it. A while back, Mickey sounded disappointed with the feasibility of this. But maybe things have gotten better since ? I did my share of reverse engineering as well. It's not so bad if you have plenty of time, the device isn't overly complex, and most of the functionality is already openly documented. E.g., for the Psion S5, we had documentation for the SoC, we left all the hardware bringup to the native operating system, and we got leaked information for their custom ASIC. We figured out almost everything we needed to know. Storage (CF) was a bit shaky but still usable. Phones are quite a bit more complex. Also, there are areas where you're currently unlikely to get proper documentation, such as the modem. So you need to plan around them, e..g, by substituting a highly integrated solution with a SoC without modem plus a black box modem. There is little reason for a manufacturer of Closed phones to make such a choice. So you won't find any mass-market devices that do this for you. There are other components where you can choose between Open and Closed. If Open is not a design objective and you're used to sign lots of NDAs (or you have blanket NDAs with various chip makers already), the decision may be fairly arbitrary. Thus each chip lowers the probability that the overall design will be Open-friendly. That's why I think it's indispensable to be able to choose which chips you put into your design, and to negotiate with chip makers before selecting components. Once you've committed yourself, it's nearly impossible to change the conditions. (In Openmoko alone, we have two examples: GTA01's GPS and GTA02's WLAN. In a university project I did some years ago, there was a competing project from another university. We had insisted on permission to GPL our driver, while our competitors accepted an NDA that didn't let them. Ironically, even after we released our driver they never managed to get that NDA changed.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Kosa wrote: I ain't no expert on this, but since iPad is being a succesful mobil device, we could give a chance for a BIGGER Freerunner. The joy of the Open Design Hardware concept - anyone can design their own mutant :) There's a huge market for the big touchscreen devices. Let's see how the Newt^H^H^H^HiPad goes. Wouldn't be the first device to end up in the gadget graveyard after the novelty effect wears off. I guess a bigger device is easier to build BTW. Having a larger case gives you more freedom, yes. Designing it as an offspring of a phone would make it attractive to use much of the same technology, though. After all, you've already debugged it, know where to get the parts, etc., so there's probably little to optimize from the engineering point of view. A larger screen may be a problem, though, if it also comes with a larger resolution. The larger the resolution, the more pixels the poor CPU has to push and the more memory bus bandwidth is eaten up by refreshing the screen. Of course, 640x480 would still look quite tolerable at, say, 6 (133 dpi, like the original Eee PC), so you may be able to avoid this issue - and be able to use cheap screens. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Carsten Haitzler wrote: no news there and no solution to is unless you design your own gpu... good luck. :)) I'd worry a lot more about GUI and applications than about any bit of hardware. Pads in one form or another have been around for a long time. So far, they weren't particularly successful. The promise of the pad is basically that there are many tasks, either new but useful (and beyond what a smartphone could do) or traditionally requiring a laptop, that can be formulated such that all the interaction they require are a few taps and drags. Maybe the iPad will be able to do this. Maybe not. We'll see. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Carsten Haitzler wrote: if it's hard to communicate - you don't have a sales point. Yup, that's why I wouldn't belabour that angle for now. Whether and when the time for selling on open software alone will come depends on how constrained people feel with the non-open choices, and how many indirect benefits they get. For now, I'll be happy with the niche of project customers who need to tweak the hardware or who already understand why they cannot afford a closed system. That said, such a phone wouldn't have to be free from appeal to the mass market. It should definitely be as attractive as possible, but within reason. sure - but it seems those project customers want to feed off a stable supply line Stability is indeed crucial. I hope to be able to compensate with flexibility what we lack in sheer momentum. E.g., if you get, say, Motorola to make a design for you, and then Motorola decides to shut down or sell off that business unit, then you're left with pretty much nothing, no matter what your contracts say. With an open design, no mattern what happens with the makers of it, you still have the design - down to the last detail - and most of the information needed to produce it. You may still fail to recover from a breakdown in your supply, but your chances are vastly better. Also, since the supply is likely to be spread over multiple companies and individuals (who, in the Open world, enjoy a great deal of mobility) catastrophic failures that wipe out everything are less likely. Now, it remains to be seen whether prospective project customers will agree with these arguments or whether they prefer to stick with the traditional view and try to partner with companies that are too big to fail. In terms of numbers, I think cost levels out pretty well already at only a few kunits. If you're competing on the last 5%, you're already in the wrong game. i know that to you, or to many freedom advocates all this fancy eyecandy, sexy design, high end components etc. seems all irrelevant Heh, yet here I am, still using my sleek little Samsung X-830 as my daily phone, while keeping the ugly pucks in the lab :) The thing with bleeding edge components is that they cost you a lot (in various ways) at very little gain. Yes, you may get that extra push for today's fashionable effect, but by the time you hit the market, fashion will have changed. Better find your own style that doesn't come from the manuals of the Gigahertz war :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customer
Jon 'maddog' Hall wrote: But if you are making your phone out of beginning of life components that other people are also using and that have a bit of life to them, you can sometimes get some components without having to buy 10 million of them Hmm, there is an opportunity around beginning of life, namely when the product doesn't have (enough) big (enough) customers yet. At that time there's a chance to become a partner who makes a reference design to help to spread the word. After that, it gets difficult for a while, until the big guys have had their fill. Let's call the stage of life that follows mature. What I'd aim for are mature chips. They're not brand-new, their quirks and shortcomings are known, documentation may have leaked, someone may even have written drivers for them already, you can get them in small and large quantities, they still have many years of life in them, and you can already get a glimpse of the roadmap beyond that chip. Not that I would sneer at a good opportunity to use some fancy new chip, but I'd make sure not to depend too much on this. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The Origin of the Freerunner Shape!
Dr. H. Nikolaus Schaller wrote: I have finally found where the shape and visual appearance of the Neo1973 and Freerunner come from: Close :-) I've been told that the case originally came from a phone intended for the Chinese Olympics. The rounded form would mimick the outline of the Olympic rings. This probably also explains the rugged design. As far as I know, that phone never made it to production and the Openmoko project then inherited the device, radically changed its internals, and so on. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Dr. H. Nikolaus Schaller wrote: In business strategy planning it is quite common to separate e.g. consumer, project, service, solution business types and markets because they have quite different requirements and attitudes Yes, I was familiar with the concept but I didn't know the term project customer. I used terms like integrator and similar, which cover only part of the activities. Project customer is much more precise. I'm happy I finally found the word for them :) At least one visitor during our presence at the SYSTEMS 2008 fair expressed he is interested in 6 units [...] Hmm, if we assume a contribution towards RD and QA of about USD 50 per device, that would be 3 millions. A while ago, Maddog and I did a rough estimate of how much it would cost to make a new phone, similar in style to gta02-core, but with updated components, etc. We came up with a cost of about 2.5 millions before production (but including transfer, certification, etc.). This visitor may be one of those who would have enough resources to have their own design made (*), but may not realize it. (*) With the proviso that modules are used for most or all the RF parts. A design with RF components at the chip level would add difficulties and increase development cost. So for successful project business, one must either provide a product that is available for 5-7 years or at least a consistent roadmap/upgrade plan. I think either is very difficult to provide for an entire device using mobile phone technology. But I think that much of the push towards technological change can be buffered by having an Open design - one may not be able to avoid changing the bare metal, but interfaces and the software layers above the hardware can live as long as anyone cares to keep them alive. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Carsten Haitzler wrote: day. openmoko never made it to be big enough to continue - and ye once you get big enough, the kind of thing you talk about no longer make business sense (as you are busy shopping around to telcos who will order millions of devices). catch 22 :-S This is where an Open hardware design can help :-) No matter which role you play, you always have the purchase power of the whole group behind you. Openmoko Inc. found many doors open that would normally be closed for such a flyspeck of a company, because it promised manufacturers access to the Linux market. The Open hardware design also increases the scalability - the small garage company that makes 100 customized phones for the local shopping mall has access to the same design resources and can have access to much of the production resources as the largest member of the group. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Carsten Haitzler wrote: too late for that. the others are in on the game. and now being open enough is all that's needed. window of opportunity for om and the likes has closed - or at the best is very close to closed. I think the advantage is still there, it's just harder to communicate. Also in this regard, Open Design Hardware helps: you still don't get anything like this from the now open players. And from what I've heard and keep on hearing, there are lots of project customers who want to modify the hardware. They often also have the engineering resources to perform their changes. But also doing the rest of the phone would be too much for them. The Open phones would be sort of a reference designs created by the Open hardware development process, but not the one and only results. depends on who is buying the units to make it scale - if it's a telco, chances are they want it far from being open - that includes the hw design. chaning that doesn't come from a small company like om screaming. A small telco may be happy enough to finally be able to brand their products, too. I wouldn't try to deal with large telcos for now. Don't sleep with a girl who eats more than your own weight for breakfast :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customer
Christoph Pulster wrote: Good luck. Maddog made a lot words about the Brasilian universitary which should continue the Openmoko project. Nothing happend. I think it's Sao Paulo you're talking about. USP never promised to continue the project (even though the press may have mis-interpreted this) but to give gta02-core free use of their SMT line, which is more than generous by any standard. It's not USP's fault that nothing happened so far. We still need to obtain the components, make the layout, produce the PCB, and only then we can use the SMT facility at the university. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Dr. H. Nikolaus Schaller wrote: We also had many discussions with project customers and basically they were happy with the device. And would prefer it over any consumer oriented device. Are there actually any stories of project customers whose project made it past the RD stage and who deployed a reasonably large number of devices, let's say = 100 ? I'm not aware of any, and that's bothering me a little, for it weakens my theory that project customers (I haven't heard this expression before Christoph used it, but I like it very much) would be a major market for an Open phone. It could be that the combination of long-lived problems and a short-lived product or series just left no window for this to happen. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Christoph Pulster wrote: As you already said, companiess who built a solution based on the Openmoko need a reliable product AND a reliable company behind. Hmm, I think you're right that there has to be a company that buffers the customer from the increasingly chaotic (*) inner layers. However, I'm not sure this company has to be the manufacturer or owner of the product, nor that there would have to be just one company in this buffer role. E.g., I could easily imagine a consortium grouped around an open design. That's one of the possible directions I see for the work we've started with gta02-core. Such a consortium could be much more reliable than a single company. If someone drops out, others can fill the gap. If the consortium as a whole falls apart or veers off course, anyone can pick up the design and continue producing it. You can even have mobility at the level of individual engineers. So the product would live as long as there's enough interest in seeing it live, much as it is with Open Source software. Also, if we consider project customers, many of them have needs the current market offerings cannot satisfy, they usually do have technical competence, and they have some money. What they don't have is the size and pull to just create the product they need from scratch. Now, there are many roles they could play. They could be just customers. They could take a more proactive role and be part of such a consortium. Or maybe they're even underestimating their potential and would actually be able to take the lead in creating such a product from scratch. They just don't think they could. (*) Chaotic, not necessarily because of a lack of structure, but simply because of the amount of information going around and because there will invariably be a lot of horrifying news that don't have much of an impact in the long run. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA02] clock reset on battery removal?
Paul Wise wrote: Yet another hardware design issue I guess, I'm quite surprised there isn't a small battery to power the clock like in PCs. There is. It's called the backup battery. It's the small button next to the front speaker. Strangely, this battery has a very pronounced death wish. I.e., in a recent survey, something like 33% reported that their backup battery can't hold a charge for any useful amount of time. (I don't remember who conducted the survey. Joerg told me about the results.) It's not clear what causes the backup battery to perform so poorly. It could be a quality issue, it could be a manufacturing issue (*), it could be incorrect use in the GTA02 design, it could be a usage pattern of the user that subjects the battery to unexpected stress, etc. (*) We had backup batteries die like flies at some point in time, GTA01 or early GTA02 prototypes I think, because they were not compatible with the soldering profile. However, the battery was replaced with a sturdier one, so this is supposedly no longer a problem. In general, I think it would be good to avoid assuming that the backup battery works. There are many potential time sources around, GPS being only one of them, so I think a distribution that detects a loss of RTC could cushion the effect in many cases. There are also time sources that are exact but have an unknown offset, such as the time provided by some GSM providers. When the system has a know to be good time, it could identify and record the time offset, and use this information later to derive the correct time from this kind of source. Just throwing ideas in the general direction of the middleware folks :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: beautiful qt based
Christoph Pulster wrote: project customers: gone, disappointed of all the bugs and problems Whether the bugs and problem really bother project customers should depend a lot on what their specific plans are. E.g., if they plan to have their own user interface anyway, they wouldn't care much about any flaws in the existing ones. However, if I was a project customer, what would scare me most is that the hardware is no longer being produced and that there's no follow-on product I could switch to. The more a project customer plans to invest into the platform, be it in units purchased or in their own development effort, the more they need the assurance that their effort won't be wasted. A product that's already discontinued makes a horrible basis for this. So I'm not exactly surprised that you don't have hordes of project customers banging at your door, begging for more FreeRunners. lets wake up, the game is over :-( It's always nice to compare the views of the distributors. Hmm, what kind of movie character would best reflect the typical attitude of each ? :) How about - Pulster: perhaps Marvin the Paranoid Android ? - Golden Delicious: definitely Angus McGuyver - Tuxbrain: I'm struggling with this one, Sister Mary Clarence ? - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
project customers (was Re: beautiful qt based)
I wrote: So I'm not exactly surprised that you don't have hordes of project customers banging at your door, begging for more FreeRunners. Perhaps I should clarify that I don't mean to make fun of your situation. We're all in the same boat here. But I think it's important to be aware that this kind of completely non-technical issue can disqualify the product for project customers. The irony here is that the openness as such would be a very strong point in favour of something like the FreeRunner, especially for those with long-term plans, and it's sad that we (as in those who believe in the ideas behind the Openmoko project) have missed this opportunity so far. Of course, where something isn't right, there's also an opportunity to do better :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AAVA Mobile?
undrwater wrote: I'm wondering if this is a re-badged product discussed here previously, or something relatively new? Looks like something new. It isn't quite clear to me what semantics they attach to Open, in particular whether the openness is supposed to come from the mere fact of being an x86 platform and inherently PC-ish, or whether it also means an absence of binary kernel modules and similar kinds of joy. Or it could just mean that they'll license the design to anyone, which would indeed be more open than anything else on the market, even though at a different level. I'd also be curious about battery life. If they've indeed managed to make an x86-based phone with a battery life that compares to a good ARM-based one, that would be very impressive. There's of course also the question to what extent x86 matters for mobile phones today. In terms of processing power, already ARM seems to offer more than enough for most purposes. In terms of compatibility, they don't seem to aim for straight PC-compatibility anyway, and the concept of an app store, having been given a very pronounced shape by Apple, has changed the landscape. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Thone 0.5
pike wrote: And today is a nice day to release what I have http://wiki.openmoko.org/wiki/User:Pike/Thone Looks great ! Finally a UI that's friendly also with users who are hackers ;-) It would be nice to avoid modal dialogs, like the one in $TH_MENU_SMSREAD. Why not simply remember the last message read and have commands del(ete), re(ply), n(ext), p(rev), etc., that operate on whatever was the last message ? mh worked like this, and it was quite nice to use. sms read can still print a hint what commands may be useful next, but without a modal dialog. (As an advanced feature, there could then be an option for an expert mode that turns off the hints.) If there's an undo, you also don't need to ask before dangerous operations. By the way, regarding overlay keyboards, in cases where fatfingershell is too crowded or narrow, perhaps the following approach may be worth considering: - use a 4 x 6 grid (or similar) - use the keys on the leftmost column as modifiers, e.g., with the following functions: - Left: use left half of the keyboard - Shift: shift, pressed in combination with Left and Right - Right: use right half of the keyboard - Fn: special functions/characters - for the remaining positions, select the layout according to the modifier(s) pressed Typical use would be two-handed. E.g., if we assume a split through the middle of a regular keyboard, we'd get something like this: Modif. LeftRight -- - - Left1 2 3 4 5 6 7 8 9 0 Shift Q W E R T Y U I O P Right A S D F G H I J K L Fn ? Z X C V B N M ? ? ? is something non-alphanumerical. Space, Enter, and Delete come to mind. We can use Shift+Number for special characters. To type Hello, one could - hold Right+Shift then tap H - hold Left and tap E - hold Right and tap L, then holding Right tap L again - keep holding Right and tap O If modifiers are sticky, also single-handed use would be possible, but slower. Right+Shift could correspond to a location somewhere around the bottom of the Shift area, or a transition of in Right to between Right and Shift (rolling the finger.) The multi-touch effect would be possible because touching positions X and Y looks like a touch at a position in the middle between the two. A sequence like Left-E would then look like this: - press somewhere in Left (let's call this vector X, from the origin) - point moves - without releasing - somewhere near the top of W or Q (let's call this vector Y, from the origin) - we calculate the real second position as X+2*(Y-X) Just an idea for whichever April 1st is next :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Whither open hardware ?
Dave Ball wrote: What's the yard stick for measuring against here? I.e. are we talking about one-off from digikey/farnell, samples direct from the manufacturer, or limited-run (couple of hundreds) quantities? For the full process from RD to mass production, you need to have channels for small, medium, and large quantities. First just a few to figure out if and how the thing works. Then hundreds for the prototypes, and finally thousands for mass production. If a part is available from Digi-Key or a similar distributor, this helps enormously to accelerate RD and it can also help when in a pinch in a prototype run. - what are the integration costs ? is this things like placement of awkward (small pitch etc.) parts, FPC's etc., or ancillary parts such as partner chips? Depending on the part, it can be all of this and more. Requirements on the PCB and the SMT process, partner chips, extra voltages, mechanical and thermal issues, drivers, and so on. Examples: - if a new component reduces the minimum pitch or has a higher pad density than the rest, your PCB may get more difficult to make, possibly resulting in higher cost, a smaller choice of companies that have the technology, higher lead time, and so on. - some components have an unusual reflow profile, e.g., batteries (don't like the heat) or complicated BGAs (have to make sure even the most inaccessible ball reflows correctly). - CPUs have long lists of requirements on their power supplies and their sequencing. E.g., it was quite a puzzle to figure out how to make the 2442 with with the 50633. - extra voltages: some chips inexplicably want something slightly different from 3.3 V. There goes another LDO. - mechanical: need to find suitable space. Electromechanical components also need to interface mechanically, which may affect the shape of other elements. - thermal: don't cook your neighbours and don't be cooked by them. Also, some special layout may be needed to get the heat away from the chip. - let's not forget the software. If a chip needs a driver, that one has to be written, debugged, and so on. This also implies what one needs sufficiently open documentation, which can require a great deal of negotiation. Is the normal route of sourcing via a factory (even for prototypes etc.)? From a few searches it seems that getting hold of some parts (i.e. screens / touch layers) is incredibly difficult for one-offs. For the easily obtainable parts, you have many choices. Small quantities you get from Digi-Key, even if it's expensive per piece. Perhaps even medium quantities, if you don't already have a better channel. Large quantities, you get from the official distributor. If you're willing to take some (small) chances, you can also use other channels, e.g., to bring down lead time. Parts that are hard to get require contacts, muscle, illusions, or someone who can lend you some of these. You normally negotiate the whole package, so you don't only get samples but you also at least talk about the larger quantities you'll need in the future. For prototypes you want fast turn-around times, so involving a mass-production factory may not be such a good idea. They can do sourcing, but their mode of operation may not include quick changes and such. (E.g., GTA01 was prototyped in Taipei, GTA02 had many prototype runs at the MP factory, a process that was agonizingly slow and had a huge overhead, GTA03 was prototyped again in Taipei.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maintain(er) OpenMokoProjects [was: Openmoko projects page down]
Michael Pilgermann wrote: the OpenMokoProjects page is back online - thanks to whoever did this. That would be Joachim. I'll add my thanks too ! Unfortunately, there still appear to be problems with accessing certain directories, and nobody seems to have an idea (so far) how to solve these. But in fact, I got a bit concerned about carrying on to host my projects there. What is the status of this site - and who is the maintainer? As far as I know, Armin Ranjbar is in charge of the administration of the projects (approval, etc.), but there doesn't seem to be anyone who's clearly in charge of running the infrastructure. (I might be wrong, though. Corrections welcome.) Now, GForge doesn't seem to be a particularly friendly platform to maintain. At least I gather this from the amount of invective uttered by those trying to fix it :-) Considering alternatives, we could also look at the things we already have in the Openmoko universe. For example, we have a mailing list processor, a bug tracker, an SVN, a git, and even a web-to-SVN gateway (with limitations). I wonder if each project really needs to have its own copy of each of these, or if we could share and pool some resources. These central services used to be for official Openmoko Inc. projects, but now that it's all in the hands of the community anyway, there's little need to maintain this distinction. The rate of new project registrations is not particularly high. Last year: jan 17, feb 8, mar 6, apr 9, may 5, jun 5, jul 5, aug 1, sep 1, oct 2, nov 1, dec 2. So it may not be worth the effort to automate these tasks. (I don't know the rate of membership changes, though.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Maintain(er) OpenMokoProjects [was: Openmoko projects page down]
Michael Pilgermann wrote: - for the gforge page itself: I am thankful for all the explainations about responsilities regarding the site; however, nobody has yet came up to say: it is me to deal with these problems. The implied meaning of these explanations was of course that for any prospective volunteer who's good at taming GForge but has kept quiet so far because everything seemed to be so well under control, now would be an excellent moment to speak up :) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Whither open hardware ? (was Re: Quick e-mail poll: Still using your Freerunner?)
Ken Young wrote: My two cents: If I were dictator of the gta02-core team (instead of someone who doesn't even contribute), I would repurpose the device as a GPS PDA. I would remove all the radio components except for the WiFi, and try to optimize for the longest battery life possible. Companies who were looking for a device for some project often asked Openmoko Inc. if they could have a GTA02 with some features removed or with other - often small - changes. Unfortunately, Openmoko Inc. did not have the resources for making such derivatives. However, this is a promise the approach chosen for gta02-core holds: with the whole design out in the open (Open Design Hardware [1]), anyone can independently define, implement, and produce derivatives. [1] http://people.openmoko.org/werner/openness/odhwdr-v1.pdf This doesn't mean that everyone is forced to fight all alone. To the contrary, there are many possible synergies along the way that are not visible as such in the traditional product development process, such as shared sourcing or shared manufacturing. For example, if you want to make your GPS PDA, you may choose a set of changes that fits your budget, e.g., by staying with the overall platform and physical shape but removing subsystems you don't need. When it then comes to sourcing components and manufacturing, the same facilities used for making the phone could offer their services also to your project. The incremental cost for them would be very small, much smaller than running a completely different product of similar complexity. Also the core company (or whatever form of organization) in charge of the base design would benefit. If it has spare engineering resources to put into derivative projects, it can choose to do so, favouring projects that best suit its agenda. If not, others can help out. Thus, the business opportunity is not wasted - it only goes to someone else you could think of as an ally. Even better, resources that can be shared contribute back to the whole ensemble of projects. E.g., if your PDA is wildly successful, sourcing may be able to get much getter conditions for parts than they did with just the phone. Or a new type of subsystem gets researched and is then available as a possible building block for the entire architectural family. Thus also the phone benefits. Now some may say that this is crazy and that anyone handing out designs so liberally would be robbed by competitors. In my experience, it's surprisingly hard to get people to steal your cool new ideas. Eventually, the thieves and parasites will show up, but you have to be successful for an awfully long time before they even notice you. [...] but rather to point out that there is really no hope at that a group of people such as the gta02-core team, working part time with no large corporate sponsor, will ever produce a product with hardware on a par with what the big players are contemporaneously offering. I agree on the point that there's no hope to mass-produce a phone without suitable resources. The resources don't have to be in one hand (e.g., you could have a consortium of entities each contributing their own capabilities and splitting the proceeds), but they have to be available. However, I don't think it's necessary to compete on leading edge technology. Often enough, less advanced components will yield an equally satisfying product. Besides, companies that don't have the sexiest product in their sector of the market are often much friendlier towards openness than those who do. Please don't take the poor performance of GTA01 or GTA02 as too much of an indicator of what second best can do. Both are based on very conservative designs (e.g., no DDR) and GTA02 has two thirds of its high-throughput peripherals share an incredibly slow bus. (Think of a first-generation PCI-based PC where someone chooses to use ISA cards for video and the SCSI controller. Would such a system properly represent the typical performance of the PCI architecture ?) The 2442 is now about five years old, and it shows all over the place. In an updated but similar design, unlike gta02-core suitable for mass-production, I would use something like the 2450, which has high-speed USB, 2D acceleration, and other goodies. In contrast, I think there still might be an unexploited niche in the GPS-PDA arena. I think there is a whole universe full of unexplored niches. It's hidden from us by a tall wall called high cost of entry. If we can find ways to lower that wall, a lot of interesting things should happen. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Whither open hardware ? (was Re: Quick e-mail poll: Still using your Freerunner?)
Laszlo KREKACS wrote: Is it unsuitable for a phone because of power inefficiency? Can be the ARM Cortex-A8 600Mhz used in a future phone? There are many component choices for future phones. Things to consider when choosing chips include: - do they fit the intended purpose ? - are they open enough for our purposes ? - are they available (to us) ? - will they be available as long as we need them ? - are they affordable ? - what are the integration costs ? - what are the opportunity costs ? - do they work as intended ? - how do they fit our technical capabilities ? - what legal exposures do they cause ? Of course, you don't see companies advertize much on the issues listed above. Quite to the contrary - how often does one see a feature presented as patented proprietary technology as if this was a good thing ? - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [gta02-core] FOSDEM2010
Dr. H. Nikolaus Schaller wrote: What about GTA02-core? Hmm, no plans from my side so far. I prefer to have something tangible to show when going to conferences :-) There are still a few months until FOSDEM - by when would a decision have to be made ? - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WikiReader
Sean Moss-Pultz wrote: Today, with the greatest of pleasure, I am ready to share with you the birth of our third product -- WikiReader. Yeah, it has hatched ! Congratulations to you and the rest of the team, and I hope that this cool little device will be a smashing success ! - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Internal pressure sensor
Stroller wrote: This barometer is self-contained and connected to the i2c bus, a _relatively_ simple addition. If there is demand for the barometer - although I'm inclined to agree with Rask that there wouldn't be - then it might it be justified to add it were Brazil ever to go into Freerunner production. Here's where Open Design Hardware changes the scenario: if you have an (open) base product, you can design, produce, and deploy small changes for a special interest group at a comparably low price - a bit higher than if the change was part of the mass-produced design, but considerably lower than any traditional alternatives. software installed. The software would have to be closed-source, [... more horror material ...] Why bother ? Even if we assume for a moment that you can't make money selling unencumbered software, you'd have the enhanced hardware already as a kind of dongle. Also, since this would be a highly specialized niche product, I would expect customer loyalty to be high. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Michael 'Mickey' Lauer wrote: The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). Yes, doing less work is the most promising approach here. You can also try to move moredrivers into modules, replace udev, and move to uSD, avoiding JFFS2. (JFFS2 and udev conspire to create a huge startup cost, with udev's expensive initialization and JFFS2 doing its garabge collection at the same time.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel Mode-Setting (KMS) on Neo FreeRunner + Debian
Dan Staley wrote: The glamo.useful? If this work continues...perhaps a rethink of gta02-core is in order?! Hmm, I doubt it :) Use one bitmap that's not cached in Glamo memory and you're back to watching the same old paint dry again. So I still think gta02-core will run circles around GTA02. But perhaps smaller circles now :-) But I have to say that I'm very impressed by Thomas' work. It's not just the acceleration but also the complete overhaul of the driver architecture. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
steven mosher wrote: 2. Build a Copyleft version of the Iphone from scratch. pass me 400Million and I'll get right on it! But you can't just build the iPhone, you have to build what apple will ship 18 months from now to be competitive. Heh, I'd do it for 40 ;-) But I think the fallacy is in trying to mimic the iPhone anyway. The way I see it, Apple took an existing and well-understood concept, added a competently done design, and created an open market for applications. Perhaps the most significant departure from the industry's old course lies in partially superseding the carrier-centric lock-in model. Smartphone hardware, however, still seems to be largely driven by the vision of the video phone. If you trace back the history of the video phone, you'll end up somewhere in 1927 with Lang's Metropolis. Now, if you're making a movie, wouldn't you rather use a video phone instead of a plain old telephone ? After all, you want to show moving pictures and your actors are already dressed up, presentable, and exist in a perfectly scripted universe in which all calls are important and always happen at exactly the right moment. With virtually every movie that depicts an even slightly futuristic world showing video telephony, it's no surprise that some people do start to believe that this will be part of the future ... With that in mind, we could ask ourselves what are the roads not taken in the guided evolution of the mobile phone, because they led away from that perceived holy grail. Then put the creative energy not wasted on chasing Apple into doing something that's really groundbreaking. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
applied sci-fi (was Re: New Open Hardware company)
[ Changed the subject, for we've veered off-topic. ] pike wrote: So, what did science fiction *miss* ? Actually, very little :) One thing that could make voice telecommunication a lot more attractive would be an avatar who listens and understands. Voice mail makes many people uncomfortable because they don't get none of feedback that normally accompanies a conversation. Even voice telephony has that kind of problem to some extent, particularly with large end-to-end delay. A possible improvement would be some sort of avatar that provides these clues and fools the speaker into feeling as if he or she was talking to a real human being. Determining how all this might work would need a bit of research, though. TV fakes continuous motion, MP3 fakes a loss-less reproduction, so I wouldn't be surprised if we couldn't fake a human listener as well with less effort than dragging a real human to the phone. Okay, that's a far-out idea. Something closer to home: if you don't need video telephony, you don't need rapidly updating color images. So, put e-paper into those phones. Maybe even the well-established grayscale type. It probably still updates quickly enough that you could even doodle on it. Oops, have we just eaten a big chunk of the e-book reader market ? So sorry ;-) As an added bonus, you can get flexible e-paper. I don't know how much abuse it can take, but maybe you could hide something that gives tactile feedback under it ? Wouldn't a touch screen that feels as if it had real keys be nice ? I've always been amazed by the 1-on-1 nature of phone calls. Oh, that's been solved already. Even GSM supports multi-party calls. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: applied sci-fi (was Re: New Open Hardware company)
pike wrote: strange, i've never seen it in day-to-day usage. can't do it on my phone afaik ? It's certainly one of the more obscure features :) You should be able to use it by making the first call, then call the next party and join the calls, and so on. Not sure if any of the Openmoko distros support this. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RFC: Open Source Hardware - Disclosure Requisites
Sorry for the cross-post. I've prepared a whitepaper that explains the documentation requirement of Open Source Hardware to component vendors. If you're interested in this topic, please help to review it. The thread about it is on the gta02-core list: http://lists.openmoko.org/pipermail/gta02-core/2009-July/000238.html Thanks, - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
Dr. H. Nikolaus Schaller wrote: most FOSS. Unless we restrict the Non-G-UI to commandline and ncurses. I noticed that is has an escape key. So vi will be fine. What else could one possibly wish for, except that more GUI designers would draw their inspiration from the grace and style of vi ? :-) Historical note: once I had Linux run on my Psion S5 and took it to a conference. The UI consisted of eight virtual consoles with a shell each, with whatever I chose to run there - typically a vi, so I could switch from taking notes on various topics just by changing consoles. Despite the device's many shortcomings, the system felt amazingly productive, almost on par with the HP-100LX. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
steven mosher wrote: A while back Wolfgang mentioned that he and I were starting a new venture.Drop by and say hello. And so it has begun ... congratulations and good luck ! May the source be with you :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [gta02-core] The University of S?o Paulo's intent to join Openmoko development
?lvaro Lopes wrote: But (for example) the gerbers be licensed with a small royalty (1-2 dollars per phone, with a cap of 500,000 to 1,000,000 USD) only if the party will make *over* 5,000-10,000 phones. Interesting idea, but would defy the openness of the project IMHO. I feel a similar uneasiness with this proposal. While these royalties would be extremely friendly compared to what others take, I think they would still limit the power of what is the key differentiator of the whole project, namely the openness. So far, I can think of three areas where such royalties would be troublesome: - they would add a bias that could be perceived as unfair to future major contributors and might set a precedent for an accumulation of claims. - such a license would probably be incompatible with pure CC-BY-SA and similar, discouraging cooperation and limiting the opportunities for reuse (both from and by us). There's also the issue of where you draw the line when people copy only part of the design. - good licenses are simple. The more exceptions and special cases you add, the less comfortable people (and companies) will be with it. There are also many cautionary tales of someone trying to wrap a business model around revenue from an almost Free license, and the whole thing leading to protraced arguments and frustration. So I would rather keep the license plain and simple, and try to generate revenue from the value of the design team's experience, visibility, and contacts. The problem here is we are not developing a state-of-the-art phone. I think it's sufficient to have decent enough hardware. Most of the ubiquituous features aren't all that expensive to have and you gain little by driving things to the bleeding edge of technology. Instead, we can capitalize on the one truly unique feature we offer, the radical openness. This may have limited appeal to end users outside the geek population, but if I was a VAR, I'd kill for it. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The University of S?o Paulo's intent to join Openmoko development
Jon 'maddog' Hall wrote: A copy of Dr. Zuffo's letter of intent is below. I have the original PDF if anyone would like to see it, but it was too big to make it through the community's standards on mailing lists unmoderated, and I thought you might like to see this as soon as possible. This is wonderful news indeed ! Thanks a lot for making it happen ! I haven't had the opportunity to meet Dr. Zuffo and his team at LSI-USP yet, but from your description and the LoI, it seems that LSI-USP can help in several key areas where our community-centric approach is currently weak. I also believe that the openess we pursue resonates very well with the necessities of academic work. To draw a parallel, in the early 1990es, the usual way of sharing one's Unix kernel research was to get a SunOS source license and to distribute object files. With the advent of the free unices (i.e., BSD and Linux), publishing source became the standard, and everyone was happier for it. So, how do we proceed ? As far as gta02-core is concerned, we will need a friendly place for SMT soon ... and we still have that GSM elephant in the parlor. Thanks again for bringing LSI-USP aboard, and welcome to the exciting adventure that is the Openmoko project ! - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New case (was Re: Freerunner's Future)
[ Let's give threads that change direction a clearer name than just Freerunner's Future ] Fabian Sch?lzel wrote: I'm not an engineer, but a draftsman, so I could also help with the mechanical design and modeling of the case and other things related to the project. Great ! I think redoing the GTA02 case should be a project on its own, independent from gta02-core or such. There are no technical dependencies anyway - gta02-core will fit into any GTA02 case and a new GTA02 case can host any GTA02 board. Two considerations: I think just making a case equivalent to the existing one would be an interesting enough task on its own, without adding any changes that aren't motivated by feasibility (machinability, etc.) alone. Ideally, someone who's already experienced the whole process from design to prototype production getting done would take care of coordinating that project. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Adolph J. Vogel wrote: As a new freerunner owner :) and as a mechanical engineering masters student, I think this might be an ideal place for me to contribute to the freerunners future. :) Yeah ! You may even be able to make this count as a semester or final project, or similar. I have done some googling on free cad software, anything beyond 2D is severly lacking behind their propriety counterparts. I will look into them some more, maybe there are some new projects that we can use. The most promising one seems to be HeeksCAD. It has fairly comprehensive CAM integration and can do parametric modeling via Python scripts. Salome also looks quite powerful and is perhaps more mature but appears to lack CAM integration. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery ID chip - help needed
Christoph Pulster wrote: While working out a solution, we get stuck on the point the battery has some coded ID-Chip. This chip is not available on the market. Also the data can not be copied to another IC because its crypted. Hmm, I wonder what that would be or what it would do :-) I haven't actually taken apart a GTA02 battery yet, but what should be in there are some pretty standard Li-Ion protection circuit (note that cut-off voltage and cut-off behaviour can differ among such protection circuits, e.g., the GTA02 battery needs some prodding to come back to life after a cut-off. That's what caused all the fun with the Vsys cap problems.) and of course the Coulomb counter. The bq27000 is a pretty accessible part. You can buy it at Digi-Key. No secret handshake involved :-) Paul Fertser and Joerg have done some investigation on the factory settings of the bq27000, so they may have suggestions for a better configuration. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Jeremy McNaughton wrote: 1. That the open source hardware development processes pioneered by gta02-core get formalized as part of the structure of the new organization There's always room for improvements, so I wouldn't nail down too many details. But the overall goals, i.e., the use of Open Source wherever possible, yes. 2. That the people who are working on the gta02-core will continue to work together as part of the new community organization. Definitely, yes. Of course, the community organization (heh... we need a name!) should encompass more than just hardware. The open hardware part will likely just be a part of what the organization does. Even in the hardware area, there's more than just low-risk implementation projects. E.g., there should also be activities that take on the risky bits and bring them under control. Such pioneer efforts can then be integrated into the next safe design. Also, we haven't touched the whole area of case design and manufacturing yet. There's a number of Free CAD tools that should be up to the task. We've briefly discussed them on the gta03 list a while ago. Also turning a CAD design into a prototype is not an impossible task. There are relatively inexpensive CNC mills (i.e., within the reach of many hobbyists) that should be able to make reasonably good prototypes. Access to mills or 3D printers may also exist through academic institutions or projects like Fab Lab: http://en.wikipedia.org/wiki/Fab_lab I don't know if anyone actually made a case from the CAD files Openmoko released about a year ago. The CAD files themselves may not be directly useful with Free CAD tools except for making very minor changes. But I think a case-making project that follows the same approach as gta02-core, namely reconstructing and prototyping the existing design with Free tools (and making some small changes) could be rather useful for establishing the know-how that can later be used for more ambitious work. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Project B guessing game was[ Re: Pat Meier (=public relation of Openmoko)]
David Reyes Samblas Martinez wrote: * Open Hardware programable Annoy-a-tron 2.0[1] like. (1) [1]http://www.thinkgeek.com/gadgets/electronic/b278/ Sean actually likes pranks very much :-) (Sadly, I never managed to goad anyone into trying the inverted coffee cup prank on him, and when I finally got to Taipei again, I had already forgotten about and Openmoko had tables with which it wouldn't have worked.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Jeremy McNaughton wrote: Scope: What will our mission statement be? Is the foundation just to support the gta02-core project, Just a quick remark: please don't concentrate too much on gta02-core when planning organizational structures for the future. The focus of gta02-core is not on making the next big phone but on opening the process. The few pieces of hardware gta02-core is planned to produce would be a proof of concept that we've succeeded to meet that specific goal but they will likely be of little practical interest to anyone who is looking for a substantial improvement on the GTA02 as a day to day phone. Once gta02-core is complete, there are several paths that could lead to a mass-produced phone. Some could be very quick, others quite slow. Mass-producing a phone requires a lot of money, so at that stage, the direction would also depend on the goals of investors or sponsors and on an assessment of the target markets. An organisational structure should allow us to keep assets across projects. This will also encourage keeping technical projects small and focused. I use gta02-core as a reference when discussion specific needs, because of the project's narrow scope. If a plan doesn't work for gta02-core, it probably doesn't work at all. But a plan that only works for gta02-core wouldn't be much better either. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Linux International and Openmoko
Jon 'maddog' Hall wrote: If the Openmoko community is interested in pursuing this, I would be happy to discuss LI's plans further with you, and how Openmoko could fit into this. I think putting gta02-core and similar projects under the wings of LI is a wonderful idea ! We already discussed some of this a few days ago. Below are some hopefully not too random thoughts on the things a project like gta02-core needs and how they fit with what I think an organization like LI can provide. For technical projects like gta02-core, one of the most important roles of such an organization would be to enter contracts and to maintain rights that exist beyond and across projects. For example, if we need to enter an NDA for some purpose, also follow-on projects should be able to use this NDA without having to re-negotiate it (which can be very difficult if not impossible.) I'm not familiar with the subtleties that distinguish the various forms of organization, and their impact on commercial activities, but I think we can identify a few types of such activities that are likely to be necessary: For projects like gta02-core and possible successors, it would be important to purchase goods (e.g., components), contract services (e.g., PCB making or an SMT run), sell products (e.g., boards or complete phones), and to save some of the revenue for later activities (e.g., purchase of material). Furthermore, it should be possible to hire or contract people for roles that are beyond the scope of mere volunteer activities. The international chapters certainly resonate well with the global interest in open phone development that we've experienced with Openmoko. Regarding international members, is there any special paperwork they need to do to join LI as members or to perform tasks in which they represent LI (or a sub-group ?) to some extent, e.g., negotiate a contract ? If none of the items above raises a red flag, I'd say this should be an excellent match. The experience of LI would help projects like gta02-core to establish a solid organizational framework, and the prominence of LI would help gain visibility, attract participants, and open doors for industry contacts. When these bustling projects are successful in bringing openness, both for hard- and software, into new areas and to new users, this would in turn be just what LI aims for. So I'd like to thank you for the invitation, and I'm very excited about the prospect of joining forces with LI. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Paroli introduction video
Laszlo KREKACS wrote: http://www.vimeo.com/5029019 Lovely retro style. Bleeding-edge technology meets the silent movie. Finally, there's a worthy successor for Metropolis :-) Someone should make a piano track for it. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New list: gta02-core
[ Cross-posted to the community list, since there's been a lot of discussion about future projects as well. ] A few people have voiced discomfort with the gta02-core project dominating the gta03 list, and I have to admit that having us squat there was more an act of opportunity than a good choice. So please welcome the brand-new list dedicated solely to the gta02-core project: https://lists.openmoko.org/mailman/listinfo/gta02-core The gta02-core project aims to create and test an open prototype development process for phones using the design of the Openmoko GTA02 FreeRunner. This will not be the next big open phone, but it should provide a basis for making the hardware of one, using a development process that is as open as we've come to expect from Free Software. Please send new postings related to gta02-core only to the new list, and copy replies to gta02-core-related postings on other list to both lists, until the current threads all have moved. Thanks, - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Dale Schumacher wrote: If the concerted efforts of many talented (in some cases even paid) engineers couldn't achieve that basic milestone, it seems unlikely that it will be achieved by a loosely-organized group of unpaid (and demoralized) volunteers. You can view the situation also as an opportunity to change some of the structure of the project. Openmoko Inc. had certain constraints due to the way it was conceived. Some of them looked good at the beginning but later caused problems - yet were too difficult to change. The good thing about a new start is that you can stop fighting the mistakes of the past and turn your full attention towards making new ones ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Christoph Pulster wrote: I see ONE active Mailinglist (here) and nothing more worth to mention. openmoko-kernel used to be very busy. Now it's a bit more quiet with kernel maintenance being rearranged, but I expect it to pick up some more activity again before too long. Also, these days, the most active participants all use IRC and much of the small coordination happens there. The GTA03core list consists of 5 active people feeding some strange CAD software, gta02-core is a very young project and I'm rather pleased with the way it's growing. There are 1-2 people joining for active participation every week, and some more are just lurking for now. If active participants joined at a higher rate, it would actually be difficult to give them the attention they deserve and to integrate them into the project. (In fact, I already built up a bit of a backlog for this week. Shouldn't dwell in this mail too long ...) If you don't like the strange CAD files, you may find http://people.openmoko.org/werner/gta02-core/gta02-core-expanded-all.ps.gz easier on your eyes ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fundamental Qi question
Laszlo KREKACS wrote: I use the distribution on NAND as an SD card reader. Hmm, I think we have to distinguish between things you can do and things that actually make sense here ;-) Once you've started to fill the niches, it's always unpleasant to change. That's one reason why it's difficult to make architectural changes like switching from a NAND-centric approach to an SD-centric approach once a system has been deployed. But in a new system, features should be open to evaluation, and if one can accomplish the same tasks in a simpler and cheaper way, that only helps to make the product stronger. The problem with NAND is that it's no end of hassle. You need a complex boot loader to use if fully, you need an in-system recovery architecture, it needs special partitioning, you have to deal with unusual error patterns (factory-bad blocks and wear), etc. An SD-centric design does away with all this and brings the whole architecture much closer to what you find in a PC. I.e., the analogy SD == disk holds true for most purposes. So you don't need to learn a whole new set of methods and tools to perform routine tasks but you can just handle them exactly like you'd handle a PC. For your SD reader scenario, there are actually two solutions: - you can just have a small system on the SD card that boots into an initramfs. Once the system has been loaded, you can remove the card and insert another one. - USB microSD readers sell for USD 3 and make a nice addition to the travel accessories bag for each laptop that doesn't have an SD slot. and I write the new distro to the uSD card. It is impossible to do it on the same SD card, from where the OS is running. You cant simply repartition the uSD card. Why not ? Just get a big enough card and partition it before using it the first time. The total cost of a card with several GB is likely to be much lower than that of those few hundred MB of NAND. (It's not only the cost of the chip per se but also how this constrains the choice of packages, complicates sourcing, production, and all that.) Furthermore, I used recently TangoGPS, and it broke the filesystem where the maps were located. It broked every time when the phone runned out of battery. Hmm, frequent data loss looks like a problem that needs solving anyway, whether there is NAND or not. Does your user space attempt a shutdown when it notices an imminent low battery condition ? I see only one alternativ: two uSD card slot. That's actually an attractive feature anyway. Basically one acting like a hard disk and the other one like a USB stick. Thinking of it, you can actually do this already if you have a suitable cable, since the USB port can be switched to host mode. I think I made a fair point, so please save an emergency path. The design of a typical Qi system (whether NAND-free or not) should include a partition with an small user space for the boot menu and just this sort of recovery environment. There's no disagreement that you need this sort of functionality, there are just better ways to do it than to use NAND :-) Ah, and to recover from a truly catastrophic SD failure, there's always the option of carrying a backup card. There are also failure modes where you're much better off with SD than with NAND. E.g., if your device fails completely and needs to be replaced, you can't backup your NAND if your device is broken, while you can usually still remove your SD card and access it with another computer. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fundamental Qi question
arne anka wrote: - what reasons make you say, sd is the future? The main reasons are: - much easier handling. SD is like a disk, so you can use all the standard tools and get standard behaviour. NAND needs a lot of exceptional treatment to properly address wear and factory-bad blocks. I.e., you can't just pretend it's a regular disk but need special file systems, special tools, special partitioning, and all that. - the price/performance point of SD is set at the time you buy the SD card while that of NAND is set when the device is designed. So NAND always lags behind trends in capacity growth. - if all the data of a device is stored on SD, you have a lot more flexibility when moving data across systems. E.g., you could share a phone among people, use multiple phones with the same data, have completely separate work/personal or regular/travel environments, etc. - what reasons, except the impossibility to replace the nand when it is worn out by to many write operations, led to the decision to use nand read-only? The complexity of recovering from catastrophic NAND corruption. With GTA01, you needed the debug board. GTA02 has an expensive and (for most purposes) non-upgradeable NOR chip. With no valuable changeable state in the device, the whole issue of recovering a bricked device disappears, since you can just use a different/externally repaired SD. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Sean, thanks for the update ! It is unfortunate that Openmoko Inc. cannot presently continue to lead the development of the open phone. But then, many a great undertaking has required more than one effort before reaching its goal. Anything that brings us closer to that goal is a success in itself, and the value of previous achievements is often only appreciated in the light of the final result. I'm very glad that Openmoko Inc. has not only brought the vision of the ubiquituous open phone this much closer to its realization, but that you are also willing to help us to ease the transition from a project centered around a single company to a true community effort. In the name of the gta02-core project, I'm particularly grateful to you and the board for supporting this effort with further material and components. This will be critical for enabling us to open up the engineering process with our moderate resources. Alright, I think we all have a lot of work lined up for the future. I hope we'll all have the opportunity to envy each other's before too long ! :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mailing list glitch?
Doug Jones wrote: Has this bug been there all along? Does our community's collective memory have a hole in it? Seems that it chopped the mail at the line beginning with From. Not sure where the rest ended up ... - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fundamental Qi question
roguem...@roguewrt.org wrote: I booted from flash and SD card for quite some time. I think it's best to consider Qi as an SD-centric solution and to plan migrating towards SD. NAND support is only there because of the GTA01/GTA02 legacy and it has limitations compared to SD. While technically possible to bring NAND support in Qi on par with SD, I think it would just make things more complicated and lure people into using NAND whereas SD is the future. In the GTA03 design, we would not have used NAND for anything but storing Qi and read-only factory data. Likewise, for gta02-core, I wouldn't consider using u-boot. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debuzzing
Dr. H. Nikolaus Schaller wrote: Aother note to all who read this: the Buzz rework is only required if you have the Buzz problem. Hmm, wasn't there an environmental component as well, i.e., band and signal strength ? So changes in the network, e.g., traveling, moving, or the provider messing with things, might bring buzz to phones that still lacked that experience. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: where to buy atheros SDIO wifi card?
hong zhang wrote: I like to buy a Atheros SDIO wifi card and can be used in laptop SDIO lot. Could any one tell me where I can buy it? Hmm, the only ones I've seen with that shape were development boards. Atheros might have an idea about whether such modules are available. If not, maybe try Accton. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Visit at Openmoko
Sven Klomp wrote: When I arrived, the whole office was empty. [...] I'd say your timing was perfect. Your eyes did not betray you, but it's still too early to draw too many conclusions from what you saw. I think it may take a few days before there will be any official information from Openmoko. This is all brand-new and there's still a lot of dust that has to settle, and not all of the consequences may be for the worse. So, no need to panic quite yet :) - Werner ___ 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
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
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
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
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: openmoko neo shape
blokkie wrote: some of my collegues at work ask why the neo looks like a beer opener . Was this part of the design ? Seems that those designers didn't get out much - they missed this obvious feature. As far as I know, the case design predates Openmoko. I've heard that it was originally made for a device to be marketed in the context of the Olympics in China, hence the emphasis on circles, and perhaps also the fairly rugged design and the space for a heck of a lanyard. PS: where should the stylus be inserted ? In the empty beer bottle ? A stylus doesn't make sense. You'd either lose it after a few beers or you're not drinking enough :-) Cheers ! - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bying a Freerunner with the buzz-fix on it
Joerg Reisenweber wrote: There's a way to detect buzzfix by rapidly switching on and off MICBIAS and testing if you hear some buzz when recording from builtin mic. Werner has created a small program to do the switching job. I'm actually not sure if this approach works. You can hear the ~40-50 Hz buzz that program (*) generates well enough, but when I added a buzzfix capacitor, that artificial noise was still there. It could be that I did something wrong, though, including not actually applying the buzz fix. (*) http://svn.openmoko.org/developers/werner/wolfhammer/ - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Slashdotted
Steve Mosher wrote: hardware world. I'll use another metaphor. Building hardware requires a waterfall design process, at least in my experience. In the software world, outside of DOD and NASA, we'd be hard pressed to find projects that followed a strict waterfall model. Hmm, I think one risk of having a heavy development process is that everyone tries to cram all their pet ideas into the project like there's no tomorrow. And yes, I have to plead guilty there as well :-( I think a useful compromise would be a rigid process from design to prototype or product, but the ability to start such processes in rapid succession. A lot of problems in the GTA01/GTA02 design were only found after they hit end-users. Instead of bickering for half a year about buzz fixes, wouldn't it have been easier in the end if we had just been able to start a new design, with the necessary changes, but only them ? This isn't of course something you just decide and it's done. You have to design the company/organization around such an idea. E.g., don't produce at a factory that could spit out a million of units a week but that takes three months to get rolling. minimum, plus a redesign. Take the appendix out--perform a glamoectomy? ask Werner about the design implications of that on WIFI. From (painful) memory: Half a month of getting a straight answer from the vendor whether the chip can do it, about two weeks of figuring out how to best rearrange that whole software stack such that the problem becomes solveable, a few days of implementation, well above a month to find out why that perfect plan didn't work, followed by a few more days of working around the silicon bugs eventually discovered. Ah yes, and when it was done, it didn't get used :-( When assessing the complexity of a problem, we tend to see only those few days of actual development, not those months of unexpected consequences. The OM designs all used modules for GSM and modules for things like WIFI and BT as opposed to down designs or chips on PCBs. The diffculty is not in finding components or modules Famous last words ;-) I'd humbly submit that it can be incredibly painful to find certain components if you're not a really big player. And sometimes, one has to use components that aren't even designed for phones, which creates its own set of problems. The voting approach will be discussed. Basically I dont believe in letting idiots vote. In Linux, we have the concept of benevolent dictators ;-) Very nice and insightful post. Thanks ! - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Slashdotted
Lothar Behrens wrote: I mentioned KICAD (http://kicad.sourceforge.net/wiki/index.php/DE:Main_Page KiCad is probably the Open Source EDA system that's closest to being up to the task. But I still wonder if it can really do it. Don't get me wrong. I use KiCad for everything I do privately and I even contributed a few small features. But then I only do 2 layers, no ground planes, no impedance-matched lines, etc. For an open development process, using a freely available EDA system would of course be an incredible boost. I just wonder if we would really have the resources to build the phone and the EDA system that can do it in parallel. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Slashdotted
Marcel wrote: That's the selling point for us more-or-less nerds. But the average oh-the-iphone-has-so-nice-bling-bling-user cannot see the value an open phone has for us [...] I think they see it, indirectly. If the openness attracts developers, they build things. First they build things that excite only themselves and their peers, i.e., other developers. But eventually, they build things that also appeal to non-developers. And that's when the system becomes interesting to the (wo)man on the street. Eventually also non-developers thus make the connection that open is good. They have to understand the underlying principles about as much as anyone needs to understand differential equations to know that a heavy object once released falls towards the ground. Of course, that rarely stops us developers from trying to tell them anyway, especially after a few drinks at a party ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FatFingerShell vt with fullscreen keyboard
Helge Hafting wrote: Hm. But the glamo supports _some_ format. Will X11 be able to take advantage of that, if the app is smart and request exactly the subsets of blending operations/dataformats that the glamo can do? That would be a question for the X11 gurus. I have such a script for sms, but not for calls. I can send a message like this: # sms 123456789 Short message text Great ! So all we need is a dialer, a contacts database (just use something like $HOME/contacts/$name with maybe a ^key\s+value\s$ structure inside ?), and an SMS reader. April 1 is not over yet ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FatFingerShell vt with fullscreen keyboard
Rafael Ignacio Zurita wrote: it is a new virtual terminal for Openmoko, with a complete fullscreen keyboard and sound. Wow, I love this idea ! Alas, it looks a little slow. (Haven't tried to run it yet, just looked at the videos.) Here's an idea how you could perhaps make it much faster: A long time ago, I discussed with Carsten about what the Glamo could do for us. Predictably, this quickly turned into some rather extensive bashing of this ill-fated chip. On item that came up is the lack of proper support for a feature X11 calls compositing: http://en.wikipedia.org/wiki/Compositing_window_manager The Glamo hardware has the ability to blend images, but, if I recall our discussion correctly, X11 expects the blending operation to support certain formats which the Glamo doesn't. So the conclusion was that it wouldn't be possible to accelerate full X11 compositing with the Glamo. However, perhaps what the Glamo can do is enough for your full-screen overlay. So you would put the X11 framebuffer in one (off-screen) memory area A, draw the keyboard in an area B, and whenever X11 or keyboard manager have updated their screen content, the Glamo would be told to merge screens A and B into the real frame buffer. This may also make it easy to do things like dynamically changing the respective brightness of the keyboard overlay and the background with the actual content. (*) Now, having said all this, I have to admit that making the Glamo do anything is rather hard, and I've heard that X11 isn't trivial either. But several people have started to work on even more complicated things (DRM, GL, ...), so maybe there's someone who could help making an X server with such functionality. (*) For this, you would have to have a means to turn on the keyboard. This could be done by tapping an area where there's no key or where there's a key that doesn't do anything unpleasant (Shift or so), by just absorbing the first tap if the keyboard is dimmed, or perhaps by distinguishing a light touch of the screen from a tap. Oh, and where are the applications ? :-) When Openmoko first announced the Linux-based GTA01, I read a lot of jokes about the kind of user interface a Linux phone would have. Usually they were of the kind making a phone call is easy and intuitive: # phone dial -d /dev/ttySAC0 --number=+123456789 --voice But I wonder if something that would make a call with simply # call foobar wouldn't be about as convenient to use as a GUI. Hang up with ^C, background and do something else with ^Z, etc. :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
Andy Green wrote: Hi yourself... I guess you must have started using Openmoko build system then because last time we spoke about it you were avoiding it same as me - -- for the same reasons. I think you misunderstood me there - I wasn't referring to myself when I mentioned the angelic patience :-) (*) For me, bitbake is a great tool for distribution makers. I say that it's a great tool for them because they seem to be happy with it. When they're happy and make happy little pre-compiled packages for me, I'm happy as well. And I'm even happier if I never ever have to touch bitbake ;-) (*) If you must know, I was thinking of Raster. Although the deprecations he uttered on IRC while struggling to use bitbake as a twisted substitute for make seemed somewhat less angelic (-:C What you should have said is: ''Also, having a toolchain that makes it easy to cross-build from PACKAGES will help a lot towards people not even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.'' What I mean is that, with a good and extensible toolchain, you can pick some Openmoko-agnostic package and build it from sources without pain. Yes, if the package has already been properly openembeddified and is part of someone's build process, sure, you can just grab the binary. But often enough, you'll find that this hasn't happened yet, and you probably want to try it out before lobbying its addition to the daily build. Similarly, if it's work in progress, you often don't want to wait for the daily build. And neither do you want to run your own OE build just to get that package (unless you're blessed with the aforementioned angelic patience). - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Meta Toolchain Release (2008 May)
John Lee wrote: opkg-target update opkg-target install libjana-dev Sure beats the manual approach :-) A little while ago, I built a program that uses SDL, and this is what I came up with: for n in \ libsdl-1.2-0_1.2.9-r5_armv4t.ipk libsdl-1.2-dev_1.2.9-r5_armv4t.ipk \ libsdl-ttf_2.0.3-r0_armv4t.ipk libsdl-ttf-dev_2.0.3-r0_armv4t.ipk \ libsdl-mixer-1.2-0_1.2.6-r2_armv4t.ipk \ libsdl-mixer-1.2-dev_1.2.6-r2_armv4t.ipk \ libasound2_1.0.15-r0_armv4t.ipk libmikmod_3.2.0-beta2-r0_armv4t.ipk \ libogg0_1.1-r3_armv4t.ipk libvorbis_1.0.1-r2_armv4t.ipk; do wget http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/ipk/armv4t/$n ar x $n ( cd /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi; tar --strip-components=2 -xzf -; ) data.tar.gz done rm *-dev* scp *ipk 192.168.0.202: All things considered, not too horrible, but opkg-target will definitely make such things a lot easier. Thanks ! - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Shipping questions, customer organized distribution in Europe
steve wrote: Werner doesn't even know he was the inspiration. Oh, *now* I'm curious :-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel upgrade by ipkg
Graeme Gregory wrote: This has been a long requested feature and its finally ready to be unleashed on the world. One less pleasant feature of this ipkg is that a freshly built rootfs image will still execute /usr/lib/ipkg/info/kernel-image-*.postinst which then wipes out the hard-coded /dev/mtd2. On GTA01, this is indeed the kernel, while it's the u-boot environment in GTA02 ... You've already discussed this issue with Andy. I'd suggest to just grep /proc/mtd for the right partition, and fail if it's not there. That way, we also don't have to worry about getting bitten after any future changes we may make to the partition layout. Thanks, - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain alpha release
John Lee wrote: Yes, I met this one before and I solved it by 1). Okay, that's good enough for me. Just wanted to know where you're heading. BTW, what I need this for are the u-boot and kernel build scripts, trunk/src/target/*/scripts/ This environment setting is dumped and modified from OE Oh, I see. That's why it's so intrusive. For a only cross-build environment type of setting, as in OE, this makes sense. I think if one wants to use toolchain this kind of problems will always happen. Hmm, not sure. The previous (oabi) toolchain served us well for this kind of things for more than a whole year, without acting up. Thanks, - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain alpha release
John Lee wrote:
http://downloads.openmoko.org/toolchains/openmoko-x86_64-arm-linux-gnueabi-toolchain.tar.bz2
I found one little problem with setup-env: when I try to build u-boot
or the kernel with it, ld fails due to the LDFLAGS, which are defined
as follows:
export LDFLAGS=-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib
-Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1
Now, both u-boot and kernel invoke ld directly and not through cc
or gcc. Unfortunately, ld doesn't understand the option -Wl, so
it fails.
We couldn't just omit the -Wl, since gcc doesn't understand -rpath-link,
and we wouldn't want to unconditionally compile with -O1 anyway. But in
what scenario do we actually need to set these flags ? As far as I can
tell, just plain use of arm-angstrom-linux-gnueabi-gcc or
arm-angstrom-linux-gnueabi-ld gets all the search paths right.
If we do have to set LDFLAGS, I can think of the following ways to work
around breaking u-boot and kernel builds:
1) don't use setup-env but define only PATH (which is all kernel and
u-boot really need anyway)
2) make LDFLAGS= ...
3) LDFLAGS= make ...
What I don't like about 2) and 3) is that they make an already too long
command even longer, and that this may let more environment variables
slip through and cause subtle breakage. 1) looks much safer.
Would you agree that, if we have to keep LDFLAGS in setup-env, 1) best
reflects proper use of the toolchain in these cases ? If not, how would
you propose to solve this problem ?
- Werner
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel upgrade by ipkg
Graeme Gregory wrote: There is unfortunately a bug in the kernel, a workaround for this was introduced with the November 2007 snapshot. It's this one: http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=567 - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Neo case-modding ? (was Re: Community update: The 850 MHz issue)
[EMAIL PROTECTED] wrote: The centered, 4.5 Diag *Finger Touch* screen with one thumb width of grip space on either end of a basically rectangular device is a Golden Form Factor. Interesting, so we got it almost right ? Screen size is of course different, but you could probably case-mod the rest. Replace the GSM antenna, cut off one speaker, put the GPS antenna in its place, put it all in a new slimmer and sexier case. Voila, there is your iNeo :-) One gotcha: the GPS antenna would end up at a much worse spot. - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Again: Advertising thoughts
Adam Krikstone wrote: 6. There needs to be some kind of openmokoforums.com. forums.openmoko.org ? We could certainly create that. posting, My phone doesn't work. Help me. We actually have brokenmoko.com/org for these ;-) - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: well, that didn't take long
Phil Schaffner wrote: http://tinyurl.com/35bkor Picture caller ID That fellow is certainly way ahead of the rest of us, including the OpenMoko team ;-) - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko ads now on youtube
Adam Krikstone wrote: http://www.youtube.com/view_play_list?p=472DE700A3CC70A4 Hot shit ! I hope you realize what sort of productivity killer for OpenMoko mission control you've created :-) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS trail - crazy idea
Urivan Saaib wrote: This sounds pretty cool. I've always thinking on a service that could let anyone provide means to upload their position (without being tied to any personal records) and be able to see through the time the evolution of the flows of population (dynamic of fluids). That would be a possible extension, if data is to be passed through some central server (which is probably necessary, since telcos usually don't allow direct IP traffic between mobile terminals). However, I think the best approach to tackle all this is to go incrementally. A standalone trail application should already be useful. Next, one could add simple waypoints. A camera would actually be kinda useful ;-) Trails of multiple users, shared in real time, would be the killer application. I don't think anyone is doing that at the moment. A typical scenario would be to meet someone in a city both don't know. Street names aren't very useful, but knowing roughly where the other person is at the moment, would be. Directing a taxi to the other person's location should be fun, though ;-) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPS trail - crazy idea
Hi all, I was wondering of any of the Gtk gurus hanging out here could do me a little favour. I have this idea that's haunting me in my sleep, but I don't have the time to implement it. It should be really easy to do, though. The idea is to have a GPS tracker/mapper that uses a very simple GUI with very rapid (finger) interaction to find one's way around some place. There are no maps. The context is provided by past movements and/or external information sources, combined by the user's brain. Brief description: http://people.openmoko.org/werner/trail.txt GUI mockup (for 640x480): http://people.openmoko.org/werner/trail.ps The current location interface should probably be generic, e.g., reading x-meters, y-meters, seconds messages from a Unix domain socket. We can then feed it with fake test data and/or slap on a converter from NMEA. I know there are similar programs around, but I don't think they pursue this light-weight and real-time approach quite to the same extent. Anyone feeling like giving it a try ? - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS trail - crazy idea
Nick Johnson wrote: Why not just use NMEA sentences directly? They're simple to read, and more versatile. Sure. Just wanted to skip the math and modularize the thing. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Shawn Rutledge wrote: used for system exploration when there are multiple devices on the bus. We only have the Samsung MCU in the JTAG chain. What is your favorite hardware and software for doing this? We use our own debug board. You need a special flexible cable to connect to JTAG (*), and our board has the corresponding connector. (*) In a phone, there isn't nearly enough space for one of the JTAG connectors you have on eval boards and the like. You could probably roll you own, though, and use some other JTAG adapter, e.g., the cute little Amontec JTAGkey. On the software side, we use OpenOCD. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Joe Friedrichsen wrote: Yes, most of the hardware designs and schematics aren't distributed, Actually, I hope that we can release at least schematics of the debug board and the immediate surroundings of the MCU. There seems to be a lot of red tape surrounding all this, though :-( but there are shadows of scraps here and there thanks to Werner ( http://svn.openmoko.org/developers/werner/usb-pullup/new.spice ). Oh, that one. Don't worry, that never made it into hardware. What we currently have (in GTA02) is the circuit depicted in gates.fig In general, developers/werner/ is my personal junkyard, and I'm a messy person. So please don't jump to conclusions when sifting through it. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Stefan Schmidt wrote: We already had some thoughts about such 'junior tasks'. I really like the idea to give interested people small tasks for a quick start. Regarding quick starts, perhaps some sort of tutorial could be useful, e.g. - how to get the basic development/run-time environment - how to set up QEMU - how to add/change things to/in the run-time environment - step-by-step description for building a graphical hello world application (code layout, widgets, build process, packaging) - pointers to reference code for the most important widgets and/or use of infrastructure interfaces The real problem is to identify such tasks. Most of the stuff is still much work in progress. We should start such a list anyway. :) One problem is also that many small tasks involve a lot of context. So it's two weeks of learning, five minutes of coding, and even then you probably don't do it quite right. Of course, once the learning curve is mastered, things improve significantly. An example for an a bit meatier project, without too many dependencies may be the implementation of a working prototype of the finger splash input method: http://www.micropp.se/openmoko/ An example for a project with lots of cross-dependencies would be a cleanup of the u-boot build process. It would be great if the build process was non-verbose by default, like we have it for the Linux kernel. If anyone wants to tackle this, the best starting point would be u-boot upstream (and synchronize with the upstream developers). A build infrastructure idea: it would be great if BitBake would support entire quilt patchsets, e.g., by pointing to the series file. (Stefan, see yesterday's discussion on #openmoko-devel.) I would vote against another ml. We already have enough. Just send the patch to the ml for the stuff you are hacking on: u-boot, kernel, application... For reasonably self-contained small projects, we also have projects.openmoko.org - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Stefan Schmidt wrote: Should be both in the wiki already, no? Yup, so the walk-through should just explain the easiest approach, and link to the more detailed background material for the rest. E.g., the QEMU part doesn't need all the background information from the QEMU page. Trimming the MokoMakeFile information may be a bit harder. - how to add/change things to/in the run-time environment Hmm, do you mean before the buil with OE or working on the live system? Pick one :-) The idea is to give an answer to how do I run my application on QEMU or my Neo, for testing. There are many possible answers. The getting started guide should give one that's reasonably efficient and reasonably fool-proof. That's indeed a big missing point. On the other hand two projects already found it way in our tree, rss-reader and calculator, which means it seems possible to learn how it works. ;) Yeah, but this should be really easy. Most beginners won't care to understand all the fine points of our build process, at least not initially. Anyway we should fill this gap even if I don't know when we have time for this. :( Perhaps this makes that one more item for the contributions we'd appreciate list. People who have gone through a certain learning experience recently are usually in the best position to describe it. Any bugs/inefficiencies can be filtered out through peer review. [ Tautology deleted ], I'll add these tasks and perhaps some more to the wiki tonight. Great ! :-) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
Jonathon Suggs wrote: My favorite input method is still the finger splash concept (needs some tweaking to the concept though) http://www.micropp.se/openmoko/ I like that one. One issue would be the font size, though - the secondary letters are quite hard to read on the Neo, and the multi-letter functions are basically unreadable (while unsplashed). - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
[EMAIL PROTECTED] wrote: Dasher is only really information efficient considering the input only. The output stream needs to be quite dense. I was commenting on finger splash. I agree that Dasher seems extremely stressful, more like a fast-paced video game. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Heilpern, Mark wrote: If you want to roll your own, with Linux support, check out http://flash-plaice.wikispaces.com/. Wow, this is great ! And the one on sump.org is even closer to what I'm looking for (same hardware, but simpler design). Thanks a lot ! - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Simon Matthews wrote: Could you tell me the make and model of the new MPU, and maybe some links to datasheets. It's the Samsung 2442, http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/SC32442/um_s3c2442b_rev12.pdf I am intrigued to see how they implement the protection. Yeah, me too :-) Section 6 basically says that it works, but doesn't give any details on how. I'd try the following types of attack: - confuse the state machine: disable the NAND controller block between sending command and address, and see what happens. - combine operations: start a write command, turn the NAND control lines to GPIO, send the address, take the rejection, send a harmless command, switch the GPIOs back to NAND control, and send the address. - completely bypass the NAND control block: set the slowest memory timing, control the NAND signals through GPIO, then do a memory write to put the right kind of data on the bus. A logic analyzer may be handy for this type of experiments. (There are some quite resonably priced PC-based ones, alas none of them seem to play nice with Linux :-( Alas, building my own with a small FPGA is a bit too much work for a lunch break project.) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
[EMAIL PROTECTED] wrote: There are a couple of PC-based LAs that work with Linux. Look for the xoscope project, I think it has links to a couple of such LAs. Hmm, only the BitScope, which is a nice device, but its digital capabilities are fairly limited. What I'm thinking of is something like the LogicPort: http://www.pctestinstruments.com/ - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: So, the scenario can be: spefifying area by virus and getting device to reset to have full control... At which time your (still protected) firmware sets the protection again, and executes the regular code. But yes, if you add an easily changeable vector before that point, you lose :-) The bypass I'm thinking of is a little harder, either by messing up the NAND state machine in the MCU (so it doesn't notice we're about to write), or, if they've been really careful, by toggling the bits through GPIO and carefully timed memory accesses. Something your virus author may still do, of course. And that's when the second chip kicks in. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Simon Matthews wrote: I would have thought it would be nice to avoid an extra chip. Yeah, we tried, but it just doesn't seem to be possible :-( There are some alternatives, but they then lead to other problems, such as chips not being available in quantity, etc. (And we've had our number of surprises with that. Once bitten, ...) Of course this [OTP} would only be any good if it could be mapped to the addresses that get downloaded by the CPU before it starts. That's in NAND Flash, which isn't really mapped. Instead, you transfer data in pages. So it's more like a disk than RAM. The MCU has a build-in boot loader that does this, but it doesn't know about OTP. Besides, that OTP can still be changed. I see a couple of problems with having one large complex bootloader. If it is large and complex there is more chance it will need to be changed due to changes in functionality or bugs. No, I don't think this will be needed. The basic recovery functions will be exercised well enough. To the contrary, since this is code we already use daily, it's more likely to be correct than a special-purpose loader that only gets used rarely. Even better: a more general recovery loader will give you more than one way to do things (e.g., SD card and USB), so even if one method fails, you still have a backup. but wonder how hard it would be to write a very basic USB driver with just enough functionality to do the job of downloading some fixed format data from a host. You'd have to ask Harald for comments on USB (among other things, he implemented DFU in u-boot), but my impression is that it's hard and messy enough that nobody wants to maintain yet another stack. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
