Re: No HDMI signal from Nitrogen6x board with daisy

[Eric Nelson <eric.nelson@boundarydevices.com>]

Sorry Peter,

I didn't recall that the other post was from you, so some
of these questions are answered.

On 05/23/2014 05:18 PM, Eric Nelson wrote:
> Hello Peter,
>
> On 05/23/2014 05:16 AM, Otavio Salvador wrote:
>>
>> On Fri, May 23, 2014 at 4:23 AM, Peter Bergin <peter.bergin@tritech.se
>> <mailto:peter.bergin@tritech.se>> wrote:
>>
>>     I have trouble with my Nitrogen6x board after upgrade to daisy
>>     build. I can not get any HDMI signal out of the board after boot.
>>     During boot u-boot can show content on screen but when booted the
>>     monitor does not detect the signal.
>>
>>     I have updated to u-boot 2014.04. I have tried with the pre-built
>>     image found at Boundary Devices with same result as my own build.
>>
>
> This is not likely to be a U-Boot level thing.
>
>>     I see this printout on the console after boot:
>>     mxc_sdc_fb fb.27: timeout when waiting for flip irq
>>     mxc_sdc_fb fb.27: MXCFB_WAIT_FOR_VSYNC: timeout 0
>>     mxc_sdc_fb fb.27: timeout when waiting for flip irq
>>     mxc_sdc_fb fb.27: MXCFB_WAIT_FOR_VSYNC: timeout 0
>>     mxc_sdc_fb fb.27: timeout when waiting for flip irq
>>     mxc_sdc_fb fb.27: MXCFB_WAIT_FOR_VSYNC: timeout 0
>>
>>     I have also posted a, still unanswered, question on the Freescale
>>     community page (https://community.freescale.com/message/405002).
>>
>
> I saw that post, but have been struggling to find time to reproduce it.
> A nominal build of Daisy/fsl-image-machine-test just seemed to
> work for me at 1080P60.
>
> Are you also running 1080P (i.e. with a custom boot script)?
>
> Can you forward the content of /proc/cmdline?
>

Got it:

	enable_wait_mode=off video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 
video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=28M 
console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait 
root=/dev/mmcblk0p2

This looks reasonable.

>>     Any help is really appreciated! Any ideas?
>>
>> I think it might be your monitor do not support the frequency it is
>> using.
>>
> If your monitor supports EDID, you should be able to tell by
> looking in sysfs:
>
>      # cat /sys/class/graphics/fb0/mode
>      ... currently negotiated mode here
>
>      # cat /sys/class/graphics/fb0/modes
>      ... list of supported modes should be here
>

I see in your post that you decoded the EDID information
in U-Boot, and it certainly says that your monitor supports
1080P60:
	 1920x1080       60 Hz (detailed)

In the serial output, I also see 720P come up before
before a transition to 1080P.

imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x00800000
mxc_sdc_fb fb.25: 1280x720 h_sync,r,l: 40,110,220  v_sync,l,u: 5,5,20 
pixclock=74250000 Hz
...
mxc_sdc_fb fb.25: 1920x1080 h_sync,r,l: 44,528,148  v_sync,l,u: 5,4,36 
pixclock=148500000 Hz
imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00080000

I suspect that this is the source of the issue, because your monitor
doesn't appear to support 720P, but I'm not sure.

Hmmm. While testing your command-line, I'm seeing some weirdness too.
With your arguments, my display gets confgured as 1024x768.

If I add the "mxc_hdmi.only_cea=1" as is done in the boot script,
I get proper negotiation.

Can you try running this by hand?

U-Boot > setenv bootargs enable_wait_mode=off 
video=mxcfb0:dev=hdmi,1920x1080MR@60,if=RGB24 video=mxcfb1:off 
video=mxcfb2:off video=mxcfb3:off fbmem=28M console=ttymxc1,115200 
vmalloc=400M consoleblank=0 rootwait root=/dev/mmcblk0p2 mxc_hdmi.only_cea=1
U-Boot > mmc dev 0 && fatload mmc 0 10800000 uImage && bootm 10800000

I suspect we introduced a bug when pulling our "only_cea" patch
over to 3.10.17.

Please advise,


Eric