Minnowboard MAX - Add HDMI CEC support

Portisch · January 27, 2017 at 9:29 AM

Hi all,

I own a Minnowboard MAX: MinnowBoard.org
This is a x64 development board with an Atom CPU.
This board does not have wired the CEC line from the HDMI connector.

The CEC line just ends: (Page 15): MinnowBoard.org

But the newer Minnowboard Turbot do have wired the HDMI_CEC (Page 8 & 15): MinnowBoard.org

As I am used to handle electronic I am able to wire on the Minnowboard MAX a connection from R29 (HDMI_CEC) to TP9 (Page 8).

Where is in the firmware the pin for CEC defined?
So I can compile the libreelec firmware with the new pin to be able to use HDMI CEC onboard.

If this is working I would supply a documentation what have to done to use HDMI CEC with the Minnowboard MAX board.

Thx!

**gdachs** · January 27, 2017 at 11:06 AM

Quote from Portisch

Where is in the firmware the pin for CEC defined?

It is not that easy as you might think. There is no CEC pin that can be accessed by the "firmware". CEC pins typically ends at a dedicated CEC chip that is in or near the CPU. There are many different kinds of CEC chips. For everyone you need a kernel driver. The userspace communicates with this kernel driver via an adapter in the LibCEC. Without any knowledge of the used CEC chip it is impossible to write a kernel driver.

The schematics you have linked, does only show that the CEC line goes to a level shifter, but the CEC output of this chip ends in the nowhere. So there is even no proof that CEC would work with this device.

Gerald
[hr]
Okay, I understand now that you want to root the CEC pin to a GPIO pin. AFAIK there is no kernel driver available that is able to do CEC communication directly with the CEC line. The only peace of software I know of, that is doing this, is a firmware for an atmega microcontroller. Maybe someone wants to try to port this to a kernel driver, but this will be extremely difficult. In contrast to the Atom CPU running distributions like LE, the atmega gets not disturbed by interrupts from other hardware. So it will be very difficult to keep the timing constraints of the CEC bus, if e.g. a userspace writes something to the disk, or the user types on the keyboard. To reserve just on core of the Atom for CEC communication seems not to be a good idea

That is a task I surely will not do, but if somebody else steps in here and is doing a kernel driver, and someone provides me a free sample of this hardware, I will do the adapter for the libcec.

Gerald

Portisch · February 9, 2017 at 9:33 AM

Yes, the CEC line ands in nowhere. But the new board is showing CEC line connected to the CPU.
This pin have to be handled like a gpio input.
So I will need a thread polling the gpio for high/low. There is a cec_gpio implementation around:
MK908-Kernel-NAND/drivers/video/rockchip/hdmi/softcec at master · tyeo098/MK908-Kernel-NAND · GitHub

But this have to be implemented in libCEC.
And libCEC is right now designed for "ready-to-use" CEC interface chips with vid & pid.

**gdachs** · February 9, 2017 at 9:55 AM

Quote from Portisch

Yes, the CEC line ands in nowhere. But the new board is showing CEC line connected to the CPU.
This pin have to be handled like a gpio input.
So I will need a thread polling the gpio for high/low. There is a cec_gpio implementation around:
MK908-Kernel-NAND/drivers/video/rockchip/hdmi/softcec at master · tyeo098/MK908-Kernel-NAND · GitHub

But this have to be implemented in libCEC.
And libCEC is right now designed for "ready-to-use" CEC interface chips with vid & pid.

Okay, so someone has to write an adapter for libcec that is using this softcec. Should be not that complicated then.

I have to correct myself. This driver is not usable for libcec, as it doesn't export a device. I can't see any interaction with userspace. So this driver would need some work too.

Gerald