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

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

sorry, i missed the most important flaw in this, which i've now
outlined in the (new) software-related part of the spec, and it's
this: if you replace the Card (even with one that has the same SoC but
with a different amount of RAM), there's absolutely no guarantee that
the resources or the instruction set is capable of running the media,
*even* if it were able to access it.

remember that it's perfectly acceptable to have an x86 Card, or a MIPS
Card, or a Card that expected MIPSEL, or a MIPS64, or a PowerPC, or
even a 72mhz ARM Cortex M0 if it is powerful enough to run an LCD
(even if it's monochrome: 1366x768 is actually only just over 128k so
in theory it's doable).

the only way that an arbitrary processor (including future ones!)
would even remotely be capable of "booting" from external arbitrary
media is if it was in something like machine-independent bytecode
(CLR, Java, FORTH, Python bytecode, etc.) or was actually in
source-code form (perl, python, or other interpreted language).

and many many other exceptions that are, when you get down to it, just
too f*****g horrible to contemplate.


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

 given that the games console development is a GPLv3+ (libre-licensed)
project, i'm attempting to create an appropriate section that covers
this scenario adequately.

 one thing that's becoming clear is that there's an order of
precedence here for what is acceptable, in a similar way to the legal
requirements for vehicle safety (both Aviation and Road vehicles).

 we simply cannot blithely claim that just because it's "free" and
"open" that we can do whatever the hell we like.  safety and
consideration for future interoperability *ABSOLUTELY* has to take
precedence.

 kinda weird.

l.