From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id A076BE0073A; Fri, 23 May 2014 17:58:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=RCVD_IN_DNSWL_LOW,RDNS_NONE autolearn=no version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.220.42 listed in list.dnswl.org] * 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS Received: from mail-pa0-f42.google.com (unknown [209.85.220.42]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 31868E00716 for ; Fri, 23 May 2014 17:58:12 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rd3so4847592pab.1 for ; Fri, 23 May 2014 17:58:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DID37sOX369+vPeEkozBzqgvRjdZLsSxR1YCXPCI+cY=; b=kGApv9DdTNKS9AKmM8jRTS5V+95L7EE79m21nnR+1vCgtRMr7Xqe8mRvRhCK6yTzko OPymncvFBAe/iYRDt2I83erAXrXxWHBEhQPML2cXsLHbLXaqarkqErmAUOzhvjsXQn1E S8cpR7IODEDpiXl2yUX44Zd+zltvEemOw9TKbMDiwhAEppX1oz7262Y2vFGfRcz06bTk f7/m3DCM70XpkLFF8ZhJ0T68ovoNJbm6uANdFge10E59z/qu562V9O0oE76MDT24AdCc c8oTdZHfAW5o7VUbTKHX1G/m2c0Cbp6nHPY5Qsi1CoNc2CTC32ovQSRYzhlmiRF0aN/d +Xaw== X-Gm-Message-State: ALoCoQmABDEpGvxFZYIAYws9xbOu6ntVFb5SzXXJXNU4RTMfBrmzt0xibaHT+Lts/1poHs4vGIT0 X-Received: by 10.68.106.130 with SMTP id gu2mr10067255pbb.59.1400893091762; Fri, 23 May 2014 17:58:11 -0700 (PDT) Received: from [192.168.0.124] ([63.226.49.26]) by mx.google.com with ESMTPSA id rw4sm20997309pab.47.2014.05.23.17.58.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 17:58:10 -0700 (PDT) Message-ID: <537FEE9F.4040301@boundarydevices.com> Date: Fri, 23 May 2014 17:58:07 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Otavio Salvador , Peter Bergin References: <43F0718C449F6A46B393DA2BEC8E01280C4F2C34@post.tritech.se> <537FE543.10108@boundarydevices.com> In-Reply-To: <537FE543.10108@boundarydevices.com> Cc: "meta-freescale@yoctoproject.org" , Troy Subject: Re: No HDMI signal from Nitrogen6x board with daisy X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 00:58:17 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > > 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