Re: Openmoko strives for openness
Sorry for the delay in commenting, not been keeping up with the MLs. Michael Shiloh wrote: snip - Merge the debug board function on to the phone, perhaps with internal micro USB used for debricking and hacking. No write-once memory. - Discard U-Boot, minimal bootloader direct to kernel - Focus on SD Card rootfs rather than internal memory - Add a small lowpower MPU like TI MPS430 to manage everything seamlessly when main CPU is down. Stuff like motion sensors, wake sources, battery management, maybe touchscreen, leds so there is an always-on guiding hand in the phone that is consistent and reliable There are some MCUs that can help with several of these aims. For example - the STM32F103Tx - QFN36, not too large, 32 bit, USB, 10K RAM, 64K ROM, SPI with SD/MMC support, 10 A/D and $3ish in qty. I'd envision this connected to JTAG on the SoC, with all the buttons and LEDs and the above connected to it, and connected in parallel with the USB outside port that would for example: Battery insertion with button held down then USB plugged in: Act like existing debug board, do JTAG things, maybe even talk to SD card over SPI acting as a mass storage device. USB plugged in - battery flat: Do host negotiation for more power, play tune or flash charging LED at user, flash to indicate how much we're charging, and if we can power up. Normal condition - suspended: Talk to GSM modem over serial about stuff, poll accelerometers, maybe even listen to mic for user. Are there any models completely lacking NAND flash, that are cheaper? If the above was used, and was also connected to the SD, it could have a simple stupid 'read block 0 on the SD, and boot using JTAG' BIOS. This could potentially delete the NOR flash, the NAND flash, and some of the glue. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
I bet if you could name such a device, they would have no problem in using it for future products. I bet that if my incomes would exclusively depend on producing such a device, i would use time to search for it. Everything i do, or sale, depends on free software (even for drivers), even if that means less features and less velocity. As i am just a customer and latter on, maybe, a contributor as il would develop and give the community my work, and do want to lose time on that. i know that it is not easy to find 'open' chips, but if open company 'buy' closed chips there will not be 'open' chips at all. It's a shame that project like olpc use that new low-consuming-close-source-wifi-chip without able to obtain open specs for it : they'll manufacture a large number of it. How could someone ask the chip vendor to open there specs if even in free-world people use them as is. [this is the same with the broadcom chip on freebox(c) ] But in free-world we must be fair and do what we says _always_ hervé ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
Sebastian Billaudelle wrote: I think it would be the best way... And why is it not fair? He would be a real part of the project. What's wrong with that? Well, why not. i'm not concerned. just to be asked to the chip vendor. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
Wolfgang Spraul wrote: Dear Hervé, here is my perspective: [...;] Most chip vendors see their business in selling chips. Documentation is engineers can. Again we could only do this with vendors who understand what we are doing, trust us, and generally agree to the idea. We would That is exactly the meaning of my fair. If vendors fully agrees with what is decided, i'm fully happy with that. I understand manufacture world is not wonderland, what i was saying is free world must do what he is _supposed_ doing, not finding ways around. If the vendor agrees about letting someone(s) use the nda under the responsibility of om i am fully satisfied with it and i fully support that fact as a middle of the river position. openmokko is really a great project that would show the world that openness is a real possibility not only a sweet dream. i always by open products, even if could do without it (for exemple gp2x, and down om hervé ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
what if you become part of openmoko? Just sign some kind of work contract (like other freelancers had and still have with openmoko), but with only USD 1 in return for your work, adding a clause that you keep the copyright on your work? This way you are legally part of openmoko, have access to the docs, and can work on the code. I don't think it's fair. the world of free software should be a world of truthfulness and this way is not. They don't want their specs to run out the world, so let's keep these specs on the shelve. Let's the 'market' decide : - If it come a chip with better package [hard+spec] for gta03, too bad for Glamo and they will not be in gta03. - if the users don't like freerunner because there is no cool 3D stuff, freerunner won't be sold that much and they wont sell to much chips. the long term war vs closed sources specs is not to use them : no specs, no cool feature, bad product, product gonna die. it is irrelevant to spare time to develop driver for a product when the owner don't want a driver to be develop. Let's concentrate on another open field, ready to switch to a more open chips. hervé ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
Reply Header Subject:Re: Openmoko strives for openness (smedia glamo) Author: herve couvelard [EMAIL PROTECTED] Date: 03rd April 2008 2:21 pm what if you become part of openmoko? Just sign some kind of work contract (like other freelancers had and still have with openmoko), but with only USD 1 in return for your work, adding a clause that you keep the copyright on your work? This way you are legally part of openmoko, have access to the docs, and can work on the code. I don't think it's fair. the world of free software should be a world of truthfulness and this way is not. They don't want their specs to run out the world, so let's keep these specs on the shelve. Let's the 'market' decide : - If it come a chip with better package [hard+spec] for gta03, too bad for Glamo and they will not be in gta03. - if the users don't like freerunner because there is no cool 3D stuff, freerunner won't be sold that much and they wont sell to much chips. the long term war vs closed sources specs is not to use them : no specs, no cool feature, bad product, product gonna die. it is irrelevant to spare time to develop driver for a product when the owner don't want a driver to be develop. Let's concentrate on another open field, ready to switch to a more open chips I bet if you could name such a device, they would have no problem in using it for future products. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
I like this idea, I think this is legally OK and if we are open and honest about it, may even become an accepted practice known to our vendors. Need to do some more checks on that... Wolfgang On Apr 3, 2008, at 9:44 PM, Harald Welte wrote: On Wed, Apr 02, 2008 at 09:32:31AM +0100, Tom Cooksey wrote: On Sunday 30 March 2008 13:42:23 Harald Welte wrote: Please note though, that being one of the persons who drafted the wording on the contract between Smedia and OpenMoko: The contract contains explicit provisions for OpenMoko preparing a set of documentation for the Glamo chip, not carbon-copying from the original NDA'd docs, and then cooperating with Smedia to jointly release that new manual. However, I doubt that given the current load and priority situation, there would be anyone doing paid work on that set of new documentation. As one (perhaps only one?) who volunteered to start work on a DRM driver for the glamo (the first step to 3D), I can confirm that the NDA OpenMoko has with SMedia prevents them from releasing any docs to 3rd parties, with or without an NDA. what if you become part of openmoko? Just sign some kind of work contract (like other freelancers had and still have with openmoko), but with only USD 1 in return for your work, adding a clause that you keep the copyright on your work? This way you are legally part of openmoko, have access to the docs, and can work on the code. -- - Harald Welte [EMAIL PROTECTED]http://openmoko.org/ = = = = = = == Software for the world's first truly open Free Software mobile phone ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
I think it would be the best way... And why is it not fair? He would be a real part of the project. What's wrong with that? cheers Sebastian Am Donnerstag, den 03.04.2008, 23:17 +0800 schrieb Wolfgang Spraul: I like this idea, I think this is legally OK and if we are open and honest about it, may even become an accepted practice known to our vendors. Need to do some more checks on that... Wolfgang On Apr 3, 2008, at 9:44 PM, Harald Welte wrote: On Wed, Apr 02, 2008 at 09:32:31AM +0100, Tom Cooksey wrote: On Sunday 30 March 2008 13:42:23 Harald Welte wrote: Please note though, that being one of the persons who drafted the wording on the contract between Smedia and OpenMoko: The contract contains explicit provisions for OpenMoko preparing a set of documentation for the Glamo chip, not carbon-copying from the original NDA'd docs, and then cooperating with Smedia to jointly release that new manual. However, I doubt that given the current load and priority situation, there would be anyone doing paid work on that set of new documentation. As one (perhaps only one?) who volunteered to start work on a DRM driver for the glamo (the first step to 3D), I can confirm that the NDA OpenMoko has with SMedia prevents them from releasing any docs to 3rd parties, with or without an NDA. what if you become part of openmoko? Just sign some kind of work contract (like other freelancers had and still have with openmoko), but with only USD 1 in return for your work, adding a clause that you keep the copyright on your work? This way you are legally part of openmoko, have access to the docs, and can work on the code. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ = = = = = = == Software for the world's first truly open Free Software mobile phone ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Ich aktzeptiere keine MS Office Dokumente, weil sie 1. kein ISO Standard sind, 2. bewusst schlecht entwickelt sind und 3. nicht für alle zugänglich sind! Benutze bitte das Open Document Format - jeder kann es kostenlos öffnen - auch noch in tausenden von Jahren! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
Dear Hervé, here is my perspective: Most chip vendors see their business in selling chips. Documentation is just a necessary evil to them, they are trying to get away with the minimum amount of documentation that will still sell the chip. Unless in very few cases, chip vendors do not see good documentation as a strategic asset that will help sell their chips. Maybe down the road we are lucky and Intel becomes a vendor that sees documentation like this, but I will believe it when I see it. NXP also came around to us in a very nice way. We would like to publish documentation for the Toshiba ASIC in our LCM, very hard with Toshiba (I'm not complaining, it's a big company and we are a minuscule customer). Samsung seems to be going closed, even though they joined the Open Handset Alliance and are a big supporter of Android! Why that? Well, let's think from their perspective: Again - they are selling chips, not books or PDF files. In the case of Samsung, the legal department may look at a given PDF file (say 1000 pages long) and see LOTS OF RISKS! When their lawyers read this document (and they won't understand most of the technical stuff in there), they are very concerned that the document will provide grounds for lawsuits against Samsung later on. If they just sell the chips as-is, those risks are reduced. Plus they will say why do we have to release THIS particular PDF? Why not a much shorter version, say a 2-page high-level overview, which the legal department can carefully check word-by-word before release? And if it has to be this specific PDF, why not release even much more? Samsung certainly has another 100,000 pages documentation for each chip, internally. If you think about it from their perspective documentation is a very random thing. You cannot easily convince them that if they release a 1000-page PDF file about the say 6400 chip, they will sell this many more chips compared to just releasing a 2-page PDF file. So we at Openmoko need to be smart, and accept realities out there: ---1 The current model: We try to convince vendors to open up documentation to the public, ideally allowing us (or even better everyone else) to redistribute the documentation. Like Intel is doing with Creative Commons now. ---2 We can try to 'buy' chips+documentation, make the PDF file part of the purchase. We would then put the PDF file behind a click-through license, which says that the PDF behind the click-through license is just part of the Neo product, and does not guarantee product behavior. The legal effectiveness of such a click-through license is debatable, and we would still need the vendor to like the idea and agree to give us documents under these terms. ---3 We can sign traditional NDAs and alert our vendors that we are legally hiring respected FOSS engineers on a nominal basis (say 1 USD/month), in order to give them access to the documents we have under NDA and allow them to write FOSS software same as our traditional, fully-paid engineers can. Again we could only do this with vendors who understand what we are doing, trust us, and generally agree to the idea. We would not mass-hire thousands of people this way, say having a form on the web where you can 'hire' yourself, then download all docs. It all has to be reasonable and ideas and intentions must not be ridiculed. But I could imagine that this is doable, first with a few selected people, later maybe dozens or even hundreds of people? The bigger we make this the more our own legal department will get concerned :-) ---4 We can become much more aggressive in documenting our source codes. Most vendors would actually like that! Remember what I said above that the legal departments see documentation THEY publish as a risk! But if we publish something we wrote ourselves they usually don't care, in fact they like if someone does free work for them. We can say whatever we want about a vendor's chips, worst case we will get sued, not them :-) So maybe we should just go ahead and EXTENSIVELY document source codes, to the point that you basically have long lists of well- documented defines in header files, long commented-out texts describing certain chip behavior, more or less based on what we read in the documentation (just rewritten), etc. Same as always, we would only do this with vendors that understand agree to this, but as with #2 and #3 there is actually a good chance many vendors would be supportive. There is no perfect solution to cover all cases. We need to work case by case (vendor by vendor) to open up documentation, so that we Free The Phone, as we have set out to do. I see a big tendency to write 'pseudo' open source codes, where it's nominally written say in C, but actually it's just long lists of writing magic 32-bit values into magic memory registers. This is not much different from having a binary driver outright,
Re: Openmoko strives for openness (smedia glamo)
Could also put an FPGA between the processor and the display, and maybe some developers will figure out how to accelerate the most frequently used drawing functions. Just an idea... I know it's a long shot and probably takes too much power too... but for a while there was an open PCI video card project which was taking that approach. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko strives for openness (smedia glamo)
Really, it's intellectual property being sold. Skimping on docs is just trying to sell less for more. It costs money to produce documentation and documentation is regularly the final victim of tight schedules in the design factory. The best docs do seem to be from companies that have intergrated their docs with their development, so that it updates automatically or is tied together some other way. If a company has crappy docs, maybe they have a crappy dev process. I do think minimal docs are just the way things are done, you gotta be able to figure out some things as developers. What can be expected is that it's coverage is feature complete and exactly correct, at a minimum. If there are blank spaces that can be reasonably infered *or experimented with* to figure out, that's ok. An asic company just ain't going to know how there product behaves in all conditions, or the best way to adapt a given application, and it's difficult and time consuming to communicate subtlies to them, you just have to play with things. Otherwise, how else can you know your absolutely correct?? Not with the docs.. Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Spraul Sent: Thursday, April 03, 2008 12:14 PM To: [EMAIL PROTECTED]; List for Openmoko community discussion Subject: Re: Openmoko strives for openness (smedia glamo) Dear Hervé, here is my perspective: Most chip vendors see their business in selling chips. Documentation is just a necessary evil to them, they are trying to get away with the minimum amount of documentation that will still sell the chip. Unless in very few cases, chip vendors do not see good documentation as a strategic asset that will help sell their chips. Maybe down the road we are lucky and Intel becomes a vendor that sees documentation like this, but I will believe it when I see it. NXP also came around to us in a very nice way. We would like to publish documentation for the Toshiba ASIC in our LCM, very hard with Toshiba (I'm not complaining, it's a big company and we are a minuscule customer). Samsung seems to be going closed, even though they joined the Open Handset Alliance and are a big supporter of Android! Why that? Well, let's think from their perspective: Again - they are selling chips, not books or PDF files. In the case of Samsung, the legal department may look at a given PDF file (say 1000 pages long) and see LOTS OF RISKS! When their lawyers read this document (and they won't understand most of the technical stuff in there), they are very concerned that the document will provide grounds for lawsuits against Samsung later on. If they just sell the chips as-is, those risks are reduced. Plus they will say why do we have to release THIS particular PDF? Why not a much shorter version, say a 2-page high-level overview, which the legal department can carefully check word-by-word before release? And if it has to be this specific PDF, why not release even much more? Samsung certainly has another 100,000 pages documentation for each chip, internally. If you think about it from their perspective documentation is a very random thing. You cannot easily convince them that if they release a 1000-page PDF file about the say 6400 chip, they will sell this many more chips compared to just releasing a 2-page PDF file. So we at Openmoko need to be smart, and accept realities out there: ---1 The current model: We try to convince vendors to open up documentation to the public, ideally allowing us (or even better everyone else) to redistribute the documentation. Like Intel is doing with Creative Commons now. ---2 We can try to 'buy' chips+documentation, make the PDF file part of the purchase. We would then put the PDF file behind a click-through license, which says that the PDF behind the click-through license is just part of the Neo product, and does not guarantee product behavior. The legal effectiveness of such a click-through license is debatable, and we would still need the vendor to like the idea and agree to give us documents under these terms. ---3 We can sign traditional NDAs and alert our vendors that we are legally hiring respected FOSS engineers on a nominal basis (say 1 USD/month), in order to give them access to the documents we have under NDA and allow them to write FOSS software same as our traditional, fully-paid engineers can. Again we could only do this with vendors who understand what we are doing, trust us, and generally agree to the idea. We would not mass-hire thousands of people this way, say having a form on the web where you can 'hire' yourself, then download all docs. It all has to be reasonable and ideas and intentions must not be ridiculed. But I could imagine that this is doable, first with a few selected people, later maybe dozens or even hundreds of people? The bigger we make this the more our own legal
Re: Openmoko strives for openness (smedia glamo)
On Sunday 30 March 2008 13:42:23 Harald Welte wrote: On Thu, Mar 27, 2008 at 07:46:52PM +0100, joerg wrote: Am Do 27. März 2008 schrieb Lally Singh: On Thu, Mar 27, 2008 at 12:22 PM, Andy Green [EMAIL PROTECTED] wrote: Somebody in the thread at some point said: 2. Actually, is there any hope of getting 3d acceleration out of the graphics chip, or is that too bogged down with NDA-ness? Are we stuck porting Mesa3D? Chance, sure, but the NDA situation is pretty bad it turns out for the Glamo. It's a shame! Poor (Glamo) fools are shooting themselves in the foot on this one. full ACK! Anyway there's hope, there were volunteers on one of the lists yesterday, who might be willing to sign a NDA. Please note though, that being one of the persons who drafted the wording on the contract between Smedia and OpenMoko: The contract contains explicit provisions for OpenMoko preparing a set of documentation for the Glamo chip, not carbon-copying from the original NDA'd docs, and then cooperating with Smedia to jointly release that new manual. However, I doubt that given the current load and priority situation, there would be anyone doing paid work on that set of new documentation. As one (perhaps only one?) who volunteered to start work on a DRM driver for the glamo (the first step to 3D), I can confirm that the NDA OpenMoko has with SMedia prevents them from releasing any docs to 3rd parties, with or without an NDA. So, yes, I'm willing to sign an NDA to get the docs to write a driver. This was to be done in my own time and for free. As OpenMoko isn't allowed to release the docs to me at all, even if I do sign an NDA, I have to go to SMedia. Sadly, as Lorn has pointed out, SMedia wants $15,000 before they will release the docs under NDA. As this was going to be a personal project, I have no intention of forking out $15,000 of my own money to write a driver. I've been in discussion with my managers here in Trolltech to see if the company would put up the cash and perhaps even pay me a little to do it. Sadly we've all agreed that this would take too much time away from my other work and there is other hardware which already have drivers I can work with. I just find it crazy that SMedia want to charge me $15,000 to write a driver for their hardware - a driver which SHOULD already exist. When you concider things like Google Android, LiMO, etc. it's pretty obvious SMedia will need to support Linux if they are to suvive. So, the only options for getting 3D on the neo are: 1) Someone forks out $15,000 for docs writes a driver in their own time 2) OpenMoko employs someone to write a driver using the docs they already have. 3) O-Hand or similar writes a driver under contract from OpenMoko as they seem to be doing with the X driver. 4) SMedia writes a driver themselves. 5) Some poor person tries to write a driver without the docs. :-/ I guess 2 3 are the most likely candidates, but I think OpenMoko's priorities are simply not 3D at the moment. Cheers, Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
On Wednesday 02 April 2008 11:07:47 Andy Green wrote: There's a 6) I thought about, AFAIK it could theoretically anyway be possible we can write detailed header files for an open driver which contain register and bitfield enums and comments for the 3D unit. If we did write our own we would certainly have to do this anyway and presumably it is okay by whatever agreement exists (but surprises are the norm here). How about the 7) developer to become a new OM employee and thus gets access (unpaid intern or something like that, if nothing else) to the OM license? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Wednesday 02 April 2008 11:07:47 Andy Green wrote: | There's a 6) I thought about, AFAIK it could theoretically anyway be | possible we can write detailed header files for an open driver which | contain register and bitfield enums and comments for the 3D unit. If we | did write our own we would certainly have to do this anyway and | presumably it is okay by whatever agreement exists (but surprises are | the norm here). | | How about the 7) developer to become a new OM employee and thus gets access | (unpaid intern or something like that, if nothing else) to the OM license? I think we have to be seen to take care about the spirit of the agreement as well as the letter or the consequences could be negative all around. But the agreement must allow for transcription of the information into a FOSS driver because otherwise there'd be no point. So this would be a way through it rather than a way around it. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfzUuUACgkQOjLpvpq7dMqZKQCfS49hesYqIII6XprSj9ImJ0hE CxsAoId+7kkh7NAh9ne5qqxcGa4lyWd4 =EBe8 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko strives for openness (smedia glamo)
How about employ some people like Tom Cooksey but don't pay them anything? Would that be a violation of the NDA? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Green Sent: Wednesday, April 02, 2008 11:08 AM To: List for Openmoko community discussion Subject: Re: Openmoko strives for openness (smedia glamo) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | 5) Some poor person tries to write a driver without the docs. :-/ There's a 6) I thought about, AFAIK it could theoretically anyway be possible we can write detailed header files for an open driver which contain register and bitfield enums and comments for the 3D unit. If we did write our own we would certainly have to do this anyway and presumably it is okay by whatever agreement exists (but surprises are the norm here). Paging through the data, this itself is not a small job. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfzTNsACgkQOjLpvpq7dMo+PgCdHhS+7YTVrt6nPSURC3jY6Oc6 TbcAn17eg5RWU2GH86iVm17xsTqhn11v =rxeW -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
On Wed, Apr 2, 2008 at 5:33 AM, Andy Green [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Wednesday 02 April 2008 11:07:47 Andy Green wrote: | There's a 6) I thought about, AFAIK it could theoretically anyway be | possible we can write detailed header files for an open driver which | contain register and bitfield enums and comments for the 3D unit. If we | did write our own we would certainly have to do this anyway and | presumably it is okay by whatever agreement exists (but surprises are | the norm here). | | How about the 7) developer to become a new OM employee and thus gets access | (unpaid intern or something like that, if nothing else) to the OM license? I think we have to be seen to take care about the spirit of the agreement as well as the letter or the consequences could be negative all around. But the agreement must allow for transcription of the information into a FOSS driver because otherwise there'd be no point. So this would be a way through it rather than a way around it. No one has suggested it yet, but could this be a Summer of Code project? Harald's note seemed to indicate that the product of such an effort would be an open-source driver, and documentation to assist in writing of other drivers. I'm not sure if this would be close enough to the spirit, though. Could this be a way through it too? Gerald ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
On Wednesday 02 April 2008 18:32, Tom Cooksey wrote: On Sunday 30 March 2008 13:42:23 Harald Welte wrote: On Thu, Mar 27, 2008 at 07:46:52PM +0100, joerg wrote: Am Do 27. März 2008 schrieb Lally Singh: On Thu, Mar 27, 2008 at 12:22 PM, Andy Green [EMAIL PROTECTED] wrote: Somebody in the thread at some point said: 2. Actually, is there any hope of getting 3d acceleration out of the graphics chip, or is that too bogged down with NDA-ness? Are we stuck porting Mesa3D? Chance, sure, but the NDA situation is pretty bad it turns out for the Glamo. It's a shame! Poor (Glamo) fools are shooting themselves in the foot on this one. full ACK! Anyway there's hope, there were volunteers on one of the lists yesterday, who might be willing to sign a NDA. Please note though, that being one of the persons who drafted the wording on the contract between Smedia and OpenMoko: The contract contains explicit provisions for OpenMoko preparing a set of documentation for the Glamo chip, not carbon-copying from the original NDA'd docs, and then cooperating with Smedia to jointly release that new manual. However, I doubt that given the current load and priority situation, there would be anyone doing paid work on that set of new documentation. As one (perhaps only one?) who volunteered to start work on a DRM driver This was already looked at by me, as the one who is doing the Neo Qtopia port. Looked at least for a Qt embedded gfxplugin. for the glamo (the first step to 3D), I can confirm that the NDA OpenMoko has with SMedia prevents them from releasing any docs to 3rd parties, with or without an NDA. So, yes, I'm willing to sign an NDA to get the docs to write a driver. This was to be done in my own time and for free. I would have done it on Trolltech's time. :) As OpenMoko isn't allowed to release the docs to me at all, even if I do sign an NDA, I have to go to SMedia. Sadly, as Lorn has pointed out, SMedia wants $15,000 before they will release the docs under NDA. As this was going to be a personal project, I have no intention of forking out $15,000 of my own money to write a driver. I've been in discussion with my managers here in Trolltech to see if the company would put up the cash and perhaps even pay me a little to do it. Sadly we've all agreed that this would take too much time away from my other work and there is other hardware which already have drivers I can work with. This is what we already came to the conclusion of within 3 seconds of reading smedia's offer. -- Lorn 'ljp' Potter Software Engineer, Systems Group, MES, Trolltech ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness (smedia glamo)
On Thu, Mar 27, 2008 at 07:46:52PM +0100, joerg wrote: Am Do 27. März 2008 schrieb Lally Singh: On Thu, Mar 27, 2008 at 12:22 PM, Andy Green [EMAIL PROTECTED] wrote: Somebody in the thread at some point said: 2. Actually, is there any hope of getting 3d acceleration out of the graphics chip, or is that too bogged down with NDA-ness? Are we stuck porting Mesa3D? Chance, sure, but the NDA situation is pretty bad it turns out for the Glamo. It's a shame! Poor (Glamo) fools are shooting themselves in the foot on this one. full ACK! Anyway there's hope, there were volunteers on one of the lists yesterday, who might be willing to sign a NDA. Please note though, that being one of the persons who drafted the wording on the contract between Smedia and OpenMoko: The contract contains explicit provisions for OpenMoko preparing a set of documentation for the Glamo chip, not carbon-copying from the original NDA'd docs, and then cooperating with Smedia to jointly release that new manual. However, I doubt that given the current load and priority situation, there would be anyone doing paid work on that set of new documentation. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness
On Wed, 19 Mar 2008 13:02:54 -0400 Lally Singh [EMAIL PROTECTED] wrote: The openness is much appreciated!! The hack value of this phone is really mind-boggling. IMHO It could become to this generation's young hackers what the old Apple IIs and Commodores were to my generation. As for the 6400 vs the 2443, is there any reason to prefer the 2443? The 6400 seems better in every way. As for other ideas, in sorted order of perceived probability: 1. First, some sort of mounting holes near the USB (like the PSP)? Or another USB port on the back (with mount holes), to allow things to be attached behind the phone? I'm in the Virtual Reality group here, and a phone with GPS, accelerometers, and 3D is *very* interesting. With a more specific positioning system (e.g. like the wiimote's IR) attached, it'd be really useful in an immersive CAVE (small room with projectors on 4-6 sides) or a gigapixel (25-50 LCDs arranged into one giant display) system. 2. Actually, is there any hope of getting 3d acceleration out of the graphics chip, or is that too bogged down with NDA-ness? Are we stuck porting Mesa3D? 3. Also, a wifi adapter that does promiscuous mode? A few sysadmins would love to run wireshark on it, to diagnose what's going on with their network. 4. Personally, I'd love some sort of high-speed connector, so I could connect something like an FPGA to it. Maybe access to the GPIO off the processor? I don't expect it to be a high priority, but I have to ask :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Promiscuous mode? I would prefer full packet injection ;) see those wep networks crumble. -- Ewan Marshall (ewanm89/Cap_J_L_Picard on irc) http://ewanm89.co.uk/ Geek by nature, Linux by choice. signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness
Somebody in the thread at some point said: 2. Actually, is there any hope of getting 3d acceleration out of the graphics chip, or is that too bogged down with NDA-ness? Are we stuck porting Mesa3D? Chance, sure, but the NDA situation is pretty bad it turns out for the Glamo. 4. Personally, I'd love some sort of high-speed connector, so I could connect something like an FPGA to it. Maybe access to the GPIO off the processor? I don't expect it to be a high priority, but I have to ask :-) Generally speaking USB of one kind or another will very likely be around in one form or another... it will be a much better solution to make such a device a USB peripheral since you don't have to open the case, can unplug to revert to just being a phone, you get power provided from the phone, can use on other hosts, etc. And at some point it will very likely be 480Mbps (GTA02 is 12Mbps) DMA'd in and out, so bandwidth won't be an issue. I really recommend this path for any non-casual hacking. Promiscuous mode? I would prefer full packet injection ;) see those wep networks crumble. Full (radiotap) injection is useful for non-evil things too, the problem with Monitor mode and the injection is the same: the closed firmware doesn't offer it at the moment, and the firmware alone handles the MAC for the current WLAN device. -Andy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness
On Thu, Mar 27, 2008 at 12:22 PM, Andy Green [EMAIL PROTECTED] wrote: Somebody in the thread at some point said: 2. Actually, is there any hope of getting 3d acceleration out of the graphics chip, or is that too bogged down with NDA-ness? Are we stuck porting Mesa3D? Chance, sure, but the NDA situation is pretty bad it turns out for the Glamo. It's a shame! Poor (Glamo) fools are shooting themselves in the foot on this one. Generally speaking USB of one kind or another will very likely be around in one form or another... it will be a much better solution to make such a device a USB peripheral since you don't have to open the case, can unplug to revert to just being a phone, you get power provided from the phone, can use on other hosts, etc. And at some point it will very likely be 480Mbps (GTA02 is 12Mbps) DMA'd in and out, so bandwidth won't be an issue. I really recommend this path for any non-casual hacking. USB2 would be fast, but AFAIK it tends to suck away all your CPU. Something a little smarter, like firewire? Promiscuous mode? I would prefer full packet injection ;) see those wep networks crumble. Full (radiotap) injection is useful for non-evil things too, the problem with Monitor mode and the injection is the same: the closed firmware doesn't offer it at the moment, and the firmware alone handles the MAC for the current WLAN device. My own prefs aside, this one's a biggie. If OM's looking at potentially changing chips down the road, something a lot more hackable here would be wonderful. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Thu, Mar 27, 2008 at 12:22 PM, Andy Green [EMAIL PROTECTED] wrote: | Somebody in the thread at some point said: | | 2. Actually, is there any hope of getting 3d acceleration out of the | graphics chip, or is that too bogged down with NDA-ness? Are we stuck | porting Mesa3D? | | Chance, sure, but the NDA situation is pretty bad it turns out for the | Glamo. | | It's a shame! Poor (Glamo) fools are shooting themselves in the foot | on this one. It doesn't make much sense to me either. I know we have not been deficient in trying to get this policy changed. | likely be 480Mbps (GTA02 is 12Mbps) DMA'd in and out, so bandwidth won't | be an issue. I really recommend this path for any non-casual hacking. | | USB2 would be fast, but AFAIK it tends to suck away all your CPU. | Something a little smarter, like firewire? No the host controllers for 12Mbps and 480Mbps USB -- and firewire the same -- are all set up around DMA, so bulk transport isn't so expensive in CPU for any of them. As the bandwidth goes up it will start to hurt memory bandwidth and CPU in terms of the amount of descriptors flying about but not before a good few MBytes/sec I would guess. | Promiscuous mode? I would prefer full packet injection ;) see those wep | networks crumble. | | Full (radiotap) injection is useful for non-evil things too, the problem | with Monitor mode and the injection is the same: the closed firmware | doesn't offer it at the moment, and the firmware alone handles the MAC | for the current WLAN device. | | My own prefs aside, this one's a biggie. If OM's looking at | potentially changing | chips down the road, something a lot more hackable here would be wonderful. Well it has AP scan, WEP and WPA which are truly the biggies, in comparison Monitor mode and injection are a bit specialized (despite I would love them too). Changing is possible but it would need a proven Linux driver and enough advantage to offset the upset of changing, testing, etc. I don't see being able to say about Monitor mode and injection is enough advantage to convince most folks about that. These annoying fullmac firmware-is-boss type devices have a lower power requirement that can't be ignored despite it means the product is defined by the closed firmware in them. You know there has been a run of mails I am writing lately and the thread is the same all over, closed stuff is making the trouble. If the firmware was open, we could consider to add exactly what we wanted and then we would be nicely and willingly locked into that product, and our improvements are available to other customers. But the vendor isn't quite ready to add value to their products like that. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfr3UcACgkQOjLpvpq7dMoC/wCfZ8hhvzFqOCQvx+taQsLAFAu/ zLkAmQHod6GvgEeA6s6rMw+9omL1DH9D =GvZF -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness
On Thu, Mar 27, 2008 at 1:45 PM, Andy Green [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No the host controllers for 12Mbps and 480Mbps USB -- and firewire the same -- are all set up around DMA, so bulk transport isn't so expensive in CPU for any of them. As the bandwidth goes up it will start to hurt memory bandwidth and CPU in terms of the amount of descriptors flying about but not before a good few MBytes/sec I would guess. I'm sold. One (more?) vote for a USB2 port in later generations of OM? Well it has AP scan, WEP and WPA which are truly the biggies, in comparison Monitor mode and injection are a bit specialized (despite I would love them too). Changing is possible but it would need a proven Linux driver and enough advantage to offset the upset of changing, testing, etc. I don't see being able to say about Monitor mode and injection is enough advantage to convince most folks about that. These annoying fullmac firmware-is-boss type devices have a lower power requirement that can't be ignored despite it means the product is defined by the closed firmware in them. Lower power is a decent counterrequirement to promiscuity and injection. OTOH, we've got a bit of a hacker bias on this group of developers. If OM later sees a comparable or nearly comparable device that has those features, perhaps a poll could be run to get an idea of what people would want? You know there has been a run of mails I am writing lately and the thread is the same all over, closed stuff is making the trouble. If the firmware was open, we could consider to add exactly what we wanted and then we would be nicely and willingly locked into that product, and our improvements are available to other customers. But the vendor isn't quite ready to add value to their products like that. *sigh* It's a shame. It's too bad we can't get the openness we're seeing out of Sun for their opensparc project :-) ... unless OM wants to go sparc anytime soon :-P -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness
The openness is much appreciated!! The hack value of this phone is really mind-boggling. IMHO It could become to this generation's young hackers what the old Apple IIs and Commodores were to my generation. As for the 6400 vs the 2443, is there any reason to prefer the 2443? The 6400 seems better in every way. As for other ideas, in sorted order of perceived probability: 1. First, some sort of mounting holes near the USB (like the PSP)? Or another USB port on the back (with mount holes), to allow things to be attached behind the phone? I'm in the Virtual Reality group here, and a phone with GPS, accelerometers, and 3D is *very* interesting. With a more specific positioning system (e.g. like the wiimote's IR) attached, it'd be really useful in an immersive CAVE (small room with projectors on 4-6 sides) or a gigapixel (25-50 LCDs arranged into one giant display) system. 2. Actually, is there any hope of getting 3d acceleration out of the graphics chip, or is that too bogged down with NDA-ness? Are we stuck porting Mesa3D? 3. Also, a wifi adapter that does promiscuous mode? A few sysadmins would love to run wireshark on it, to diagnose what's going on with their network. 4. Personally, I'd love some sort of high-speed connector, so I could connect something like an FPGA to it. Maybe access to the GPIO off the processor? I don't expect it to be a high priority, but I have to ask :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko strives for openness
What would be interesting to know: What is the next thing Openmoko wants to do? A GTA03 Neo device with some changes in functionality but keeping the general design? An entirely new device with possibly other/revolutionary design goals? Multiple devices at the same time? How about a TI OMAP3 as SoC? They seem to somewhat support open source Linux though I'm not sure to what extent and if they can be pushed further in the right direction. http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123contentId=4752 http://focus.ti.com/general/docs/gencontent.tsp?contentId=36915 http://focus.ti.com/docs/prod/folders/print/omap3530.html Pandora ( http://www.openpandora.org/ ) uses the OMAP 3530. I'd like to see a similarly powerful, similar form factor Openmoko device. Maybe a cooperation with the Pandora guys would be possible, adding Bluetooth and phone functionality to it? Putting the rootfs on an internal microSD card sounds like it would make sense. I'd like to have a second SD slot though, that is easier to access. Full SD would be nice for that but microSD probably more practical in a phone. I don't have much of a clue about these things but here is what the boot mechanism should make possible: The first part starting the system has to be permanent and only flashable with some effort (debug board). It should never need a reflash. This part has to check if the user wants to start up normally (power button) or wants to reflash the internal memory (power + aux). The internal memory would contain everything that can change, such as the boot loader and the OS. Flashing needs to be possible over USB. So what needs to change is that flashing the internal memory isn't a function of the bootloader, which sits in internal memory, but rather something put into a part that boots up first and can't be changed without the debug board and thus not destroyed by a virus or software failures. The need of a debug board for repairing messed up software would vanish. Ortwin On 3/19/08, Michael Shiloh [EMAIL PROTECTED] wrote: Hi everyone, I wanted to point out to you something that has been happening quietly for awhile now. Often discussions start on Openmoko internal mailing lists. Suddenly we realize the discussion is important and that there is no reason for it to remain internal. There is a constant trend of moving these discussions from internal lists to public lists. Many Openmoko employees do this, but I'd particularly like to publicly thank Wolfgang Spraul for championing this and for setting up a culture that encourages everyone to think in these terms. I realize that often you, the world outside, see these discussions appear on the external lists and perhaps don't realize that this is a deliberate action on our part to hold as much discussion as possible in public rather than private forums. Regards, Michael Original Message Subject: Post- GTA02 Date: Wed, 19 Mar 2008 10:27:47 + From: Andy Green [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks - We had some internal talk about how to go post GTA02 and Wolfgang wants us to make it external. We have a choice about basing on S3C2443 or S3C6400. A lot of the info is confidential but not these high level things which are public domain on Samsung's site. S3C2443 is an 130nm incremental improvement over the 2442 in GTA02 with 480Mbps USB Device (not OTG) and better clock scaling. It can accept x16 DDR memory. S3C6400 is 90nm and has 480Mbps USB2 OTG, 667MHz max clock, some 2D acceleration and can accept x32 DDR memory. http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229partnum=S3C6400 http://www.samsung.com/global/system/business/semiconductor/product/2007/8/21/661267ptb_s3c6400_rev15.pdf I like the 6400 better but information is a bit scarce right now and it can go either way. Some other concepts kicked around: - Merge the debug board function on to the phone, perhaps with internal micro USB used for debricking and hacking. No write-once memory. - Discard U-Boot, minimal bootloader direct to kernel - Focus on SD Card rootfs rather than internal memory - Add a small lowpower MPU like TI MPS430 to manage everything seamlessly when main CPU is down. Stuff like motion sensors, wake sources, battery management, maybe touchscreen, leds so there is an always-on guiding hand in the phone that is consistent and reliable To be clear though -- GTA02 is soon going to actually exist, and this is just future talk right now. But because of that, if you have any ideas about future arch, now is the time to throw them in and they will at least get the time of day. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH4OqjOjLpvpq7dMoRAldNAJ4kDtEv4ktKAVdw9UlW1G9+fEUMvgCfdH1e
Re: Openmoko strives for openness
On Wed, Mar 19, 2008 at 9:17 AM, Michael Shiloh [EMAIL PROTECTED] wrote: There is a constant trend of moving these discussions from internal lists to public lists. Many Openmoko employees do this, but I'd particularly like to publicly thank Wolfgang Spraul for championing this and for setting up a culture that encourages everyone to think in these terms. I for one noticed, and I think it's pretty cool. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community