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
Solved! Go to Solution.
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
Hi Ernie,
What kernel and userspace are you running?
Can you also provide the U-Boot output (I'm curious about the silicon revision).
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
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
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:~#
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
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
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?
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
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?
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)
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)
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