[Arm-netbook] EOMA Specification / Documentation Issues

Joseph Honold mozzwald at gmail.com
Sun Sep 25 17:11:38 BST 2016


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.

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

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

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

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

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

>>> I'd like to bring up the point that lacking a micro-sd card
>>> slot may not have to do with cheapness, but physical
>>> limitations. What if there is no room for it because other
>>> connectors / doohickeys were considered more important for the
>>> specific card?
> then you can get a top-loading or side-loading set of PCMCIA
> casework made up, and (if top-loading) use one of the top-loading
> MicroSD card holders that you get for mobile phones.
> 
> very simple solution.  investigated this 4 years ago.

I agree with Louis on this. Depending on the cpu, other electronics in
the cpu card and other ports on the user facing end, there may not be
room for a sd card socket. The top loader is a good idea if you have
the space; I hadn't considered that. We should not assume the cpu card
will have an sd card if it's not required.

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

"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). Housing boot could make it easier to deploy
and still call it EOMA compliant.

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

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

(1) is okay with me if the cpu card sd slot is *required* by the spec,
otherwise there is no *guarantee* that the sd card slot exists on the
cpu card.

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.

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



More information about the arm-netbook mailing list