[Arm-netbook] Regarding Improv, EOMA68, Free Software and Open Hardware.

[Luke Kenneth Casson Leighton]

On Thu, Jun 26, 2014 at 2:50 AM, Henrik Nordström
<henrik at henriknordstrom.net> wrote:
> This is a response letter to the notice just received that the Improv
> project is being warpped up. Only trivially editied to fit the context
> of the mailinglist. (inital reply was sent privately)

> Just not sure I agree on the conclusions expressed in this letter
> however, claiming that "The Free software community does not seem ready
> at this point to make a concerted stand on the pressing issue of
> hardware freedom".

 that's actually very sensible i think to say because it either a)
wakes people up or b) makes them think "hang on is it true??"

> people relations. And in addition starting at the wrong end of the table
> trying to make a standard for hardware without first being familiar with
> hardware designs and considerations. Resulting in a project trying to
> make a leap before it knew how to crawl or even less walk, with a very
> high level of uncertainty as result. It will probably get there in the
> end, but getting there takes a lot of time and experience.

 and you know what? i'm actually relieved, because this is supposed to
be a decade-long standard.  if we'd had the funding, we would have
gone ahead, the EOMA68 standard would have SATA and it would have
about one SoC available per two years *or less*.

 the changes i've made since it started open it up to 23or more SoCs
*per year*.  i am also considering - reluctantly - reserving the 5.0mm
card height for 1280x800 capable SoCs and the 3.3mm card height for
1920x1080 SoCs (over the 24-pin RGB/TTL that is)

> As for Improv, by the time it entered (the hardware) it provided nothing
> unique that developers could not find elsewhere. Also most people in my
> humble opinion already had given up on EOMA68 as a serious initiative
> due to the numerous problems that project had already seen. I still back
> the basic ideas of EOMA68, but not sure about the current realization of
> it, aiming purely at low end market in interface specifications.

 but henrik, this is entirely entirely missing the point.  the entire
point for end-users is that you buy 1 CPU Card and share them across
products, saving 30 to 40% for doing so *and* having consistent user
applications and data across all products.

> Also,
> it has to be realized that any such specification do have a fairly
> limited lifespan and needs to be revised regularly, which somewhat
> nullifies the benefits.

 no.  the interfaces were picked because they have all been around for
over a decade, and they are anticipated to be around and in
mass-production use for at least another decade.

 do you see USB being retired in the next 10 years? (serious question)

 with over 2,000 active LCD panels on panellook.com do you see RGB/TTL
being retired in the next 10 years?

 likewise I2C, likewise GPIO, likewise SD/MMC, likewise SPI, likewise
UART, likewise ethernet.

 if one of them was e.g. Firewire i would say there was a problem.

> For the sake of software development Improv isn't really needed, and was
> not needed at the time of launch. There is and was fully OSHW solutions
> available that covers the hardware functionality of Improv (minus the
> exchangeable "CPU module" part). In particular I am thinking of Olimex
> Olinuxino A20 MICRO (and it's related cousins), giving the same
> performance specifications as the selected EOMA68-A20 module, but with
> much richer hardware interfacing capabilities and of course 100% OSHW,
> by a established manufacturer who works with believes in OSHW.

 ... except doesn't take a stand on GPL violations, and distributes
illegal copyright-violating product, but _apart_ from that they
"believe in OSHW", yes.

 no i am fully aware that the CPU Cards have "less interfaces" quotes.
that is entirely deliberate, as the interfaces had to be:

 *  lowest-common-denominator
 *  hardware-level upwardly self-negotiating (faster rates over more wires)
 *  decade-long lifespans

 then the base-board uses e.g. Embedded Controllers to "fan out" the
missing functionality in a way that is *guaranteed* to be available
*regardless* of the SoC in the CPU Card.

 in this way we can ensure that even the lowliest SoC (for example the
IC1T which is barely struggling to meet the absolute minimum of EOMA68
requirements) stands a chance.

 if we had put e.g. CSI or TS on, or eDP or MIPI, then only the
absolute absolute top-end SoCs could be included, and even then some
of *those* would be excluded simply because they were so specialist
that they did not have the interfaces available.

 look at the example of SATA.  i wanted it - everyone wanted it - but
in the end it had to go, because it's not lowest-common-denominator
(and USB3-to-SATA ICs can do a good enough replacement job).


> I have much more to say on the subject, but enough for tonight. Feel
> free to contact me if you want me to elaborate further.
>
> Regarding refund of my Improv "investment". Don't sweat over it.

 you need to tell the improv team that, not me.  remember, they were
just a 3rd party client, so we were waiting for the cash order.  all
the money is held by that 3rd party.  so you need to tell *them*, not
me, ok?

> I'd
> rather see you focus on moving forward than how to cover the refunds.
> Failures are all natural path of moving forward and learning.

 true.   ain't quitting.