[openmoko-announce] Crossroads

Martin Lefkowitz lefko at sbcglobal.net
Wed Mar 14 16:01:08 CET 2007

They are all funky in this regard.  Having worked for a chip company
before I can tell you they are very afraid of this.  The issue with the
way the architecture went, as I think I said before, is that more
registers are exposed to the host because the chip only does the real
time aspects of the protocol, the lower MAC, and the High level
controller, and upper MAC,  is actually in the driver   This is
different than the prism where they tried to make it look like an
ethernet device.  Believe me the Prism should have died a horrible death
a couple of years before they actually did.  The only thing that saved
them was the fact that the consumer was immature and couldn't tell the
difference this includes end user as well as system developer. 
Harris/Intersil/globespan aslo screwed my company by raising a lot of
fud about 802.11g.  Very short sighted...  (I need someone to slap out
of this here)

Anyway, all modern chipsets follow this model, the one I got from AMD
when they were in the business.  TI and Marvell have Arms inside the MAC
chip.  This reduces the issues but you still have the issue of more
registers being exposed to the chipset manufacturer's end user.  This
means whatever wacky way they want to use the chip has to be supported
by someone.  If you follow the logic of a chipset manufacturer it
ultimately winds up to them having to support it;

1. they have the real intimate knowledge of how the chip works

2. if they do not use that knowledge then they don't sell chips.

That intimate knowledge is a very limited resource in the FAE(s), but
mostly in the engineering team which is working on trying to keep ahead
of the other chip companies that are working on new differentiators for
the chip, or the next gen chip.

This is the bind that Sean is in.

In my opinion, unless there is another company that can meet his
requirements, the only real answer is to have an SDIO interface and let
the end user/developer decide how to load a binary into the kernel from
the chipset vendor.  BTW take a look at Madwifi and see who actually is
supporting it. 

OTOH Marvell is the hot chipset these days and they do have an interface
that could expose less regs to the end user, the question is whether
they are willing to put the effort into Linux.  Which is what the HAL is
doing in Madwifi.  Can you get Marvell to support it?


> Date: Wed, 14 Mar 2007 10:07:45 +1100
> From: Grahame Jordan <gjordan at geicp.com>
> Hi Sean,
> What about the  Marvell® 88W8385 module used on the wifistix
> Open source drivers can be found at http://gumstix.com
> Cheers
> Grahame Jordan
> Sean Moss-Pultz wrote:
>> > Dear Community,
>> >
>> > OpenMoko is built around the philosophy that far more knowledge exists 
>> > outside the walls of a corporation than within. Internally, we're
>> > struggling with two issues. So we're throwing this out, hoping that some
>> > of you have can help us move past our current crossroads: 
>> >   
>> >   1) We can't find a WiFi Chipset with GPL'ed drivers -- We know 
>> >   this has been discussed (to death) on this list, but as we're 
>> >   beginning work on the next summer hardware refresh we still can't seem
>> >   to find a vendor that meets our strict requirements: Namely, we refuse
>> >   to put anything binary in the kernel. 
>> >
>> >   Marvell has some nice for larger devices (the 8388). But we need
>> >   one specifically for mobile phones (like the 8686). If somebody 
>> >   can help us find the right vendor, we'll give you a free Neo1973. 
>> >   
>> >   If you're a vendor and want to work with us to GPL your driver, we'll 
>> >   give you lots of business -- and a free phone  ;-)  
>> >
>> >
>> >   2) We don't have enough UI / Application developers -- If anybody 
>> >   meets (or knows somebody who can meet) the following qualifications:
>> >
>> >     	* >= 2 years experience with GTK
>> >     	* object oriented design and implementation w/ GObject
>> >     	* experience with writing GUI applications from scratch,
>> >     	* has software quality assets like:
>> >           o writing maintainable and reusable code
>> >           o refactoring
>> >           o design patterns
>> >           o identifying and extracting common application code 
>> >             into frameworks 
>> >
>> >   Familiarity with collaborative development tools such as:
>> >
>> >     	* bugtracker,
>> >     	* source control management,
>> >     	* wiki,
>> >     	* mailing lists 
>> >
>> >   is a necessity.
>> >
>> >   We've love to talk with you! Please email coreteam at openmoko.org with 
>> >   links to your previous work and a resume if you have one. (The latter 
>> >   is nowhere near as important as the former.)
>> >
>> > Thanks in advance for any help!
>> >
>> > -Sean
>> >
>> >
>> >   
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: gjordan.vcf
> Type: text/x-vcard
> Size: 311 bytes
> Desc: not available
> Url : http://lists.openmoko.org/pipermail/community/attachments/20070314/0e25e775/gjordan.vcf
> ------------------------------

More information about the community mailing list