[Arm-netbook] EOMA Specification / Documentation Issues

[Joseph Honold]

I've changed the subject of this since it went way off topic from this QWERTY Handheld thread:
http://lists.phcomp.co.uk/pipermail/arm-netbook/2016-September/012099.html

On 09/22/2016 08:01 AM, Luke Kenneth Casson Leighton wrote:
>> ok, so it's not written in the spec yet.
> 
>  correct.  this is a massive project.  i've been the only one working
> on it, so all previous discussions were "theoretical", therefore were
> a bit nebulous, but they _did_ spur me to actually think about it (for
> several years, over several years).
> 
>  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. 

>> seems simple enough to me. two shiny stickers, one says EOMA68 HW Compliant, other says EOMA68 SW Compliant. If it's missing the SW, the manufacturer should supply you software :P
> 
>  the very fact that two separate and distinct stickers exist *is* in
> and of *itself* a clear violation of the simplicity principle "Just
> Plug It In, It Will Work".  the physical form-factor (the hardware
> connector interoperability) *is* a "guarantee" that "If You Can
> Actually Get It Into The Socket, Which Is A Simple Act Taking A Few
> Seconds And Requiring No Technical Knowledge, It Will Work".
> 
> let's try an analogy.  let's take an SD/MMC Card.  if you have on the
> outside of the SD/MMC Card "SD/MMC SW Compliant" and there were some
> that didn't, and you couldn't even tell if some little fuck in a back
> yard factory somewhere was REMOVING (or worse ADDING) stickers, how
> long do you think it would be before other Memory Card Standards took
> over in full force from SD/MMC?
> 
> no.  we simply cannot possibly expect people - force people - to read
> stickers in order to make technical decisions.  you plug it in, it
> works.  no thought required.
> 
> 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.

>>>> It just doesn't make sense (to me) to effectively lock someone to a particular bootloader/kernel that is potentially less capable by denying them compliance. As long as my housing works with free/libre software, what's the problem?
>>>
>>>  the EOMA68 standard is not merely about "working with free / libre
>>> software".   it's about making **100 MILLION AND ABOVE PER YEAR**
>>> free/libre Housings (and Cards) and ensuring that the returns rate is
>>> well below 0.001% (0.001% of 100 million a year is a hundred THOUSAND
>>> units a year, which is absolutely insanely large, and could well
>>> represent the entire profit margin for that year.  mass-volume is
>>> radically different).
>>>
>>>  you cannot possibly expect, with those kinds of numbers, that people
>>> will be capable of compiling their own kernels etc. etc. or even that
>>> they are capable of installing a new OS.  they want something that
>>> "just works".  if it don't work, they'll return it (or discard it).
>>

>> I don't expect the average consumer to compile any software. If you allowed housings to be bootable, (via sd card for example), a manufacturer can supply a sd card with the device and provide their own update channel.
> 
>  as noted further down: this scenario was discussed a few years ago
> and discarded as completely unworkable.  how would you:
> 
>  * ensure that a MIPS-based Card was capable of booting from media in
> someone *else's* Housing
>  * ensure that a RISCV-based Card or an FPGA Card was likewise capable
> of booting from the same media
>  * how can the Card Manufacturer even know that there's going to *be*
> an SD Card slot?
> 
> 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. The "lowest common denominator" here is the USB bus and SD/MMC bus on the EOMA68 connector which *IS REQUIRED* as per the spec and *could* contain bootable media. This means, if a housing chooses to implement the SD card, it *might* be bootable media. 

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

