Daniel,

> The http://www.cardaccess-inc.com/products/index.php?a=wlan_burt is an
> SD sized Atheros AR6001GZ chipset device (exactly the same chipset as
> the openmoko freerunner as far as I can tell), so perhaps that + the
> microSD to SD adapter mentioned earlier is an option for people who
> refuse to use any hardware that requires binary blobs.

He he. Yes, for people who (please don't take this personal) refuse to use
non-free software unless it is hidden, the AR6001 might be an option.
Let's just be very clear. The AR6001 has the same binary blob as the 6002,
only that it is stored in flash. Flash is more expensive and needs more
power than RAM, so they switched to RAM.

But please - for you or any other free software supporter out there, don't
follow this wrong AR6001 path. First of all the binary blob also exists, just
hidden in flash. The flash update utility is very guarded by Atheros.
But even worse - the firmware in the chip has several versions, during my
time at Openmoko we encountered 1.1, 1.3 and 2.0. The GPL driver and binary
firmware are sending binary data structures back and forth. At Atheros, the
sources for _BOTH_ the firmware and GPL driver are kept together in one
revision control system. The build process produces both the binary firmware
for the chip, as well as the corresponding GPL driver. There is no continuity
between the GPL driver sources produced to match the different firmware
versions, 1.1, 1.3 and 2.0, or any future ones they may have done since.
Actually, releases are made for each customer! The trunk in the revision
control system is just the 'unstable' branch basically, and once they have
a customer, they allocate a certain amount of testing/bugfixing/polishing
resources to that customer, then they branch in the revision control system,
and work towards a release for that customer. Of course in this process the
binary firmware blob and GPL driver are always seen as a pair. There is no
independent development of a GPL driver. So actually you have as many GPL
drivers as you have Linux customers.

My take on this: Let's stop thinking that it's a good idea to hide non-free
software and call it hardware. We must not be afraid to realize that there
is a lot of non-free software running on these chips. We need to understand
this software better, and write free replacements. Then make our own
copyleft chips.

Once we have a totally free chip (of course including the firmware and driver
under GPL), I know you will support it :-)
Cheers,
Wolfgang

On Mon, Jan 18, 2010 at 10:33:20AM -0500, Daniel Clark wrote:
> On Sat, Jan 16, 2010 at 11:26 PM, Wolfgang Spraul <wolfg...@sharism.cc> wrote:
> > Daniel,
> >
> >> I'm vaguely aware of this, but since the driver is fully GPL most
> >> likely people will eventually get it working quite well; this seems to
> >> be what happened with ath9k, which sucked for a long time but in
> >> 2.6.32 seems to be very nice.
> >
> > I highly doubt that will happen with the 6001. I don't want to go into the
> > details of the firmware revisioning here etc. It just won't happen.
> > Why do you think the KDDI microSD card (which may never be produced) has
> > a 6001? The 6001 is an old chip and not recommended or supported for new
> > designs. The 6002 moved away from flash so you need to load a binary blob
> > at boot time (more about that below).
> 
> I was under the false impression that everything in the Atheros AR600x
> series didn't need binary blobs; apologies.
> 
> The KDDI microSD card specifically says it uses AR6002, so I guess it
> is no better than the card you guys were already considering.
> 
> The http://www.cardaccess-inc.com/products/index.php?a=wlan_burt is an
> SD sized Atheros AR6001GZ chipset device (exactly the same chipset as
> the openmoko freerunner as far as I can tell), so perhaps that + the
> microSD to SD adapter mentioned earlier is an option for people who
> refuse to use any hardware that requires binary blobs.
> 
> Cheers,
> -- 
> Daniel JB Clark | http://pobox.com/~dclark
> 
> _______________________________________________
> Qi Developer Mailing List
> Mail to list (members only): develo...@lists.qi-hardware.com
> Subscribe or Unsubscribe: 
> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer


_______________________________________________
gNewSense-dev mailing list
gNewSense-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnewsense-dev

Reply via email to