[Arm-netbook] EOMA Specification / Documentation Issues

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Sep 30, 2016 at 12:06 AM, Joseph Honold <mozzwald at gmail.com> wrote:
> On 09/26/2016 03:39 AM, Luke Kenneth Casson Leighton wrote:
>> *deep breath*.... ok so i've been writing non-stop since i previously
>> replied, and can only reasonably say to be 15% through what's
>> needed (!)
>>
>> http://elinux.org/Embedded_Open_Modular_Architecture/EOMA68#EOMA68_Software_.2F_OS_Requirements
>>
>> l.
>
> This helps to understand more about the project goals. Thanks. I've
> read thru it a couple times already and yeah, it's a lot to grasp :)

if i'm absolutely honest i can't quite believe it myself.  sure, i
defined the goal, and was even aware of the intended scope... but
actually then walking through every possible permutation of every
potential disruption and otherwise-accepted industry practice for each
and every role... faaaaaakin eeeelll :)

at least you didn't go (as i would expect many mass-volume
manufacturers to do), "wtf??? whaddyamean i can't use a locked 3G
modem in these products??? whaddyamean i have to go to the extra
expense of putting in a socket so that people can easily replace the
WIFI, and whaddyamean i can't use the industry-standard practice of
DRM-locking the WIFI's id to the BIOS because that's how we GET OUR
MAAAOONEYYYYYY by f*****g people over when it comes to upgraddiiing
and they have to come to uuuus to buy overpriced WIFI cards, waaaa,
waaaa, i wannt my moommmeeeyyyy you're being soo unfaaaaair, waaaa,
waaaa"

ahem.  sorry about that :)  i thought really overdoing it would make
the point better.  it has to be said though that there are some of
these kinds of "wtf??" moments even for libre pcb designers.  a way to
get across how "free/libre" does NOT mean "free to do what you like
with blatant disregard for consequences" is the "Bad USB" attacks.

if this was "USB" we were talking about, instead of EOMA68, how would
you see a product that did the exact same thing as the new "Bad USB"
devices would be viewed, even if the schematics and PCB CAD files were
made available under a libre license?  (for those people not familiar
with "Bad USB", they basically use the 5.0v socket to charge up
internal capacitors, then use that to release massive 240+ volt AC
power spikes down both the power lines and the USB signal lines).

would it be *okay* for someone to "claim that that is USB
compliant???"  is it even okay that they use the word "USB" in the
phrase "Bad USB" [serious question].


whilst we might argue that the above example is "clearly not intended
to be compliant with USB", what about the failure of cable
manufacturers recently to comply with the power specification of USB
3, recently?  those are clearly *intended* to be compliant with the
power specification, but they are failing to put in the right
resistors to indicate what current is permitted to be carried, and/or
they are failing to utilise wires that are of sufficient thickness,
and/or they are simply not designing the connectors and/or PCB layout
correctly in order to handle that kind of current.

should we say with hindsight that this is a failure of the 3rd party
manufacturers, or is it the failure of the USB Association, or is it
both?


> I'm going to make what I want for myself now and see how it pans out
> in regards to compliance, keeping in mind what's in the spec already.

 it's the hardware side (the pinouts) that have had the most
attention, obviously (like i said) creating the hardware itself is the
first priority: that's why this campaign was done, duh, to get actual
hardware out to people (get over that all too common "vapourware"
barrier, you know what i mean?)

> It will be a functional prototype for personal use. If down the road,
> others show interest then I'll deal with any changes that need to be made.

 if you're happy to work in public - i.e. release what you are doing
*all the time* as opposed to "i'll release it when i'm done, because
i'm scared that people might criticise what i'm doing or copy it and
not collaborate" - then two very important things happen:

(1) we can review the situation easily, and can clarify the relevant
role "Libre Engineer" in the EOMA68 specification as it goes along

(2) we can invite other people to collaborate.  already i am trying to
encourage the hand-held games console team to get in touch again
(perhaps set up a separate mailing list and irc channel for them
because this one is definitely overloaded now) because they too need
the exact same SSD2828.  but if both of you are working to the
principle "i'll release it when it's finalised", there's absolutely no
point considering doing that.

l.