[Arm-netbook] CC3000 Wi-Fi for MCU

[Gordan Bobic]

lkcl luke wrote:
> On Wed, Jan 25, 2012 at 9:29 AM, Gordan Bobic <gordan at bobich.net> wrote:
> 
>> By that argument, take a ralink chip, put the firmware into flash and
>> burn out the fuse that enables writing to it, then modify the driver to
>> read the firmware from there.
> 
>  ok, so the ralink wifi is connected to... what?  the CPU?
> 
>  and the NAND flash is connected to... also the CPU?
> 
>  and thus the CPU must now load that firmware from the read-only NAND
> flash, and no other location, and upload it to the wifi?
> 
>  question: how do you prevent a general-purpose CPU from *not* running
> applications that will load that firmware from elsewhere?
> 
>  [ ... without of course running a DRM-locked OS.... ]
> 
>  answer: you don't, do you?
> 
>  and that's the problem.

Why is it a problem in the first place?

>  thus, it is necessary to consider solutions such as having a separate
> CPU which has, for example 2x USB-2 (one of which is client USB and
> the other is USB host), and that CPU having on-board NAND flash which
> can be made read-only, and that CPU having an application which is
> also read-only, and that CPU's application acting as a proxy of USB
> data once the firmware has been uploaded, and that CPU having the WIFI
> module connected to the USB host and the *main* CPU being connected to
> that separate CPU.
> 
>  this is the kind of thing that would be recommended for purchase via
> the FSF's web site.
> 
>  the only problem is that i can't find a CPU that's fast enough, small
> enough, has fast enough interfaces and also isn't an insane cost.

What is the gain, though? What is the underlying cause for the objection 
to firmware blobs? Ignore the ideological rhetoric - why is it 
_actually_ a problem?

Gordan