[Arm-netbook] CC3000 Wi-Fi for MCU

[lkcl luke]

On Wed, Jan 25, 2012 at 10:52 AM, Gordan Bobic <gordan at bobich.net> wrote:
> 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,

 this is _not_ about either rhetoric or posturing.  please get such
stupid notions out of your head.  this is about supplying loyal
customers with a product.

> what would be the advantage
> of having the firmware blob in the hardware vs. having it in software
> updatable?

 if you do not respect software freedom at its absolute extreme, there
is absolutely no advantage whatsoever, and, in fact, there is a
significant financial penalty for respecting software freedom.

 ... however given that there is, quite literally, absolutely zero
persons providing _any_ WIFI modules that are FSF
Hardware-Endorseable, the first people to do so will walk away with
the entire market.

>>  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.

 you don't understand: i *have* to find a solution.

>>  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.

 precisely.

> 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.

 please get such notions of considering "pragmatism" out of your head.
 i *have* to find a solution, in order to serve these loyal customers.

>>>>  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".

 see above under "serving the customer".

 l.