[Arm-netbook] EOMA Specification / Documentation Issues

[Luke Kenneth Casson Leighton]

On Sun, Sep 25, 2016 at 5:11 PM, Joseph Honold <mozzwald at gmail.com> wrote:

> On 09/23/2016 10:27 PM, Luke Kenneth Casson Leighton wrote:
>> 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.
>>
>
> Sorry, hopefully this is better.

looks great.  may not be "perfect" but the mailing list software
(mailman) clearly copes and handles the required conversion, which is what
really matters in the end.

>> 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.
>>
>
> I re-read the spec regarding SD/MMC and see it is not required by
> housings and could be GPIO instead. My mistake. USB though, is
> required for all cpu cards and therefore is *available* to all
> housings.

available yes: guaranteed to be present, no.

for example on the breakout board (the most extreme case),
they're *clearly* not present: nothing is (strictly speaking even the
I2C EEPROM is not present because the breakout board is
really just a component not an actual Housing, but you get my
point).

imagine for example that "blind / sighted" design.  is there even
any *need* for USB ports or any internal USB devices *at all*?
i can't think of a single reason why the USB ports should even
be connected.  not even the LCD need be connected on that.
all you need is to use some of the buttons as GPIO, to have
a capacitive panel (maybe!) via I2C... err.... that's it.

where is there even a *requirement* that the USB wires even
be *connected*?

should we FORCE the blind/sighted design to have a USB
port, when the casework may not even have space to fit one?
no, of course not, that's completely unacceptable!


another example: a tablet which uses up all the USB ports
for internal peripherals.  USB port 1 is connected to a camera
USB port 2 is connected to an Audio IC.

... where's the USB storage in that example?

... where's the external USB port to plug *in* USB storage?

should we FORCE the tablet, as part of the EOMA68
Specification, to REQUIRE a USB port or to REQUIRE
USB storage?  no, of course not, that's completely
unacceptable!


so this is why it must not be "expected" that the Housing
*always* have USB storage attached (to either of its two
USB ports).

as you cannot rely on USB being present, so in turn
you cannot have Cards that fail to boot if USB is not
present.



> u-boot can be configured to scan the USB bus for storage
> media, even if that bus is not connected in the housing. If storage
> device found, attempt to load uboot script from a defined location on
> that device. If uboot script found, load and run it, else, boot from
> cpu card.
>
> Simple if/then/else.

indeed.  perfectly acceptable... but not guaranteed to be the
case.   so, it has to be a "MAY", or a "is permitted" as
opposed to being a "MUST".


> Also, since you are checking the eeprom device id in u-boot, it could
> be possible to check the dtb for sd card nodes and optionally boot
> like above (if/then/else).

exactly.  optional... but still cannot be relied on as being "absolutely
guraranteed"


>>> 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.
>
> No, it's not part of the spec, just trying to make a point that it can
> be easier for the housing manufacturer to customize the experience if
> housing boot is available.

 indeed it can.... but they should not *expect* it to be there.
 in other words the spec has to be something like,

 "if the housing happens to have externally-discovered bootable
  media it is PERMITTED to use it, but the MAIN functionality
  MUST not rely on that".

> I'm not advocating for the cpu card to not boot if media is not
> available in the housing. It's a simple if/then/else statement; else
> being "boot whatever is on the cpu card".

 exactly.  that's perfectly acceptable.

> We should not assume the cpu card
> will have an sd card if it's not required.

 mmm.... too many "nots" for me to process that :)

>>> 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.
>
> Hmm, with that kind of thinking, I can see people just tossing the old
> card in the trash because it's so "cheap".

we can't totally control the way that people think or act, we can only
consider putting in place incentives.

> The seller should
> proactively attempt to buy back or accept for donation the old cards
> if customer isn't going to use the old one.

yes.   or, just encourage them to put them on ebay.  and/or reach
out to recycling companies and say, "hey guys if you get any of
THESE we'll take 'em!"

> "Cheap" also depends on who you are. I see EOMA being deployed in
> low/no income areas of the world where the user may have little to no
> experience with computers. I understand that someone would likely be
> available to assist in a situation like this (missionaries,
> non-profits and the like).

exactly.

> Housing boot could make it easier to deploy
> and still call it EOMA compliant.

sorry: whilst it would _be_ easier, it's simply not possible.  in the
scenario that you give, the low-cost may even have been achieved
by removing things like USB connectors and saving $4 by not
including internal USB storage in the Housing.