The A20 card has a micro sd slot. Is booting from this allowed in the spec? What if the next CPU card does not have an SD slot (it's not required by the spec)? Now average consumer is forced to install a different OS to internal NAND if they want a *useful* device. 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*.

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.

>>>  anyone who is plugging in (for example) an EOMA68-A20 into a (for
>>> example) router Housing is probably the kind of expert who knows what
>>> they're doing.  if they're even *remotely* contemplating that kind of
>>> re-purposing / mixing-and-matching (and are the first or one of the
>>> first to consider doing it) i think it's safe to assume that they
>>> would be capable of customising (or entirely replacing) the OS with
>>> one that is more suited to the job of "being a router" as opposed to
>>> "being a desktop OS".
>>
>> If an average consumer buys a housing that claims it is a router and plugs in their old A20 cpu card (that contains a pre-installed desktop style OS) the hardware may be configured correctly per the dtb, but they surely won't be happy when they find out they need to setup a firewall, dhcp server, etc, etc, and much much more.
> 
>  the fact that they took a CPU Card with a *desktop* OS is the clue
> here.  if they did that, they should expect to have "a set of desktop
> functions".  i did answer this above.   they have two choices:
> 
>  (a) go get a router OS for that CPU Card (this is not unreasonable
> under the circumstances)
>  (b) go install the software required (this is not unreasonable under
> the circumstances)
> 
> 
>> The definition of "plug it in and it works" here is sketchy at best.
> 
> yes.  accepted.   i answered (and you didn't acknowledge) that i would
> consider it reasonable that someone who mixes and matches in this way
> would likely be a "re-purposing" individual, sufficiently technically
> aware to fall into either category (a) or category (b).
> 
>  if they do *not* consider it "reasonable" then i would say... mmm....
> tough.  we can't do everything.
> 
> 
>> IMO, "works" means, works as a router like the housing packaging said it would, and I expect most consumers would think the same. Now, average consumer tosses cpu card and housing in the trash and never buys EOMA again because it didn't *just work*.
> 
>  if they did that, it's their choice.  we can't stop everybody from
> being irresponsible: we can't stop everybody from making decisions
> without first getting on the internet and checking "why doesn't this
> work, does anyone have any advice".
> 
>  however in these circumstances, these are "not normal".  someone buys
> a desktop OS and a desktop Housing, they're Certified by the retailer
> to work.  if they then buy a 3rd party Router Housing and try plugging
> it in, guess what?  they're outside of mainstream aren't they?  i
> would expect such people not to be complete idiots.  they
> experimented.  i would expect them to be capable of being curious
> about the results.  or, to just put the CPU Card back into the Desktop
> Housing.
>
>
>  now, if they bought both devices *second hand*, i would *also* expect
> such people to have done a little bit of research in advance, and to
> have some common sense.
> 
>  therefore, the actual number of people who are complete idiots,
> throwing away perfectly good hardware with very little actual thought
> and analysis, i would actually expect to be qute small.
> 
>  however if there was a fuckwit *RETAILER* who sold a router housing
> and a desktop OS computer card and told the customer "yeah yeah it'll
> work fine", NOW i have a problem with that, and i will be going after
> the seller aggressively because then the RETAILER is genuinely
> bringing EOMA68 into disrepute.  actually, the seller (being a total
> idiot) would have to accept the items back under warranty (due to the
> seller's own ignorance).
> 
> 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.

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.

> 
> 
>> Consumers should expect some kind of setup for any new hardware, especially a networking appliance, but asking them to install and properly configure a router OS is preposterous.
> 
>  if the products were mis-sold... YES.
>
>  if the products were bought 2nd-hand... NO
> 
>  if the products were bought from different 3rd parties... NO.  you
> don't go complaining to Microsoft if the HP printer doesn't work, do
> you?
> 
> 
>> If you allow a provision for housings to boot, the router housing manufacturer can provide a suitable OS (eg openwrt) and average consumer can be happy.
> 
>  no, it can't.  that forces the OS to be pre-compiled for a totally
> unidentified CPU.  how can you KNOW what CPUs will be placed into
> EOMA68 Card form-factor in the future?  how can you pre-compile
> openwrt for a processor that hasn't even been invented yet?
> 
>  it's simply impossible.
> 

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.” Allowing the housing manufacturer the *option* to boot from media can assist in fulfilling this claim. 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.

Again, my issue here is the misleading/lofty claim of “just plug it in: it will work.” 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. 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". 

>>>> Can you just require all source code and shipped binaries be available before compliance is approved?
>>>
>>>  in light of the above, the question may need to be reworded /
>>> rethought.  just as the Bill of Ethics points out: entropy will
>>> require to be continuously overcome in order to achieve [continuous]
>>> compliance.  it's not a one-off "fire-and-forget" process.
>>>
>>
>> Here's a totally different question instead :) Let's say someone makes a non-compliant housing and wants to market it to tech minded folk who can handle installing their own bootloader/kernel. Will it be legal to market it as non-compliant and use the EOMA name?
> 
>  NO.  i cannot take the risk that someone gets killed or badly injured
> due to an electrical fire caused by non-compliance.  if during an
> investigation where someone is killed, i would end up being accused
> (and quite probably convicted) of manslaughter.
> 
>  the answer is therefore an unequivocable and non-negotiable NO.
>
>  that said: the use of the word "legal" is misleading.  you should be
> using the word "permitted".
> 
>  now, given that you now know this (and see below as well), if you
> were to blatantly *ignore* what i said (which is "NO") and went ahead
> anyway, *then* it would most definitely NOT be legal, and you would be
> liable for prosecution (both civil and criminal).
> 
> 
>> "This housing accepts EOMA cpu cards but is non-compliant with the official specifications" or some such warning?
> 
> NO.  the risk is too great that without a proper test in a safe
> environment that the 3rd party Housing would not cause irreversible
> damage to people's Cards.  even just doing the testing could result in
> a short-circuit and cause a fire (due to a design fault in the
> Housing).
>

> this isn't "just software", and it's not a "desktop PC" or a
> hermetically-sealed unit.
> 
> 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. In a previous thread, I've already had to ask what the power requirements for the cpu card and housings are which is not *clearly defined* in the spec (http://lists.phcomp.co.uk/pipermail/arm-netbook/2016-August/011880.html). The spec should define this information clearly, eg "Housings must be able to provide a maximum 5.2V @ 4A and a minimum of 4.9V @ 1A to the CPU Card. The CPU Card must protect itself against an over voltage/current event above 5V 2A." (random values chosen here) A specification is *specific* and until complete, it's a *draft* specification. You, as so called *GUARDIAN* of the EOMA standard are responsible for providing *all* the pertinent information for compliance. 

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. I was under the impression that the standard was mostly complete 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.

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

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. If you make it easier for manufacturers to provide a good user experience, then the customer is happy and will use it longer.

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.