[Arm-netbook] EOMA server standard

[luke.leighton]

On 10/29/12, Gordan Bobic <gordan at bobich.net> wrote:

> Say you want to use an SoC that doesn't have built in graphics for a
> particular purpose.

 then it would not be considered: it would be eliminated as an EOMA-68
candidate, and that would be the end of the matter.

 as a SoC for other EOMA standards - ones that do not require graphics
at all - it would however be considered.

> So you just leave the graphics related pins not
> connected and instead you have a serial console (does one of the USB
> connection double up as a slave side serial console?).

 then that destroys the viability of the *entire* EOMA-68 standard,
because nobody would be sure whether, when they buy EOMA-68 CPU Cards,
if the graphics would work.  they would complain, and they would
return the product.

 in a mass-volume retail sector, *any* returns is an absolute "no".
therefore, it is necessary to be absolutely absolutely strict about
this: optional interfaces are OUT.

 it's quite simple, but there's such a lot to cover, in so many
different directions, i appreciate it's hard to remember them all.

> If you allow this sort of thing to work (i.e. graphics being optional),
> you have different classes of products that aren't going to be in the
> same price bracket purely by choice of SoC/components.

 it would be better to create a different EOMA standard, one that had
its own mind-share.  optionality is not an option.

> If you don't allow that to work you are automatically excluding some
> SoCs that might be usable to implement cheaper products with fewer
> features by enforcing a one-size-fits-nobody approach, which is at least
> as bad.

 i'm keenly aware of that, and it's why i'm struggling with the EOMA
server standard.  the mass-volume retail product standard (EOMA-68) on
the other hand i have absolutely no such doubts.  except kicking
myself for not making it clearer to people about the user-facing
interfaces of the first CPU Card (audio, sd/mmc, hdmi, usb-otg)

 if you look closely at about 50 retail-product-targetted SoCs, you'll
see that they have something in common:

* they *all* have 24-pin RGB/TTL.  i don't know of a single SoC at
700mhz or above that doesn't have 24-pin RGB/TTL.
* they all have USB2.  not a single one doesn't have USB2.
* they all have I2C.  not a single one doesn't have I2C
* *some* of them don't have Ethernet;
* *some* of them don't have SATA.
* every single one of them (including the CSM1800 from Celestial
Semiconductors which only has 16 GPIO pins) has at least 16 pins of
GPIO.

the interfaces picked for EOMA-68 truly are lowest-common-denominator.
 it's a bit dodgy on the ethernet and SATA, but there it's possible to
put USB converter ICs in.


>>   in the mass-volume retail sector it simply doesn't work the way you
>> think.
>>
>>   however, in the *high-end* sector, you would be absolutely right.
>> $0.50 would make absolutely no odds.  but in the high-end sector, the
>> chances are that you would use a better IC that didn't require that
>> $0.50 part in the first place (i.e. it would probably have a composite
>> video output.)
>>
>>   *but*.... because the EOMA-68 standard covers high *and* low end, the
>> standard has to be designed to cover both.
>>
>>   therefore, composite video is out, because if composite video was
>> "in", it would jeapordise the viability of the low-end sector.
>
> This only applies if you are fixated on the one-size-fits-nobody method
> of standardising. IMO this is the wrong approach to take because you
> lose more than you gain. Compatibility is far more important than
> complete feature equality.

 so is standing firm and not letting a standard slip if there is a
good reason not to let it slip.  and "causing confusion"

>>   it's really quite simple, but has to take in a hell of a lot of
>> factors into consideration.
>>
>>   the server area's one i still can't quite get my head round, though.
>>
>>> So instead you cripple the standard by excluding the possibility of
>>> using anything with PCIe?
>>
>>   no gordan, there's no excluding of anything.  please don't put words
>> into my mouth.  i'm asking for people to contribute and discuss in an
>> open fashion - not accuse people of "crippling" anything.
>
> I didn't mean to accuse you of anything - perhaps I worded it poorly,
> and if that is the case, then I sincerely apologize. However - the point
> I was making remains (and remains unclarified).

 no no it's ok.  i just don't see that it's unclear, as i've answered
several times, each point you've raised.  perhaps it's the fact that
there is so much to consider and take in so many factors that it's not
clear how all of them affect and interact with each other.  perhaps
it's that you don't accept the individual points raised - i don't
know.

 anyway to help clarify i've started putting many of these points as an
FAQ so that they're not lost.

> That point was that by
> extension of "no optional interfaces" approach you are effectively either:
>
> 1) Excluding SoCs that don't have all the required features (e.g. PCIe)

 yes.  ok - not quite.  PCIe is the exception, because it's a
high-speed general-purpose bus.

> or
>
> 2) Excluding the possibility of use of features that a lot of (but not
> all of) the SoCs have (for example, but not limited to, PCIe).

 ok.

 right.

 PCIe is a special case, because it's a specialist general-purpose
high speed bus, and as such it *cannot* be emulated by any other ICs.
ok, i did find a PCIe-to-USB converter IC from Oxford Semi, but it's
single-lane, and i dread to think how much it costs, even if you could
get hold of it.  that illustrates the problem, right there.

 for EOMA-68, the fact that USB and I2C are general-purpose buses,
with hundreds if not thousands of conversion ICs available for those
two buses, as well as there being thousands of peripherals, and the
fact that those peripherals and ICs are very low cost, *and* the fact
that STM32Fs and equivalents are also low-cost *and* also themselves
have USB and I2C interfaces which can be connected to EOMA-68 means
that the fact that EOMA-68 doesn't have all those peripherals like
IIS, RS232, AC97 audio and so on is *not* a problem.

 this is something of a jammy / extremely lucky situation :)

 *however*, for something like a server standard, where high-speed and
high-speed peripheral extensions are an issue, now we're running into
problems.  not least, it's hard to define a standard when the market
is not really mature for ARM Server ICs, there is so much variance,
and one SoC has some of the high-speed interfaces but lacks others
because to put them all on would overwhelm a single ARM chip and
require specialist heat-distributing packaging (viz: more expensive).

 bottom line: i really _want_ to get PCi-e onto an EOMA-server
standard, but am finding it hard to see how.

l.