Re: Openmoko strives for openness

2008-04-11 Thread Ian Stirling

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)

2008-04-04 Thread herve couvelard


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)

2008-04-04 Thread herve couvelard



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)

2008-04-04 Thread herve couvelard



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)

2008-04-03 Thread herve couvelard



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)

2008-04-03 Thread Federico Lorenzi


 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)

2008-04-03 Thread 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


Re: Openmoko strives for openness (smedia glamo)

2008-04-03 Thread Sebastian Billaudelle
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)

2008-04-03 Thread Wolfgang Spraul

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)

2008-04-03 Thread Shawn Rutledge
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)

2008-04-03 Thread Crane, Matthew
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)

2008-04-02 Thread Tom Cooksey
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)

2008-04-02 Thread Gabriel Ambuehl
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)

2008-04-02 Thread Andy Green

-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)

2008-04-02 Thread Rogen, Mario
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)

2008-04-02 Thread Gerald A
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)

2008-04-02 Thread Lorn Potter
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)

2008-04-01 Thread Harald Welte
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

2008-03-27 Thread ewanm89
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

2008-03-27 Thread Andy Green
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

2008-03-27 Thread 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.

  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

2008-03-27 Thread Andy Green

-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

2008-03-27 Thread Lally Singh
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

2008-03-19 Thread Lally Singh
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

2008-03-19 Thread Ortwin Regel
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

2008-03-19 Thread Shawn Rutledge
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