[Arm-netbook] CC3000 Wi-Fi for MCU

[jonsmirl at gmail.com]

On Tue, Jan 24, 2012 at 12:17 AM, lkcl luke <luke.leighton at gmail.com> wrote:
> On Tue, Jan 24, 2012 at 1:45 AM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>
>> We have a design which could be switched to a msp430 so I am
>> interested in getting some real pricing data on the CC3000 modules.
>
>  jon.... do you think you could design a FSF-Hardware-Endorseable WIFI
> module?  (preferably in Mini PCIe USB form-factor)
>
>  i've been talking to Dr Richard Stallman and there isn't a single
> modern WIFI module available, that i can find, that does *not* require
> non-free firmware.

Accord into the his rules we need to ban all cars, televisions, video
games and refrigerators. Even the keyboard you are probably typing on
and all hard disk drives. His position is unreasonable.

The only wifi that is close is the old Marvell Liberatas chipset used
in the first OLPC. They started an open source firmware project for it
but no one finished it. They had the doc but couldn't find anyone who
would waste a couple years writing it.

Just put on a current Ralink chipset and don't ship the firmware. Then
each individual can make their decision as to whether they want wifi
or want to remain pure. The Ralink chips are the cheapest available
that work reliably.

Open sourcing graphics is a very different problem. The closed source
graphics were keeping the future of the Linux environment from moving
forward.  Without open source drivers Linux was going to be stuck
using the X server forever. Now we are able to build the Wayland
project. This is not the case with wifi firmware.


>
>  if you or anyone else happens to know of one, such a module is
> seriously seriously needed, almost regardless of cost.
>
>  the requirements are that if there is non-free firmware, it *must*
> repeat *must* be in "hardware", unmodifiable, untouchable,
> un-bypassable.
>
>  here are some schemes which are *not* suitable:
>
>  * uploading the firmware from an embedded processor which has a PROM
> on it, and then doing "switching" of the USB (or SDIO) pins over to
> the main processor.  the reason why this is not acceptable is because
> as soon as the "switching" is carried out, the main processor could
> then send *another* reset and *another* "firmware upload" of a
> proprietary firmware block that was obtained off of the hard drive
> attached to the main processor.  this is NOT acceptable.
>
>  * connecting a 54mb/sec WIFI chip to a low-cost processor with only
> 12mb/sec SDIO capabilities.  that's just... daft.
>
>  * inserting an FPGA into the mix, to analyse the data stream in
> real-time, to spot a "firmware upload" and disconnect the WIFI if one
> is noticed.
>
>  ideas anyone?
>
> l.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk



-- 
Jon Smirl
jonsmirl at gmail.com