[Arm-netbook] CC3000 Wi-Fi for MCU

[Gordan Bobic]

lkcl luke wrote:
> On Wed, Jan 25, 2012 at 10:09 AM, Gordan Bobic <gordan at bobich.net> wrote:
>> 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?
> 
>  because it is non-free firmware.  anything that is non-free firmware
> *must* not be allowed to be run - period - within a FSF
> Hardware-Endorseable product.  if you run *any* proprietary
> applications, you lose the FSF Hardware-Endorseable Product Status.

Sure, but apart from rhetoric and posturing, what would be the advantage 
of having the firmware blob in the hardware vs. having it in software 
updatable?

>  why is this something that i would like to cover?  it is because i
> would like _everyone_ in free software to be involved in the EOMA
> initiative.

As somebody pointed it out already, since there is currently no such 
thing as WiFi module that doesn't handle firmware in the side-load way I 
don't think it'll make any difference one way or the other.

>  not just those people who are happy that they have a _little_ bit of
> freedom in what they are allowed (permitted) to run on the device that
> they own and have purchased, but also those people who refuse to even
> _purchase_ the device if it does not let them program every single
> programmable device within the system.

At the moment their only choice is to not use WiFi anyway. Nothing 
changes and the EOMA card product isn't in any way disadvantaged. So 
from the purely pragmatic PoV, I don't see a problem.

>>>  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?
> 
>  it's that they are non-free.  if they're non-free, then the source
> code must be available.  if the source code is not available, then it
> must be inviolate (hardware-only).
> 
>  that's the rule.  there is no arguing with this rule: it is not up
> for negotiation.

See above under "rhetoric and posturing". Meanwhile, back in the real 
world where getting something that works is more important than having 
an idealized concept that hasn't even made it onto paper....

>  however, please feel free to not participate in this discussion,
> which is at the extreme end of software freedom, bearing in mind that
> i, personally, have taken on a comprehensive goal to allow *everyone*
> to participate in EOMA, and that that goal may not necessarily suit
> _you_, personally, to participate in, in its entirety.

I guess we're not having WiFi, then. :)

>  i welcome people to participate in whatever capacity and at whatever
> level of software freedom that _they_ feel comfortable with.

Personally, my biggest gripe about closed software of any sort is 
maintainability and portability. Software nowdays, as a general rule, is 
_crap_. If I have the source I don't have to rely on the software vendor 
to fix the problem I'm seeing (as a general rule this takes months if it 
ever happens at all). The other important thing _to me_ is platform 
portability - I use multiple platforms all the time (x86, ARM, MIPS, 
PPC) and need the same software to work on all of them.

So while I have a very real requirement and interest in OSS, I think 
firmware requirements are taking the concept a bit too far. On those 
grounds, no hard disk or graphics card is FSF endorsable since they all 
have flashable BIOS-es and firmwares, even if the drivers don't have to 
side-load the firmware.

Gordan