[Arm-netbook] EOMA Specification / Documentation Issues

[Luke Kenneth Casson Leighton]

btw joseph, could you please use a mailer that doesn't place entire
paragraphs onto a single line?  the general rule for mailing lists is
to have line-breaks approximately every 70 chars or so.  usually this
can be achieved by ensuring that you reply "plaintext" mode only,
disabling "rich text" for replies.


On Fri, Sep 23, 2016 at 4:41 PM, Joseph Honold <mozzwald at gmail.com> wrote:

>>  the fact that you now actually want to know means that it's time to
>> actually thrash it out and document it properly.
>>
>
> Yes, this should be documented. More on this at the end.

ack.

>> to even consider doing anything else would *automatically* bring the
>> standard into disrepute (even before it got off the ground).
>
> Sure, it's probably not the best idea to use stickers. But I have a another idea. You continue to have the restrictive EOMA specification but create a separate permissive specification that utilizes the EOMA spec as a basis. Call it something significantly different and not likely to be confused, maybe PEMA (Permissive Embedded Modular Architecture). These two specs would be compatible on a hardware level (and retain the free/libre software requirement) with other certain restrictions removed (eg, the bootable housing restriction). I can sell my bootable housing as compatible with the PEMA spec.

unfortunately that doesn't work, because of the following scenario:

* someone buys an EOMA68 Housing
* they also buy an EOMA68 Card
* they are happy (because it "Just Works")
* they then get sold something which is sold to them as an "Upgrade" EOMA68 Card
* it fits into the slot.
* but it doesn't work

after a LOT of trouble, and annoyance, and a very very public and
embarrassing fight on a forum, where various "Consumer Watchdog
Groups" get involved, which is then picked up by the BBC, *and* the
Guardian newspaper, *and* TheRegister *and* slashdot (all of which
generates MASSIVE confusion thus bringing EOMA68 into total disrepute
as a "Just Plug It In, It Will Work" standard)...

... after all that, it turns out that it was some fuckwit china 3rd
party clone who took a PEMA card and deliberately mis-sold it as
EOMA68-compliant.

the answer's no.  sorry.


>> these and many more scenarios make it flat-out impossible to make any
>> kinds of "Lowest Common Denominator" assessments.... or more to the
>> point: the "Lowest Common Denominator" is *literally* the "Empty Set".
>> i.e. there *are* no common boot methods from Housings.  period.
>
> I still don't think the idea of *allowing* (not requiring) housings to be bootable is unworkable.

 oh.  allowing?  of course not.  that's perfectly reasonable.  but
remember: the EOMA68 standard is based exclusively around *mandatory*
requirements.  i've told the story several times now from my
university professor's *two* separate experiences with standards that
were lost golden opportunities, thanks to "optional-itis" - one of
those was the X.25 standard.

> The "lowest common denominator" here is the USB bus

ah!  no it's not!  there is no guarantee that Housings *require* USB
peripherals at all.  thus the idea must remain "allowed" rather than
"mandatory as part of the spec"

>  and SD/MMC bus on the EOMA68 connector which *IS REQUIRED* as per the spec

yeeeees....

>  and *could* contain bootable media.

 wark-wark.  the keyword here is "could".  it could also not have any
connection at all, or it could be used for GPIO, or it could be used
for connecting to SD/MMC-based WIFI..

you just don't know (because that's down to the Housing Implementers)
and that's why booting from Housing-based media must remain "allowed"
rather than "mandatory as part of the spec".


>  This means, if a housing chooses to implement the SD card, it *might* be bootable media.

yep. that's why booting from housing-based media has to be "allowed"
(i.e. "not prohibited"), but not "mandatory".  but (re-reading what
you mention below), if it is added to the spec that it is optional to
sell Cards which *always* look for external boot media on Housings and
will *FAIL* if that media is not present, that is NOT okay.

so it has to be something that the end-user chooses for their own
convenience, rather than being something that is RELIED on.


> Let's switch to the Pocket QWERTY Computer as an example instead of router. The A20 cpu card ships with Parabola, a desktop/workstation style OS. I want my customers to have a good experience when they use my handheld housing. Using an OS tailored for desktop/workstation computing is *not* a good experience on a small screen (I've tried this with the Zipit and it "worked", but was not very productive). I can make this transition even *easier* for average consumer by supplying a SD card with Replicant or some other custom libre distribution designed for small screens.

or, you could supply multiple OS SD cards for them, and set up the
NAND to look an OS on the A20's MicroSD Card slot.

yes, i'm keenly aware that the alteration of the OS to suit LCD size
is a Big Deal.  putting it another way: it's a PAIN IN THE ASS! :)

