Sabre Lite HDMI audio + video works once then requires a reboot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Sabre Lite HDMI audio + video works once then requires a reboot

Jump to solution
6,027 Views
egremillion
Contributor III

I've run into a problem on the Sabre Lite board I'm working on.  When I play audio and video to my HDMI monitor, it only works once.  From then on, I get the following error message until I reboot the board:

ERROR: HDMI is not ready!

asoc: can't open platform imx-hdmi-soc-audio.0

Here are some sample gst-launch pipelines I used to reproduce the problem (on my board my LCD is /dev/video18 and my HDMI is /dev/video20):

# This works fine - I can play it as many times as I'd like

gst-launch \

  udpsrc port=1234 ! tsdemux name=demux \

    demux. ! queue max-size-time=0 ! vpudec framerate-nu=30000 framerate-de=1001 ! videorate force-fps=30/1 ! mfw_v4lsink device=/dev/video18 \

    demux. ! queue max-size-time=0 ! ffdec_mp3 ! tee name=t1000 \

      t1000. ! queue max-size-time=0 ! alsasink device=plughw:0,0 \

      t1000. ! queue max-size-time=0 ! alsasink device=plughw:1,0

# This works the first time I play it; subsequent attempts fail with

# "ERROR: HDMI is not ready!

#  asoc: can't open platform imx-hdmi-soc-audio.0"

# And I can't play HDMI audio until I reboot the board

gst-launch \

  udpsrc port=1234 ! tsdemux name=demux \

    demux. ! queue max-size-time=0 ! vpudec framerate-nu=30000 framerate-de=1001 ! videorate force-fps=30/1 ! tee name=mrtee \

      mrtee. ! queue max-size-time=0 ! mfw_v4lsink device=/dev/video18 \

      mrtee. ! queue max-size-time=0 ! mfw_v4lsink device=/dev/video20 \

    demux. ! queue max-size-time=0 ! ffdec_mp3 ! tee name=t1000 \

      t1000. ! queue max-size-time=0 ! alsasink device=plughw:0,0 \

      t1000. ! queue max-size-time=0 ! alsasink device=plughw:1,0

This seems very similar to a problem someone else had that appeared to be resolved with a driver patch.  I'm pretty sure I have all the latest patches, but maybe there's something I'm missing and/or maybe I need something new?  Just for fun, I've also tested this on a Nitrogen board and I do NOT have the problem there...

Any and all help is appreciated!

Ernie

Labels (2)
1 Solution
2,453 Views
EricNelson
Senior Contributor II

Hi Ernie,

The way I tested things was with this somewhat old Yocto Dora image:

     http://boundarydevices.com/yocto-dora

I tested with both aplay and gst-launch, though I didn't use UDP (just local MP4/WAV files).

We both should have grepped the kernel sources before now!

Doing so shows that the error message is here:

     linux-imx6/sound/soc/imx/imx-hdmi-dma.c at boundary-imx_3.0.35_4.1.0 · boundarydevices/linux-im...

Which indicates a failure from routine "mxc_hdmi_register_audio".

You can see the implementation of that here:

     linux-imx6/drivers/mfd/mxc-hdmi-core.c at boundary-imx_3.0.35_4.1.0 · boundarydevices/linux-imx...

And looking at it, it seems that the problem stems from "check_hdmi_state", and most likely

because the display is blanked!

Can you un-blank your display and re-try when the board is in this state? I'm not sure whether

fb0 or fb1 (the video overlay) is being checked, but it won't hurt to unblank both:

     # echo 0 > /sys/class/graphics/fb0/blank

     # echo 0 > /sys/class/graphics/fb1/blank

View solution in original post

10 Replies
2,454 Views
EricNelson
Senior Contributor II

Hi Ernie,

What kernel and userspace are you running?