the Card really does have to be stand-alone capable of booting.

now, in the case of the EOMA68-!C1t prototype, this was
actually a good example.  the 176-pin QFT IC1t processor
only has (had) one available boot option: eMMC / MicroSD.
as in: the only other SD/MMC interface had to go to the
EOMA68 connector.

in this case, there were simply not enough pins to put
in an additional NAND IC, nor was there a 3rd SD/MMC.

so in this case, i simply made the user-facing MMC *THE*
boot media.  the Card booted SOLELY AND EXCLUSIVELY
from the (one remaining) SD/MMC interface.

now, this has the side-effect that it is *always* going to be
possible to replace the OS, simply by preparing a replacement
OS MicroSD Card.

so even in the case of SoCs that are as little as $2 around
which $12-$15 Cards can be built, it's *NOT* as bad as it
appears on the surface...

... thus mitigating against the need to make "housing boot"
a mandatory requirement whilst claiming EOMA68 compliance.

think through the implications, joseph.  if you say "this device
is EOMA68 compliant even though it will only boot from
Housings", you have to then think through the implications
of what might happen if people in the 1st world go "oo!  that's
amazing!  i'll buy 1 million of those, thank you!"

that then makes its way out into the world, fast becoming
the dominant "novelty toy"... which people in the 1st world
start to try to use in Housings which *have no USB storage*...

aaaaand you're f*****d.



>> 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".
>
> So, in this case, is he allowed to use the "EOMA" name anywhere
> regarding his product?

 strictly... no.

> I see his site calls it "ZEOMA" and states
> "ZEOMA is based on the EOMA-68 concept." Based on our discussion I am
> under the impression that this would not be allowed.

my understanding is: "based on" is about the closest you can get
away with, i believe, in the Trademark world, without being in
clear and blatant violation of the Trademark.

> He is not calling
> it "EOMA Compliant" but is creating the connection from his device to
> the EOMA standard which could be confused with compliance.

yeah.  i'll have to have a word with their team.

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

whoops how did this lot get lumped together as a single block
of text??

>>
>> errr... i think that's it.  let me know if (1) works for you.  i
>> think it should.
>
> (1) is okay with me if the cpu card sd slot is *required* by the spec,

 no it's not *required*... it just so happens that most manufacturers
who *don't* provide it will find that people get a bit arsey.

> otherwise there is no *guarantee* that the sd card slot exists on the
> cpu card.

 correct... but remember, FPGA-based EOMA68 Cards and Pass-through
Cards are permitted as part of the spec (yes, Pass-through Cards are a
special case).

and, people may actually wish to make special "promotion" or "secure"
Cards.  secure cards (such as those which could contain an RFID
key-entry IC) should *NOT* have an sd card slot as it would clearly be
a security risk.

these would therefore have to be dealt with on a case-by-case basis,
applying for examptions to the otherwise-general rules.


> Anyway, I'm not going to push the issue anymore as I think I've made
> my point and you've made yours. I hope you consider the option viable
> if it ever comes up again.

i'll make a start on the "Software / OS" section, i'm going to divide
it down into separate roles (Manufacturer, Retailer, Recycler,
Technical End-User, Non-Technical End-User).

it's actually hellishly complex which is why i haven't outlined it before.


> Still, all this won't help me get the SSD2828 working which spawned
> the debate since it currently requires mainline u-boot/kernel. Looks
> like I just need to find/write a linux driver for it :)

i know.  all a bit of a pain, but that's software, and it's why we
haven't gone to "FULL ON RETAIL PRODUCTION MODE".

btw remember that mainline u-boot / kernel *does* actually work...
with the Revision 2.2 EOMA68-A20 Cards it just only works for about 90
to 300 seconds and i haven't been able to track down why.

there's clearly a bug somewhere around 4.0rc5 to 4.0rc6 which, if
found, fixed, and patched, would make mainline perfectly acceptable
for ongoing usage (with the EOMA68-A20).

also please always always remember, jospeh: the EOMA68-A20 Card is
just the first in the series.  the next one (whatever it is) will most
likely work straight out-of-the-box with mainline as it could be based
around a processor that's modern and up-to-date... or current.

one based around the Freescale iMX6 for example would work straight
away (because the iMX6 has a 19 year lifecycle so has a strong
committment from Freescale to keep it up-to-date).

l.