it's made even more complicated (for the A20) by the fact that the
people who did the sunxi u-boot and mainline kernel didn't think about
this in advance: they've specified that the LCD shall be set up by
u-boot and u-boot alone, leaving absolutely no possibility for
changing the LCD size without a total reboot!  oops...


> I could partition the SD card and put any number of distributions on there with a boot menu. This way, they do not need to fuss with installing an OS to the cpu card NAND that works *well* with the housing. When next years latest and greatest cpu card comes out, I can get a beta version of the cpu card, produce an OS that works with my handheld and publish it on my website for free download before the new cpu card ships to customers. I could sell SD cards for cost+shipping with pre-installed OS for the new cpu card if the customer doesn't want to bother making an SD card. Easy-peasy for average consumer. Files on the cpu card NAND can be accessed easily via mounting so you still have access to all your data.

 yyep.  all perfectly reasonable.... and nothing to do with the
spec... but if the Card is incapable of booting *unless* that external
media is present, that's unacceptable.


> The A20 card has a micro sd slot. Is booting from this allowed in the spec?

 anything at the other end of the card - user-facing - is permitted.
there are absolutely no restrictions (other than anything protruding
must not physically impinge on the ability to insert the card into
Housings).

 so of course it's permitted: it's part of the Card.  it travels
*with* the Card.

 now, the key difference here between booting from Housing-based media
and Card-based media is: the Card-based media (removable or not) stays
*with* the Card.  it thus *guarantees* that the Card will boot.



> What if the next CPU card does not have an SD slot (it's not required by the spec)?

 now you're into "cheap-ass" territory.  people who pay cheap-ass
money for cheap-ass goods can expect to "get what they pay for".
given that we're talking saving $0.20 for a lack of a micro-sd card
slot, you know we're talking *real* cheap-ass money-misers :)

 no, if manufacturers are saving $0.20 you know that they're probably
trying to produce something for the $12 to $15 retail market.  all
bets are off as to "features" at that point.

 basically at this level of cheap-ass-ness as long as they're
compliant with the "bare minimum" EOMA68 spec i'll tolerate it.


>  Now average consumer is forced to install a different OS to internal NAND if they want a *useful* device.

 or, because it was so utterly cheap-ass they just buy another $12 to
$15 Card with a handily pre-installed OS.  so in these circumstances,
end-users would, instead of buying a replacement MicroSD card, would
just treat the ENTIRE CARD as being "A Computing Appliance".

 buying one that has Android preinstalled ($12) and another with Games
preinstalled ($12) - heck you could even have completely different
Games Cards just like you had or have Cartridges (Nintendo, Gameboy) -
is perfectly reasonable.


> What happens if average consumer installs handheld OS to their A20 card NAND, plugs it into their laptop or desktop? Handheld OS for a workstation doesn't seem very *useful*.

 i don't see why that has to be considered to be absolutely true.  i
hear people complaining "i'm using my phone but the screen's too
small" - would it not be incredibly convenient to just temporarily pop
out the Computer Card and pop it into a Housing with a larger screen,
even for five minutes, just to view a document properly?


> My suggestion here is to make a housing "just work" as the *housing* is intended. If my housing doesn't work as intended when the cpu card is plugged in, it puts my company *and* the standard into disrepute.

 you can always sell multiple OS cards and have end-users swap them
over.  in a few years time i envisage that we will have other methods
to deal with this, starting most likely with VMs / OSes that are
selected at boot time (exactly as you describe), and moving to
adaptation at the OS level later (including icon size, menus and so
on).

 certainly i know that KDE is capable of adapting applications
dynamically, by way of simply specifying a different "spec" file.
applications can therefore *dynamically* adapt to screen size or other
features (such as touchscreen / mouse).

 this *really* is still at the very early phases, but it really *has*
been thought out.  the last discussions on this "OS adaptation" were
something like three years ago, though.


>> hmmm, good point.  need to make sure that there's proper training for
>> retailers and that they understand the consequences of misinforming
>> their customers.
>
> Here, you are defining "desktop OS computer card" which isn't defined anywhere in the spec. I see no claims in the spec that there is such a thing as a desktop computer card, router computer card, phone computer card, etc etc.

 that's correct.

> With your claim of “just plug it in: it will work”, the retailer would be justified selling a *ANY* cpu card and *ANY* housing together and expect it to work. Is it the right thing to do? No.

 no.  retailers can only be directly involved once the OSes have been
adapted to cope with the variation.  that might take a few years: i
can live with that.

 as long as it does not bring the standard into disrepute in the
process, i *might* permit a *limited* retail sale of say products
where the CPU Card is preinstalled in the Housing, or where the LCD
size is sufficiently similar between two Housings so that the
difference is effectively immaterial (say, a 1366x768 LCD screen size
for a Laptop and a 1280x800 for a tablet - something like that).

 remember, the primary purpose here is to ensure that the units on
both sides don't end up in landfill.  if that's likely to happen, i'd
rather the units weren't sold AT ALL (until they and the OSes *are*
ready).

 this is the difference between this project and a standard commercial
