[Arm-netbook] CC3000 Wi-Fi for MCU

[lkcl luke]

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.

 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.

 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.


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

 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 welcome people to participate in whatever capacity and at whatever
level of software freedom that _they_ feel comfortable with.

l.