Can you also provide the U-Boot output (I'm curious about the silicon revision).

0 Kudos
2,454 Views
egremillion
Contributor III

Hi Eric,

Any chance to look at the info I added and see if you can figure out what's going wrong?  I'd really appreciate any help you can give!

Ernie

0 Kudos
2,454 Views
EricNelson
Senior Contributor II

Hi Ernie,

Some other questions for you:

Once the system gets into this state, can you otherwise access the HDMI audio device (i.e. with aplay or gst-launch)?

Can you see if there's a lingering close of some sort?

     # fuser /dev/snd/pcmC1D0p

0 Kudos
2,454 Views
egremillion
Contributor III

Hi Eric,

Once the system gets into this state I can't access the HDMI audio device in any way, and there don't appear to be any lingering closes or open locks.  I'll paste in the contents of a shell session I just ran for you to review.  I was actually able to simplify the problem even further - basically, if I play any video to the HDMI monitor then it is subsequently locked from audio.  Very strange...

Re: your other questions about the image - this came from the people I'm doing the work for, so I don't have all the details on where they pulled everything from or why the U-Boot variant is "dirty".  I can probably get access to the Bit Bake recipes if you need any specific info.  An alternative might be to try a clean version on a Sabre Lite and see if the same problem exists there, since it's pretty easy to reproduce.  Do you have a Sabre Lite with an HDMI monitor that you could try this on?  If not, can you recommend a specific image for me to try on mine?  If I can isolate this to a problem with the image (kernel and user space) that would help a great deal...

Thanks so much!

Ernie

root@bcr:~# # Play audio to HDMI audio device via aplay

root@bcr:~# aplay -D plughw:1,0 beepbeep.wav

Playing WAVE 'beepbeep.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono

root@bcr:~#

root@bcr:~# # Play audio to HDMI audio device via gst-launch

root@bcr:~# gst-launch audiotestsrc ! alsasink device=plughw:1,0

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

New clock: GstAudioSinkClock

^CCaught interrupt -- handling interrupt.

Interrupt: Stopping pipeline ...

Execution ended after 2503908412 ns.

Setting pipeline to PAUSED ...

Setting pipeline to READY ...

Setting pipeline to NULL ...

Freeing pipeline ...

root@bcr:~#

root@bcr:~# # Play video to HDMI via mfw_v4lsink

root@bcr:~# gst-launch videotestsrc ! mfw_v4lsink device=/dev/video20

MFW_GST_V4LSINK_PLUGIN 3.0.9 build on Apr 18 2014 11:50:43.

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

set v4l rotate sucessfully

>>V4L_SINK: Actually buffer status:

        hardware buffer : 12

        software buffer : 0

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

full screen size:800x480

[V4L Update Display]: left=0, top=0, width=800, height=480

set v4l display crop sucessfully

New clock: GstSystemClock

ipu_init_sync_panel: disp=1, pixel_clk=74250000 74250000

pwm_config: pwm freq = 32786, clk_select=2 clock_rate=22000000

pwm_config: pwm freq = 20000, clk_select=2 clock_rate=22000000

^CCaught interrupt -- handling interrupt.

Interrupt: Stopping pipeline ...

Execution ended after 3254910525 ns.

Setting pipeline to PAUSED ...

Running time 0:00:03.255489562 render fps 29.796

Setting pipeline to READY ...

Setting pipeline to NULL ...

Total rendered:97

pwm_config: pwm freq = 32786, clk_select=2 clock_rate=22000000

pwm_config: pwm freq = 20000, clk_select=2 clock_rate=22000000

Freeing pipeline ...

[--->FINALIZE v4l_sink

root@bcr:~#

root@bcr:~# # Try audio to HDMI audio device via gst-launch

root@bcr:~# gst-launch audiotestsrc ! alsasink device=plughw:1,0

Setting pipeline to PAUSED ...

ERROR: HDMI is not ready!

asoc: can't open platform imx-hdmi-soc-audio.0

ERROR: Pipeline doesn't want to pause.

ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: Could not open audio device for playback.

Additional debug info:

/home/weimerc/release/bcr/BriefcaseRx/release/A04-BCR-01A1.0/branch/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/gst-plugins-base/0.10.36-r8/gst-plugins-base-0.10.36/ext/alsa/gstalsasink.c(694): gst_alsasink_open (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0:

Playback open error on device 'plughw:1,0': Invalid argument

Setting pipeline to NULL ...

Freeing pipeline ...

root@bcr:~#

root@bcr:~# # Try audio to HDMI audio device via aplay

root@bcr:~# aplay -D plughw:1,0 beepbeep.wav

ERROR: HDMI is not ready!

asoc: can't open platform imx-hdmi-soc-audio.0

aplay: main:722: audio open error: Invalid argument

root@bcr:~#

root@bcr:~# # Check for a lingering close

root@bcr:~# fuser /dev/snd/pcmC1D0p

root@bcr:~#

root@bcr:~# # Check status via file system

root@bcr:~# cat /proc/asound/

card0/        cards          hwdep          pcm            timers

card1/        devices        imxhdmisoc/    sgtl5000audio/ version

root@bcr:~# cat /proc/asound/card1/

id    pcm0p/

root@bcr:~# cat /proc/asound/card1/pcm0p/

info  sub0/

root@bcr:~# cat /proc/asound/card1/pcm0p/info

card: 1

device: 0

subdevice: 0

stream: PLAYBACK

id: IMX HDMI TX mxc-hdmi-soc-0

name:

subname: subdevice #0

class: 0

subclass: 0

subdevices_count: 1

subdevices_avail: 1

root@bcr:~# cat /proc/asound/imxhdmisoc/

id    pcm0p/

root@bcr:~# cat /proc/asound/imxhdmisoc/pcm0p/

info  sub0/

root@bcr:~# cat /proc/asound/imxhdmisoc/pcm0p/info

card: 1

device: 0

subdevice: 0

stream: PLAYBACK

id: IMX HDMI TX mxc-hdmi-soc-0

name:

subname: subdevice #0

class: 0

subclass: 0

subdevices_count: 1

subdevices_avail: 1

root@bcr:~# cat /proc/asound/imxhdmisoc/pcm0p/sub0/

hw_params  info      status    sw_params

root@bcr:~# cat /proc/asound/imxhdmisoc/pcm0p/sub0/hw_params

closed

root@bcr:~# cat /proc/asound/imxhdmisoc/pcm0p/sub0/info

card: 1

device: 0

subdevice: 0

stream: PLAYBACK

id: IMX HDMI TX mxc-hdmi-soc-0

name:

subname: subdevice #0

class: 0

subclass: 0

subdevices_count: 1

subdevices_avail: 1

root@bcr:~# cat /proc/asound/imxhdmisoc/pcm0p/sub0/status

closed

root@bcr:~# cat /proc/asound/imxhdmisoc/pcm0p/sub0/sw_params

closed

root@bcr:~#

0 Kudos
2,454 Views
EricNelson
Senior Contributor II

Hi Ernie,

The way I tested things was with this somewhat old Yocto Dora image:

     http://boundarydevices.com/yocto-dora

I tested with both aplay and gst-launch, though I didn't use UDP (just local MP4/WAV files).

We both should have grepped the kernel sources before now!

Doing so shows that the error message is here:

     linux-imx6/sound/soc/imx/imx-hdmi-dma.c at boundary-imx_3.0.35_4.1.0 · boundarydevices/linux-im...

Which indicates a failure from routine "mxc_hdmi_register_audio".

You can see the implementation of that here:

     linux-imx6/drivers/mfd/mxc-hdmi-core.c at boundary-imx_3.0.35_4.1.0 · boundarydevices/linux-imx...

And looking at it, it seems that the problem stems from "check_hdmi_state", and most likely

because the display is blanked!

Can you un-blank your display and re-try when the board is in this state? I'm not sure whether

fb0 or fb1 (the video overlay) is being checked, but it won't hurt to unblank both:

     # echo 0 > /sys/class/graphics/fb0/blank

     # echo 0 > /sys/class/graphics/fb1/blank

2,454 Views
egremillion
Contributor III

Hi Eric,

This is definitely a good workaround!  I still think there's a bug in the kernel somewhere, because I have to unblank the framebuffer after every time I play video.  But, I can do that, so I'm OK.

For your reference, here's an approximation of the session I just did to test:

# ## Play audio to HDMI audio - works

# gst-launch audiotestsrc ! alsasink device=plughw:1,0

#

# ## Play video to HDMI video - works

# gst-launch videotestsrc ! mfw_v4lsink device=/dev/video20

#

# ## Play audio to HDMI audio - fails

# gst-launch audiotestsrc ! alsasink device=plughw:1,0

ERROR: HDMI is not ready!

asoc: can't open platform imx-hdmi-soc-audio.0

#

# ## Unblank fb4 (my HDMI fb)

# echo 0 > /sys/class/graphics/fb4/blank

#

# ## Play audio to HDMI audio - works

# gst-launch audiotestsrc ! alsasink device=plughw:1,0

#

# ## Play video to HDMI video - works

# gst-launch videotestsrc ! mfw_v4lsink device=/dev/video20

#

# ## Play audio to HDMI audio - fails again =(

# gst-launch audiotestsrc ! alsasink device=plughw:1,0

ERROR: HDMI is not ready!

asoc: can't open platform imx-hdmi-soc-audio.0

#

# ## Unblank fb4 (my HDMI fb)

# echo 0 > /sys/class/graphics/fb4/blank

#

# ## Play audio to HDMI audio - works

# gst-launch audiotestsrc ! alsasink device=plughw:1,0

0 Kudos
2,454 Views
EricNelson
Senior Contributor II

Hi Ernie,

I'm glad to hear that things are working with this, but can't really pursue any further without

references to your kernel sources.

I can tell you that I tested with the Yocto Dora build and didn't see this issue.

I tested with only a single (HDMI) display though. Are you in a position to test that configuration

to see if this has to do with multiple displays?

0 Kudos
2,453 Views
egremillion
Contributor III

Hi Eric,

Multiple displays was a great suggestion - I just did a test and found some very interesting results.  I did this all on my Nitrogen board which is running a more standard version of U-Boot (2013.10-00049-ge2ee7f4 (Nov 11 2013 - 18:06:33)) and the Yocto Dora kernel (Linux version 3.0.35-4.1.0+yocto+g5809938).

Basically I was able to reproduce the problem by modifying my boot script.  I adapted the boot script from the Sabre Lite I was working on so that my Nitrogen would think it had three displays:

setenv bootargs $bootargs video=mxcfb0:dev=lcd,800x480@60,if=RGB24

setenv bootargs $bootargs video=mxcfb1:dev=ldb,1280x768@60,if=RGB24

setenv bootargs $bootargs video=mxcfb2:dev=hdmi,1280x720M@60,if=RGB24

setenv bootargs $bootargs fbmem=10M,28M,28M

setenv nextcon 3;

while test "4" -ne $nextcon ; do

setenv bootargs $bootargs video=mxcfb${nextcon}:off ;

setexpr nextcon $nextcon + 1 ;

done

This configuration exhibited the same problem that the Sabre Lite board exhibited.

Then, I slightly modified that boot script so that the first two monitors were "off":

setenv bootargs enable_wait_mode=off

setenv bootargs "$bootargs console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait"

setenv bootargs $bootargs video=mxcfb0:off

setenv bootargs $bootargs video=mxcfb1:off

setenv bootargs $bootargs video=mxcfb2:dev=hdmi,1280x720M@60,if=RGB24

setenv bootargs $bootargs fbmem=10M,28M,28M

setenv nextcon 3;

while test "4" -ne $nextcon ; do

setenv bootargs $bootargs video=mxcfb${nextcon}:off ;

setexpr nextcon $nextcon + 1 ;

done

This configuration didn't exhibit the problem - everything worked fine.

So I think you (or anyone else) should be able to pretty easily reproduce this on a normal system.  I don't think you'll even need more than one real monitor - you'll just have to trick your system into thinking it has them.

I'm going to attach three files - the boot script that exhibited the problem, the one that didn't, and a text dump from the console when I rebooted my Nitrogen board.  Let me know what you think.

Also, just to be clear, at this point I'm not expecting anything quick from you.  Since I have an acceptable workaround for this problem, I expect you'd prioritize it lower than other issues without reasonable workarounds.  I appreciate anything you can do for me, though!

Ernie

0 Kudos
2,454 Views
EricNelson
Senior Contributor II

Hi Ernie,

I can see from the above that you're running a variant of our U-Boot, though I can't tell why it's -dirty:

     U-Boot 2013.10-05892-g6bbe268-dirty (Mar 26 2014 - 10:16:29)

It also looks like you hacked the boot script, but the Kernel command-line looks very reasonable.

The kernel's a mystery though. It's apparently a 3.0.35 variant, but there aren't any git references:

     Linux version 3.0.35-imt+yocto (dev@bkuehner-ubuntudesk64)

Can you describe how this arrived on your SD card?

0 Kudos
2,454 Views
egremillion
Contributor III

Hi Eric,

Thanks for the quick follow-up. Here's the transcript from a boot of the board - I think this will include all the info you need, but let me know if not...

Ernie

U-Boot 2013.10-05892-g6bbe268-dirty (Mar 26 2014 - 10:16:29)

CPU: Freescale i.MX6Q rev1.2 at 792 MHz

CPU: Temperature 38 C, calibration data: 0x56a4b87d

Reset cause: WDOG

Board: SABRE Lite

DRAM: 1 GiB

MMC: FSL_SDHC: 0, FSL_SDHC: 1

SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB

auto-detected panel mitsubishi-rgb

Enabling RGB display.

Display: mitsubishi-rgb (800x480)

In: serial

Out: serial

Err: serial

Net: using phy at 6

FEC

Hit any key to stop autoboot: 0

MMC: no card present

mmc0(part 0) is current device

FS=ext4 DTYPE=mmc DISK=0 BOOTPART=3

MMC: no card present

    • Bad device mmc 0 **

FS=ext2 DTYPE=mmc DISK=0 BOOTPART=3

MMC: no card present

    • Bad device mmc 0 **

FS=fat DTYPE=mmc DISK=0 BOOTPART=3

MMC: no card present

    • Bad device mmc 0 **

FS=ext4 DTYPE=mmc DISK=0 BOOTPART=1

MMC: no card present

    • Bad device mmc 0 **

FS=ext2 DTYPE=mmc DISK=0 BOOTPART=1

MMC: no card present

    • Bad device mmc 0 **

FS=fat DTYPE=mmc DISK=0 BOOTPART=1

MMC: no card present

    • Bad device mmc 0 **

mmc1 is current device

FS=ext4 DTYPE=mmc DISK=1 BOOTPART=3

    • Invalid partition 3 **

FS=ext2 DTYPE=mmc DISK=1 BOOTPART=3

    • Invalid partition 3 **

FS=fat DTYPE=mmc DISK=1 BOOTPART=3

    • Invalid partition 3 **

FS=ext4 DTYPE=mmc DISK=1 BOOTPART=1

1491 bytes read in 138 ms (9.8 KiB/s)

    1. Executing script at 10008000

mmc1 is current device

    • File not found /boot/imx6q-sabrelite.dtb **

only CEA modes allowed on HDMI port

3947380 bytes read in 306 ms (12.3 MiB/s)

    1. Booting kernel from Legacy Image at 10800000 ...

Image Name: Linux-3.0.35-imt+yocto

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 3947316 Bytes = 3.8 MiB

Load Address: 10008000

Entry Point: 10008000

Verifying Checksum ... OK

Loading Kernel Image ... OK

Starting kernel ...

Linux version 3.0.35-imt+yocto (dev@bkuehner-ubuntudesk64) (gcc version 4.8.1 (GCC) ) #1 SMP PREEMPT Fri Apr 4 04:00:23 EDT 2014

CPU: ARMv7 Processor revision 10 (ARMv7), cr=10c53c7d

CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache

Machine: Boundary Devices Nitrogen6X/SABRE Lite Board

Memory policy: ECC disabled, Data cache writealloc

CPU identified as i.MX6Q, silicon rev 1.2

PERCPU: Embedded 7 pages/cpu @8c008000 s5440 r8192 d15040 u32768

Built 1 zonelists in Zone order, mobility grouping on. Total pages: 227328

Kernel command line: enable_wait_mode=off console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait video=mxcfb0:dev=lcd,800x480@60,if=RGB24 video=mxcfb1:dev=ldb,1280x768@60,if=RGB24 video=mxcfb2:dev=hdmi,1280x720M@60,if=RGB24 fbmem=10M,28M,28M video=mxcfb3:off root=/dev/mmcblk0p1 mxc_hdmi.only_cea=1

PID hash table entries: 4096 (order: 2, 16384 bytes)

Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

Memory: 640MB 256MB = 896MB total

Memory: 900336k/900336k available, 148240k reserved, 0K highmem

Virtual kernel memory layout:

vector : 0xffff0000 - 0xffff1000 ( 4 kB)

fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)

DMA : 0xf4600000 - 0xffe00000 ( 184 MB)

vmalloc : 0xc0800000 - 0xf2000000 ( 792 MB)

lowmem : 0x80000000 - 0xc0000000 (1024 MB)

pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)

modules : 0x7f000000 - 0x7fe00000 ( 14 MB)

.init : 0x80008000 - 0x8003c000 ( 208 kB)

.text : 0x8003c000 - 0x807300e0 (7121 kB)

.data : 0x80732000 - 0x8078fba0 ( 375 kB)

.bss : 0x8078fbc4 - 0x807d63ac ( 282 kB)

SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1

Preemptible hierarchical RCU implementation.

NR_IRQS:624

MXC GPIO hardware

sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms

arm_max_freq=1GHz

MXC_Early serial console at MMIO 0x21e8000 (options '115200')

bootconsole enabled

Console: colour dummy device 80x30

Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available

CPU1: Booted secondary processor

CPU2: Booted secondary processor

CPU3: Booted secondary processor

Brought up 4 CPUs

SMP: Total of 4 processors activated (6324.22 BogoMIPS).

devtmpfs: initialized

print_constraints: dummy:

NET: Registered protocol family 16

print_constraints: vddpu: 725 <--> 1300 mV at 1150 mV fast normal

print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV fast normal

print_constraints: vddsoc: 725 <--> 1300 mV at 1200 mV fast normal

print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV fast normal

print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV fast normal

print_constraints: vdd3p0: 2625 <--> 3400 mV at 3000 mV fast normal

lcd_disable_pins

0 Kudos