HDMI output on Beaglebone black

Asked by 7 months ago
Hi According to the readme for Beaglebone Black in crochet-freebsd there is no support for HMDI output yet (as of Dec 2013). Does anyone know what is required to make this work? Best regards

Your Answer

Name:
Reply:

All Answers

Answer by 7 months ago
On Thu, Dec 26, 2013 at 1:08 PM, Lundberg, Johannes < IIRC, there is no hdmi driver for any of arm boards support that we have in src tree. Ganbold
Answer by 7 months ago
Hmm, but HDMI output works fine on Raspberry Pi..
Answer by 7 months ago
Quoted message by Ganbold Tsagaankhuu 7 months ago
On Thu, Dec 26, 2013 at 1:08 PM, Lundberg, Johannes < IIRC, there is no hdmi driver for any of arm boards support that we have in src tree. Ganbold
On Thu, 26 Dec 2013 15:01:17 +0900 My understanding is the HDMI on the RPi is handled by the GPU so from the point of view of FreeBSD it is just a framebuffer with no special configuration. Andrew
Answer by 7 months ago
On Thu, 26 Dec 2013 13:32:48 +0800 We currently support HDMI output on the RPi and Efika MX(based on Freescale i.MX515). But in both cases output devices initialized outside kernel. By firmware of co-processor in RPi and by U-Boot in Efika MX. i.MX515 IPU driver supported by NetBSD, and we can reuse it.
Answer by 7 months ago
You need to write driver for NXP TDA19988 HDMI (LCD to HDMI converter), driver for LCD controller and vt/syscons wrapper. Also properly pinmux LCD pins in .dts. I did some experiments few months back but didn't get far: http://people.freebsd.org/~gonzo/arm/patches/bbb-tda.diff
Answer by 7 months ago
Thanks Gonzo! I'll do some experimenting next week. Btw, do you know if the same / similar driver is required also for the PandaBoard ES?
Answer by 7 months ago
Quoted message by Oleksandr Tymoshenko 7 months ago
You need to write driver for NXP TDA19988 HDMI (LCD to HDMI converter), driver for LCD controller and vt/syscons wrapper. Also properly pinmux LCD pins in .dts. I did some experiments few months back but didn't get far: http://people.freebsd.org/~gonzo/arm/patches/bbb-tda.diff
No, AFAIR for pandaboard ES it's somewhat more complicated. Take a look at section 10 ("Display Subsystem") of OMAP 4460 Technical Reference Manual.
Answer by 7 months ago
Does newcons make this any simpler? Tim
Answer by 7 months ago
Quoted message by Oleksandr Tymoshenko 7 months ago
You need to write driver for NXP TDA19988 HDMI (LCD to HDMI converter), driver for LCD controller and vt/syscons wrapper. Also properly pinmux LCD pins in .dts. I did some experiments few months back but didn't get far: http://people.freebsd.org/~gonzo/arm/patches/bbb-tda.diff
Hardware part - no. vt/syscons - probably. At least I think so, I haven't caught up to the latest stuff yet but AFAIR whole point of newcons was to make console/framebuffer drivers more sane.
Answer by 7 months ago
Quoted message by Tim Kientzle 7 months ago
Does newcons make this any simpler? Tim
Chances are we'll need to create an Android graphics interface module. Most of the GPUs are programmed with binary blobs that we'll have no hope of getting. However, the interface to Android is fairly standard so we should be able to leverage off that. Glad to hear about the new console code being easier to work with. I may have to bring it up on my Atmel gear that has LCDs... Warner
Answer by 7 months ago
Quoted message by Warner Losh 7 months ago
Chances are we'll need to create an Android graphics interface module. Most of the GPUs are programmed with binary blobs that we'll have no hope of getting. However, the interface to Android is fairly standard so we should be able to leverage off that. Glad to hear about the new console code being easier to work with. I may have to bring it up on my Atmel gear that has LCDs... Warner
That's true for this SoC... For others we'll not likely be so likely... Warner
Answer by 7 months ago
I don’t think we need that just to get a working console. I just skimmed through the AM335x TRM: http://www.ti.com/lit/ug/spruh73j/spruh73j.pdf It looks like there’s enough information there to bring up a basic frame buffer through the LCD controller (Chapter 13). That should suffice. Tim
Answer by 7 months ago
Quoted message by Warner Losh 7 months ago
Chances are we'll need to create an Android graphics interface module. Most of the GPUs are programmed with binary blobs that we'll have no hope of getting. However, the interface to Android is fairly standard so we should be able to leverage off that. Glad to hear about the new console code being easier to work with. I may have to bring it up on my Atmel gear that has LCDs... Warner
I forgot about this. We already have LCD controller driver for AM335x: sys/arm/ti/am335x/am335x_lcd.* It was only tested on AM335x EVM with LCD though.
Answer by 4 months ago
I got a little bit further with this and thought I $B!G (Bd better post my WIP before somebody wastes his/her time fixing things that $B!G (Bs already fixed. Here is diff of my work dir: http://people.freebsd.org/~gonzo/arm/patches/tda19988.diff There are several problems fixed comparing to first patch: - Fixed HDMI controller I2C address - Register write should be one I2C transaction - Current TI I2C driver can $B!G (Bt read more bytes than FIFO length. I moved read/write handler to ithread, instead of notifying requesting thread with wakeup. Kernel with this patch can read and parse EDID. I failed to get video output working even with test pattern (part of code commented by "#if 0 $B!I (B). Part of this code is direct copy-paste from linux driver just to get something working before re-coding it properly.