On Wed, Aug 13, 2014 at 1:28 PM, Richard Zink zink@hexatux.org wrote:
On Wed, 13 Aug 2014 11:14:43 +0200 Miguel Garcia gacuest@gmail.com wrote:
Seems a good idea. The problem is when you have many devices based on EOMA-68 (such as routers, etc.). That's difficult with your idea. You would need several OS at once.
Why not just implement the system (OS side) a bit different:
- Put the base OS on the microSD onboard the EOMA68 module
- Put an additional storage (Flash/SD/eg.) onboard the carrier board (Laptop/Beamer/TV/Router/eg.)
With this way it would be possible to have all specific drivers shipped with the CPU module and have the desired user space programs (GUI/Shell/needed programs) shipped with the carrier. So it would be easier to swap the CPU card (on which you could store your user settings).
ok think it through. remember that the guiding rule is, for the end-user "it must just work" and that translates to (in the standard) "there must be ZERO options" (as in, you are not permitted to choose "i think i will implement only part of the standard", nor does the standard itself say "you may implement only one of the 2 USBs, you *MUST* have both, even if they are slower or faster").
so, what in effect you are saying is that *ll* carrier boards *must* have:
1) some additional storage. that would need to become part of the specification. it would then be necessary to specify the minimum requirements (size, transfer rate). the type doesn't actually matter because the EEPROM can specify where it is accessible from as a DeviceTree overlay.
2) userspace programs *per CPU*. so, there must be MIPS versions of the programs, ARM (32-bit) versions, ARM (32-bit) hard-float versions, ARM (64-bit) versions... when they come out, x86 versions of the programs (32-bit, 64-bit, 486 variants)....
basically (1) is not hugely desirable but could be done but (2) would be a complete nightmare of the first order.
there are two maybe 3 possible ways around it though:
2a) you ship interpreted applications *only*. java, python, perl, ruby, .NET and so on
2b) you actually ship the full source code and the CPU Card will have a complete compiler
2c) you have a web site that allows OS applications to be downloaded, stored on e.g. external media or whatever the end-user chooses.
i think, really, 2c is the most practical / realistic way. allow people to select and install complete OSes, provide a base mechanism to do that.
which would be kinda cool. "oh you plugged in to this type of base unit, let me just offer you the opportunity to download a complete OS you can use which is customised to fit it".
l.