[Arm-netbook] EOMA-PCMCIA standard and example boards

[Luke Kenneth Casson Leighton]

On Tue, Sep 20, 2011 at 11:41 AM, Bari Ari <bari at onelabs.com> wrote:
> On 09/18/2011 01:46 PM, Luke Kenneth Casson Leighton wrote:
>>
>> please note: once the factory i've been speaking to in china finish
>> their current project (which looks like it's been delayed, bless 'em)
>> they will start to do the Mini Engineering Board and associated PCMCIA
>> CPU Card, immediately.
>>
>> so when i say this needs input and feedback, it means "i need input
>> and feedback"!
> This sounds like an interesting project. Please let me know when you
> have public information on the ARM SOC.

 SoCs plural.  ok there are two "hats" here.  the first "hat" is:
EOMA/PCMCIA specification.  the second "hat" is:
talking-to-chinese-and-other-companies-to-get-them-to-design-CPU-cards-that-are-compliant-with-the-EOMA/PCMCIA
specification.

 with the SECOND "hat" on, i am talking to several SoC companies
plural, to put them in touch with chinese ODMs plural, to get them
(plural) to develop EOMA/PCMCIA-compliant CPU cards.  also i've been
talking to European PCB developers to see if _they_ would like to
develop EOMA/PCMCIA-compliant CPU cards, although that is a more
challenging proposition because they have to have some USP that makes
it worthwhile, financially.

> Is there a website where this
> company in China will be sharing the open schematics and pcb files.

 china, europe, etc. etc. no not yet, although one china design house
i spoke to did actually suggest this before i did! :)  the main reason
for that was that they were working off of TI's publicly-available
schematics and pcbs, already.

> How
> will open hardware developers be able collaborate with this company in
> China and to contribute open and publicly shared ideas for designs such
> as these?

 well, that's the nice thing: you don't *actually* need to
"collaborate" - you just have to design something that's conformant on
either side of the EOMA/PCMCIA specification, and "collaboration"
happens automatically.

 in other words, once a CPU card exists, anyone can design a chassis
for a lot less money than it would normally cost.  using the PCMCIA
form-factor means that it's possible to go right down even to the size
of a MID or even one of the old-style smartphones (about 14mm
thickness, minimum dimensions approx 105mm x 62mm - any smaller than
that and you're running into difficulties ).


>  Who ultimately decides what will be in designs like these?

 hardware designers will.  as long as they conform to the electronic
and mechanical requirements of the EOMA/PCMCIA specification, they're
entirely free to do whatever they please.  even put a 3G modem
on-board (if it will operate within the 5W power budget) on a CPU
card.


> What license will the hardware designs be under?

 that's up to the individual hardware designers.  for example, there
is nothing to stop the Ben Nanonote team from creating a PCB with a
jz4740 on it and 128mb of RAM, and releasing the designs as open
source.

 there is no "license" on the EOMA/PCMCIA specification.


>>
>>
>> or, if you can think of any other example usage, beyond a
>> "self-contained reprap controller with an on-board web server" (to
>> replace the existing situation which is that you have to have the
>> arduino boards connected directly to an entire PC), please do say so!
>
> I'm not certain that the repap community will care.

 yeh i spoke to a friend of mine about this: his take was that the
reprap community won't care, right up until the point where a complete
ready-to-go drop-in replacement is dropped into their laps.

> It been obvious to
> do this but some of the main developers are under the impression that it
> can't work or will be very difficult for the reprap to operate that way.
> I'm not sure why they are sticking to this philosophy. IMHO reprap needs
> a wider variety of materials, faster print speeds and higher resolutions
> than what they are currently choosing to find acceptable vs a combined
> UI and machine controller. Maybe once you build it they will see it
> wasn't impossible or even very difficult and why it makes sense.
>>
>> i'll get on with the task of cut/pasting more stuff out of
>> http://lkcl.net/linux/modular.computing.architecture.html
>>
>>
> Public docs for the ARM soc's will go a long way in convincing hardware
> developers that a project such as this is an 'open' hardware project vs
> another 'almost' open project such as openmoko.

 *sigh* tell me about it.

 well, that's a different fight.  putting "first hat" back on: at
least the EOMA/PCMCIA specification makes it possible to barter /
negotiate on both sides of the fence.

this specification is a double-edged sword: it speeds up the development cycle.

so, let's take it from a SoC vendor's perspective.  they are in
absolute hell right now, because their CPUs take 18 months to develop,
and then their customers need to be spoon-fed, requiring even not just
schematics but also *completely* finished software so they can just...
ship it.

now along comes the EOMA/PCMCIA specification, and as long as they
port the linux kernel correctly, a wide range of chassis will already
exist, along with a wide range of OSes, off they go!  job done!

*but*, then they find that actually, their CPU didn't last very long,
because somebody else came along a few months later and created a far
better CPU than them, and everyone started buying that instead.

*but*, then, what happens?  they come out with their *next* CPU, and
people find it's much much better than anything else available, and
_they_ get all the sales!

so it is swings and roundabouts, just a bit quicker, and less
development effort and cost in between cycles.

now, from a *free software* perspective and "open hardware"
perspective, the choices have been opened up on both sides of the
specification.  it's perfectly possible for even someone using KiCAD,
Eagle or gEDA to develop a motherboard that conforms to the
EOMA/PCMCIA specification, because all the interfaces are quite
reasonable speeds (exception: SATA, and even that is ok because it's a
down-negotiable speed bus as well as being balanced lines).

from the CPU side, for free software developers and open-hardware
teams, it's much trickier: getting DDR2 RAM bus lines correct is very
very hard if you don't have PCB-CAD software like ORCAD or Mentor
Graphics stuff, but it's doable, as we've seen.  *BUT*, here's the
nice thing: *until* one team succeeds on that, everyone can at least
use proprietary EOMA/PCMCIA-compliant CPU cards.

l.