[Arm-netbook] EOMA-68 passthrough implementation
Derek LaHousse
dlahouss at mtu.edu
Tue Jul 10 23:49:27 BST 2012
On Tue, 2012-07-10 at 23:27 +0200, Henrik Nordström wrote:
> > The EEPROM is on the
> > motherboard, and whatever controls the passthrough would need to read
> > it. Or are you saying the passthrough card needs to scale the HDMI
> > signal to the proper output, according to the EEPROM?
>
> There is this "little" requirement on EOMA68 cards:
>
> http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Start-up_procedure
>
> The reason is to protect both the EOMA68 card and the I/O it connects to
> from incompatibilities in future upgrades of the EOMA68 standard, and
> for configuring the LCD output to the right format for the connected
> screen. LCD in itself do not have any DDC like control channel for
> discovering hte LCD panel capability and the needed information need to
> be passwd out of band (i.e. the I2C EEPROM information in EOMA68)
Ok... So the requirement is that the passthrough card doesn't send RGB
until after "someone" checks the I2C. Does the "all pins disabled"
apply to the discoverable busses?
> > My laptop sees external storage, an audio card, and an external monitor.
> > I enable the monitor, and my HDMI puts out a 1080p image. Because the
> > screen is only 768... What happens? Who scales the image?
>
> The HDMI receiver chip that converts HDMI to LCD TTL signalling.
It sounds like you're saying the passthrough has to handle it.
> > An additional question I hid in there is: According to spec, is it okay
> > for the EOMA68 card to extend beyond flush? This seems to be purely
> > aesthetic.
>
> Afaik yes, but undesired as it would fit badly with tablet like use
> cases.
Well, I would like the aesthetics to be flush for most cards. But on a
passthrough, there's significant plugs which are already unwieldy, and a
longer card isn't a big deal.
> I did raise this a little bit before quesioning if we should have
> Ethernet in EOMA68 1.0. Imho it's better if Ethernet is directly
> connected to the CPU card. But doing so requires the card to extend to
> provide an RJ45 jack. Use of strange adapter cable for connectors is
> highly undesired.
>
> Having Ethernet in an EOMA68 passthrough card is kind of pointless other
> than for testing purposes. That ethernet only goes to the Ethernet port
> on the I/O board/unit if anywhere.
>
> I would suggest revising EOMA68 to
>
> a) remove Ethernet and instead define physical parameters to allow class
> II height at the last 2(?) CM of the card, allowing for a wider choice
> of external connectors on the CPU card.
Disagree. I want to leave a desktop EOMA system in place, with
connections, and just change the card. Ethernet is necessary on the
EOMA header. As for tablet, I wouldn't expect ethernet at all.
> b) Add analog stereo audio output. It's a very common requirement and
> expect most I/O boards to want audio. Higher quality audio is possible
> via USB, but at significant overhead cost which impairs both software
> complexity and battery lifetime.
I don't know the overhead. On the topic of audio quality: I'd prefer to
buy a better sound device, matched to speakers, than to replace the
CPUCard with a lossy audio connection over EOMA.
Could you elaborate on the battery lifetime issue? As for complexity,
cannot hotplug and ALSA/Pulse/etc. find the audio hardware and configure
it?
More information about the arm-netbook
mailing list