profit-maximising outfit.  a standard profit-maximising commercial
outfit would rush ahead and get things out the door as soon as they
could.


> If you sell me a cpu card and a housing with the claim that “just plug it in: it will work”, it should work as intended as a complete package. If I have an old cpu card collecting dust, I should be able to use it under the claim “just plug it in: it will work.”

 within reason... and within the expected cost, yes.  in the 2nd-hand
market and "recycling / re-use" market, i expect there to at least be
*one* technically-competent person who makes the necessary
phase-change adjustments before selling/handing the item(s) over to
the next non-technical end-users who will expect that claim to be
true.


> Allowing the housing manufacturer the *option* to boot from media can assist in fulfilling this claim.

 *thinks*.... the moment i hear the word "option", that is an instant
red flag.  options are what destroy standards.  i spent five years
analysing a range of standards, and 25 years ago it was deeply
impressed onto me through the example of X.25 quite how dangerous
"options" are.

 so, to reiterate above: if the Card will *not function* unless that
external media expected to be on a Housing is discovered, that is
completely unacceptable.

 now, on the other hand, if there is at least some level of
functionality (whether it be Lowest Common Denominator or something)
then that *might* be tolerable.  if there is a "Download A Full OS"
button, that also might be tolerable.

 it's complex, basically, and would need careful evaluation on a
case-by-case basis.


> Mr. Salesman can have a rack of SD cards to sell to average consumer and provide a free or paid service of installing the OS on the card for them. Or, average consumer can use my nifty cross platform free/libre SD Card Imaging program to download and install the correct OS for them. Easy-peasy, nowhere near impossible.

 yes.  these can go into the main MicroSD slot actually on the Card.
bit of a pain that they have to be for a particular CPU, so it would
probably make more sense (given the low cost of the Computer Cards
themselves) to just sell the OS preinstalled (an Android EOMA68-A20, a
ChromeOS EOMA6-A20, a GNU/Linux Distro EOMA68-A20 etc etc. blah blah)
but there you go.


> Again, my issue here is the misleading/lofty claim of “just plug it in: it will work.”

 no, that's the *goal*.  you've misunderstood.  it's the *goal* that
that claim be true.  remember, we're still working this out!  so,
you're helping to refine what is and is not permitted.

 but everything gets "judged", "does the claim still hold?"  if the
answer is "yes" then it's okay.  if the answer is "no" then, clearly
we either wait until more work (on OSes for example) has been done, or
we just have to live with it.


> The way I understand it after your explanations this phrase should be "just plug it in: it will work, but if you want it to be useful you'll need to install and configure software yourself" which is completely against the idea of the project.

 if there's a techically-literate person in the loop / scenario, i
find that to be perfectly acceptable.


>  The use of this phrase needs to be rethought and/or reworded. Since ethics is a hot topic on the mailing list these days :) ... it's unethical to claim “just plug it in: it will work” when the housing doesn't work as intended. Sure, it will boot and be some sort of Frankenstein device, but it's not a useful device.
>
> Let's try a silly example. I sell you a Harley Davidson Motorcycle (without an engine installed) and I sell you a separate lawnmower engine that fits perfectly into in that motorcycle. I tell you "just plug it in and it works." You go home, plug in the engine, strap on your helmet, start your engine and ... you ride free on the open road at a whopping 1 mph. Sure, it works, but it's not a good experience. Obviously, this example isn't very good in relation to EOMA and software, but it makes the point of customer dissatisfaction when the claim is "just plug it in and it works".

 well if you look more carefully you'll see that i actually qualified
this a number of times over the years (bear in mind that you're new to
the conversation so won't have seen this) with the (sotto voice) of
the more honest salesman, "But You Get What You Pay For, Know What I
Mean".

 if people pay $12 for a Computer Card, they Get What They Pay For.

 normally this was in the context of people paying for Cards with USB
1.1 interfaces instead of USB 2.0 interfaces, but the same rule
applies: if you pay only $12 retail for a Computer Card where the
processor is a single-core MIPS 1ghz (or less), you cannot expect it
to perform miracles.




>> some of these housings will take 20 watts or contain Lithium
>> Batteries.  20 watts is more than enough to cause an electrical fire,
>> and a Lithium Battery if overheated or otherwise mistreated could
>> explode.
>>
>
> Understood. And this leads me to the specification which, if documented properly, would reduce the likely hood of an incident.

actually, we've already had some 3rd party implementers fail to
listen, implementing *hardware* that did not comply to the
specification.  they also tried to take control of the EOMA68 Standard
by making public statements without consultation and without
authorisation.  i had to publicly reprimand them and make it
absolutely clear - publicly - that they were acting in a completely
unauthorised fashion and were not permitted to make further statements
or claims.

so no: even from this one incident, we know *already* that people can
and will fail to read the specification properly. a Compliance Test is
therefore absolutely critical.


> At a minimum, there needs to be some sort of *disclaimer* / *notation* / *message* at the top of the EOMA specification page that indicates it is a "work in progress" and possibly point to a section (at the bottom/separate page?) with all of the unwritten/unfinished requirements/proposals/ideas.

good idea.  just have to find time to do that :)


