On Sun, Sep 25, 2016 at 5:11 PM, Joseph Honold mozzwald@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.