> I was under the impression that the standard was mostly complete

the hardware side is.... but it's a really complex project, and it's
still at an early phase.  this current phase is where, with the
hardware in place, the software can begin to be created.

we had to *have* hardware in order for there to *be* the opportunity
to get the software ready... so that's next.


>  and only after the fact, this information is coming to light (my fault for lack of due diligence in research and asking questions). I understand you've been working on this for a long time and *you* have this all worked out in your head, but I (and likely others) surely don't. If I had known how restrictive the specification is going to be, I would have thought much harder about using EOMA for a project/product. I obviously misunderstood how far along the project is. Perhaps the roadmap you mentioned previously would help.

apologies - i haven't had time to write one.  this is one of the
down-sides of there not being enough other people involved.  expecting
other people to be committed for five years without payment of any
kind and without hope of financial renumeration for potenially several
more is a bit too much... so all the people that *were* expecting to
financially exploit this project (and jeapordise it in the process)
have all left (some of them are still causing huge problems, but
that's another story).


> Based on the specification on the elinux.org wiki, I had plans/ideas which now need to be completely changed to support restrictions that are nowhere to be found (not easily anyway).

review what i said above about being able to boot from removable media
actually on the Card itself: i think you'll find (after evaluating
that) that the perceived restrictions are incorrect / unjustified /
insert-suitable-word-here.


> It's quite frustrating to hear "you can't do that" time and again. My impressions of the specification based on the information readily available are clearly incorrect. I see it more as a hardware spec with the additional requirement of free/libre software being provided/available. That's my interpretation and is obviously incorrect.

yes.  this is a mass-volume standard that *happens* to have libre
software as a preference (where closed / proprietary software is
tolerated under certain strict circumstances).

> I understand the basis for your restrictions against booting from a housing, it just doesn't seem like a good idea to me and isn't very free/libre, IMO.

anybody is perfectly at liberty to completely ignore the EOMA68
standard (from a software perspective) - in doing so they are NOT
permitted to call it "EOMA68 compliant", that's all.

manuel's team (with the hand-held games console) will be choosing this
route.  they will simply be using the EOMA68-A20 as a "module".

if you recall, i brought this up on the OSHWA mailing list a month or
so ago.  there is a naive expectation that the Four Freedoms may be
applied to create a Hardware Compliance Standard without further
adaptation or taking into consideration the consequences:.  that
simply isn't true.

so we have the scenario where the OSHWA creators have failed to add a
disclaimer or add any indications that someone who puts an OSHWA
"sticker" on a product is not liable for any damages, and that the
person doing so is simply blithely permitted to put that sticker on,
regardless of the fitness for purpose *of* that hardware, thus
bringing the *ENTIRE* OSHWA Certification process into disrepute and
exposing its writers to massive liability!

they seem to have ignored my advice and warnings about this, but the
fact that i have mentioned it discharges my obligation to them...

the fact is that we simply cannot just naively create hardware
standards - even Open ones - and expect that the Four Freedoms will be
sufficient or adequate safeguards all on their own.


> If you make it easier for manufacturers to provide a good user experience, then the customer is happy and will use it longer.

deployment to retail *WILL* be delayed indefinitely until that
statement becomes true.


> Don't get me wrong, I still think the idea is good and has good intentions. I'm happy to support it. I'm just pointing out issues I see to hopefully make it better.

 appreciated.

 so.  summary:

 (1) use the A20's on-board SD card slot. you'll be able to do what
you're expecting (deploy multiple OSes)
 (2) don't worry about cheap-ass Cards.  people Get What They Pay For.
 (3) technical users are expected to be involved in transforming /
repurposing 2nd-hand cards
 (4) "Just Plug It In, It Will Work" is qualified by sotto-voice "But
You Get What You Pay For"
 (5) Hardware's ready so that software can be worked on
 (6) Four Freedoms cannot be deployed as-is to Hardware Standards.
 (7) Retail deployment is DEFERRED INDEFINITELY until such time as the
expected outcome is true.  NOT the other way round.

errr... i think that's it.  let me know if (1) works for you.  i think
it should.

l.