* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite [not found] ` <CAK18fxFSsmHbwje=obkZgFO+rpCGamC337JT20khQ8CSBDdiNA@mail.gmail.com> @ 2013-02-28 17:33 ` Eric Nelson 2013-02-28 17:47 ` Andrei Gherzan 2013-02-28 17:51 ` Otavio Salvador 2013-02-28 18:16 ` Eric Nelson 1 sibling, 2 replies; 11+ messages in thread From: Eric Nelson @ 2013-02-28 17:33 UTC (permalink / raw) To: Andrei Gherzan; +Cc: meta-freescale@yoctoproject.org, Otavio Salvador On 02/28/2013 08:34 AM, Andrei Gherzan wrote:> On Thu, Feb 28, 2013 at 5:30 PM, Eric Nelson > <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>> wrote: > > Hi Otavio and Andrei, > On 02/28/2013 08:01 AM, Otavio Salvador wrote: > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan > <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote: > > While using imx6, I faced 2 issues after updating the > kernel to ver. / rel. > 1.1.0: > Hi Andrei, I think you wanted to send this to meta-freescale@yoctoproject.org and not meta-fsl-arm@googlegroups.com. Otavio, the Github project description still has a reference to the Google Group. Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite 2013-02-28 17:33 ` Issues with sync-boundary-changes.patch on imx6qsabrelite Eric Nelson @ 2013-02-28 17:47 ` Andrei Gherzan 2013-02-28 17:58 ` Eric Nelson 2013-02-28 17:51 ` Otavio Salvador 1 sibling, 1 reply; 11+ messages in thread From: Andrei Gherzan @ 2013-02-28 17:47 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale, Otavio Salvador [-- Attachment #1: Type: text/plain, Size: 875 bytes --] -- Andrei Gherzan m: +40.744.478.414 | f: +40.31.816.28.12 On Feb 28, 2013 7:33 PM, "Eric Nelson" <eric.nelson@boundarydevices.com> wrote: > > On 02/28/2013 08:34 AM, Andrei Gherzan wrote:> On Thu, Feb 28, 2013 at 5:30 PM, Eric Nelson > > <eric.nelson@boundarydevices.com > > > <mailto:eric.nelson@boundarydevices.com>> wrote: > > > > Hi Otavio and Andrei, > > On 02/28/2013 08:01 AM, Otavio Salvador wrote: > > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan > > <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote: > > > > While using imx6, I faced 2 issues after updating the > > kernel to ver. / rel. > > 1.1.0: > > > > Hi Andrei, > > I think you wanted to send this to > meta-freescale@yoctoproject.org > and not meta-fsl-arm@googlegroups.com. > Ok. I'm confused now. [-- Attachment #2: Type: text/html, Size: 1515 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite 2013-02-28 17:47 ` Andrei Gherzan @ 2013-02-28 17:58 ` Eric Nelson 2013-02-28 18:03 ` Andrei Gherzan 0 siblings, 1 reply; 11+ messages in thread From: Eric Nelson @ 2013-02-28 17:58 UTC (permalink / raw) To: Andrei Gherzan; +Cc: meta-freescale, Otavio Salvador On 02/28/2013 10:47 AM, Andrei Gherzan wrote: > -- > Andrei Gherzan > m: +40.744.478.414 | f: +40.31.816.28.12 > On Feb 28, 2013 7:33 PM, "Eric Nelson" <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>> wrote: > > > > On 02/28/2013 08:34 AM, Andrei Gherzan wrote:> On Thu, Feb 28, 2013 > at 5:30 PM, Eric Nelson > > > <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com> > > > > > <mailto:eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>>> wrote: > > > > > > Hi Otavio and Andrei, > > > On 02/28/2013 08:01 AM, Otavio Salvador wrote: > > > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan > > > <andrei@gherzan.ro <mailto:andrei@gherzan.ro> > <mailto:andrei@gherzan.ro <mailto:andrei@gherzan.ro>>> wrote: > > > > > > While using imx6, I faced 2 issues after updating the > > > kernel to ver. / rel. > > > 1.1.0: > > > > > > > Hi Andrei, > > > > I think you wanted to send this to > > meta-freescale@yoctoproject.org <mailto:meta-freescale@yoctoproject.org> > > and not meta-fsl-arm@googlegroups.com > <mailto:meta-fsl-arm@googlegroups.com>. > > > > Ok. I'm confused now. > Hi Andrei, There was apparently a Google group before the ML at Yocto Project was created. I'm testing now and seeing some weirdness related to 1080P beyond the vmalloc and fbmem thing. 720P seems to work fine. Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite 2013-02-28 17:58 ` Eric Nelson @ 2013-02-28 18:03 ` Andrei Gherzan 2013-02-28 19:39 ` Eric Nelson 0 siblings, 1 reply; 11+ messages in thread From: Andrei Gherzan @ 2013-02-28 18:03 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale, Otavio Salvador [-- Attachment #1: Type: text/plain, Size: 1763 bytes --] -- Andrei Gherzan m: +40.744.478.414 | f: +40.31.816.28.12 On Feb 28, 2013 7:58 PM, "Eric Nelson" <eric.nelson@boundarydevices.com> wrote: > > On 02/28/2013 10:47 AM, Andrei Gherzan wrote: >> >> -- >> Andrei Gherzan >> m: +40.744.478.414 | f: +40.31.816.28.12 >> On Feb 28, 2013 7:33 PM, "Eric Nelson" <eric.nelson@boundarydevices.com >> <mailto:eric.nelson@boundarydevices.com>> wrote: >> > >> > On 02/28/2013 08:34 AM, Andrei Gherzan wrote:> On Thu, Feb 28, 2013 >> at 5:30 PM, Eric Nelson >> > > <eric.nelson@boundarydevices.com >> <mailto:eric.nelson@boundarydevices.com> >> > >> > > <mailto:eric.nelson@boundarydevices.com >> >> <mailto:eric.nelson@boundarydevices.com>>> wrote: >> > > >> > > Hi Otavio and Andrei, >> > > On 02/28/2013 08:01 AM, Otavio Salvador wrote: >> > > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan >> > > <andrei@gherzan.ro <mailto:andrei@gherzan.ro> >> <mailto:andrei@gherzan.ro <mailto:andrei@gherzan.ro>>> wrote: >> > > >> > > While using imx6, I faced 2 issues after updating the >> > > kernel to ver. / rel. >> > > 1.1.0: >> > > >> > >> > Hi Andrei, >> > >> > I think you wanted to send this to >> > meta-freescale@yoctoproject.org <mailto: meta-freescale@yoctoproject.org> >> > and not meta-fsl-arm@googlegroups.com >> <mailto:meta-fsl-arm@googlegroups.com>. >> >> > >> >> Ok. I'm confused now. >> > Hi Andrei, > > There was apparently a Google group before the ML at Yocto Project was > created. > > I'm testing now and seeing some weirdness related to 1080P beyond the > vmalloc and fbmem thing. > > 720P seems to work fine. > Aaa. Forgot to mention this. I can confirm it. ag [-- Attachment #2: Type: text/html, Size: 3254 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite 2013-02-28 18:03 ` Andrei Gherzan @ 2013-02-28 19:39 ` Eric Nelson 0 siblings, 0 replies; 11+ messages in thread From: Eric Nelson @ 2013-02-28 19:39 UTC (permalink / raw) To: Andrei Gherzan; +Cc: meta-freescale, Otavio Salvador Hi Andre, On 02/28/2013 11:03 AM, Andrei Gherzan wrote: > -- > Andrei Gherzan > m: +40.744.478.414 | f: +40.31.816.28.12 > On Feb 28, 2013 7:58 PM, "Eric Nelson" <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>> wrote: > > > > On 02/28/2013 10:47 AM, Andrei Gherzan wrote: > >> > >> -- > >> Andrei Gherzan > >> m: +40.744.478.414 | f: +40.31.816.28.12 > >> On Feb 28, 2013 7:33 PM, "Eric Nelson" > <eric.nelson@boundarydevices.com <mailto:eric.nelson@boundarydevices.com> > >> <mailto:eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>>> wrote: > >> > > >> > On 02/28/2013 08:34 AM, Andrei Gherzan wrote:> On Thu, Feb 28, 2013 > >> at 5:30 PM, Eric Nelson > >> > > <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com> > >> <mailto:eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>> > >> > > >> > > <mailto:eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com> > >> > >> <mailto:eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>>>> wrote: > >> > > > >> > > Hi Otavio and Andrei, > >> > > On 02/28/2013 08:01 AM, Otavio Salvador wrote: > >> > > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan > >> > > <andrei@gherzan.ro <mailto:andrei@gherzan.ro> > <mailto:andrei@gherzan.ro <mailto:andrei@gherzan.ro>> > >> <mailto:andrei@gherzan.ro <mailto:andrei@gherzan.ro> > <mailto:andrei@gherzan.ro <mailto:andrei@gherzan.ro>>>> wrote: > >> > > > >> > > While using imx6, I faced 2 issues after updating the > >> > > kernel to ver. / rel. > >> > > 1.1.0: > >> > > > >> > > >> > Hi Andrei, > >> > > >> > I think you wanted to send this to > >> > meta-freescale@yoctoproject.org > <mailto:meta-freescale@yoctoproject.org> > <mailto:meta-freescale@yoctoproject.org > <mailto:meta-freescale@yoctoproject.org>> > >> > and not meta-fsl-arm@googlegroups.com > <mailto:meta-fsl-arm@googlegroups.com> > >> <mailto:meta-fsl-arm@googlegroups.com > <mailto:meta-fsl-arm@googlegroups.com>>. > >> > >> > > >> > >> Ok. I'm confused now. > >> > > Hi Andrei, > > > > There was apparently a Google group before the ML at Yocto Project was > > created. > > > > I'm testing now and seeing some weirdness related to 1080P beyond the > > vmalloc and fbmem thing. > > > > 720P seems to work fine. > > > > Aaa. Forgot to mention this. I can confirm it. > I've finally been able to reproduce the issue you reported (lockup during boot), and it's really odd. It appears to only occur if I leave off a couple of clauses from the kernel command-line: video=mxcfb1:off video=mxcfb2:off Without that, something in the kernel startup seems to create another frame-buffer on /dev/fb2: --------/sys/class/graphics/fb0 DISP3 BG - DI1 U:1280x720p-60 --------/sys/class/graphics/fb1 DISP3 FG --------/sys/class/graphics/fb2 name: DISP4 BG mode: D:1280x800p-60 FWIW, my other display problem stemmed from me running a kernel that had the Vivante driver built as a module instead of statically into the kernel. Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite 2013-02-28 17:33 ` Issues with sync-boundary-changes.patch on imx6qsabrelite Eric Nelson 2013-02-28 17:47 ` Andrei Gherzan @ 2013-02-28 17:51 ` Otavio Salvador 1 sibling, 0 replies; 11+ messages in thread From: Otavio Salvador @ 2013-02-28 17:51 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale@yoctoproject.org On Thu, Feb 28, 2013 at 2:33 PM, Eric Nelson <eric.nelson@boundarydevices.com> wrote: > On 02/28/2013 08:34 AM, Andrei Gherzan wrote:> On Thu, Feb 28, 2013 at 5:30 > PM, Eric Nelson >> <eric.nelson@boundarydevices.com > >> <mailto:eric.nelson@boundarydevices.com>> wrote: >> >> Hi Otavio and Andrei, >> On 02/28/2013 08:01 AM, Otavio Salvador wrote: >> On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan >> <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote: >> >> While using imx6, I faced 2 issues after updating the >> kernel to ver. / rel. >> 1.1.0: >> > > Hi Andrei, > > I think you wanted to send this to > meta-freescale@yoctoproject.org > and not meta-fsl-arm@googlegroups.com. Done. > Otavio, the Github project description still has a reference > to the Google Group. Done :) thx -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite [not found] ` <CAK18fxFSsmHbwje=obkZgFO+rpCGamC337JT20khQ8CSBDdiNA@mail.gmail.com> 2013-02-28 17:33 ` Issues with sync-boundary-changes.patch on imx6qsabrelite Eric Nelson @ 2013-02-28 18:16 ` Eric Nelson 2013-02-28 18:27 ` Andrei Gherzan 2013-02-28 18:37 ` Eric Nelson 1 sibling, 2 replies; 11+ messages in thread From: Eric Nelson @ 2013-02-28 18:16 UTC (permalink / raw) To: Andrei Gherzan; +Cc: meta-freescale@yoctoproject.org, Otavio Salvador On 02/28/2013 08:34 AM, Andrei Gherzan wrote: > > On Thu, Feb 28, 2013 at 5:30 PM, Eric Nelson > <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>> wrote: > > Hi Otavio and Andrei, > > On 02/28/2013 08:01 AM, Otavio Salvador wrote: > > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan > <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote: > > While using imx6, I faced 2 issues after updating the kernel > to ver. / rel. > 1.1.0: > > 1. If i boot the board with hdmi monitor connected the boot > process hangs > with: > > --- > MIPI DSI driver module loaded > mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver hdmi > mxc_hdmi mxc_hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 > fbcvt: 1920x1080@60: CVT Name - 2.073M9 > imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), > 5B(2~5), 5F(6,7) > Console: switching to colour frame buffer device 240x67 > mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver lcd > mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver ldb > _regulator_get: get() with no identifier > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 0(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 1(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 2(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 3(VIC 1): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 4(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 5(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 6(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 7(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 8(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 9(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 10(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 11(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 12(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 13(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 14(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 15(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 16(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 17(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 18(VIC 0): > mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added > mode 19(VIC 0): > fbcvt: 1920x1080@60: CVT Name - 2.073M9 > mxc_sdc_fb mxc_sdc_fb.3: register mxc display driver ldb > > This all looks valid, though things shouldn't hang here. > --- > > Additional infos: > > $ cat /sys/devices/platform/mxc_sdc___fb.0/graphics/fb0/modes > V:640x480p-60 > U:640x480p-60 > Was this from a boot without the HDMI monitor connected? The mxc_hdmi > driver should list all of the display resolutions supported by the > monitor as reported by EDID. > > > Nope. This is from a boot with HDMI monitor connected. > > Kernel command line: console=ttymxc1,115200 > console=ttymxc1,115200 > root=/dev/sda2 rootwait > video=mxcfb0:dev=hdmi,__1920x1080M@60,if=RGB24 > When trying to reproduce things, I noted a -- You have two 'console=ttymxc1,115200' clauses here -- You appear to be using SATA (/dev/sda2). For SD card boot, this should be /dev/mmcblk0p2 with a Yocto-standard image -- There's some extraneous stuff (__) in your video= clause I just booted with a slightly modified kernel command-line to try and match yours: Kernel command line: console=ttymxc1,115200 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 fbmem=48M vmalloc=400 root=/dev/mmcblk0p1 rootwait What I found is that things booted, and I got a login prompt on the serial console, but my display isn't functioning properly. > > You'll need to add a an 'fbmem=' clause to the kernel command line. > For 1080P, I think this should be ~48M and you may need a 'vmalloc' > clause: > root=/dev/sda2 rootwait console=ttymxc1,115200 > video=video=mxcfb0:dev=hdmi,__1920x1080M@60,if=RGB24 fbmem=48M > vmalloc=400 > > 2. The first client connected to X server won't show > anything on screen. But > absolutely anything -without seeing any issues /errors / > warnings. > Restarting application everything works OK. And until reboot > no related > issues. After a reboot, the same behavior. > > So I've been struggling to get these fixed and search for > the source of the > problem. I was pretty sure that was something related to > kernel so I tried > some bisects with no luck. After some digging a realized the > issue was > something inside the sync-boundary-changes.patch. Without > this patch 1) and > 2) are fixed. > > I will take a look as we know the source of the problem now. > But maybe > somebody who already knows this patch can work with me in > parallel. > > > Eric, is it a known issue? > > > I'll try to reproduce when I get into the office. > > > Thanks. > > > -- > *Andrei Gherzan* > m: +40.744.478.414 | f: +40.31.816.28.12 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite 2013-02-28 18:16 ` Eric Nelson @ 2013-02-28 18:27 ` Andrei Gherzan 2013-02-28 18:37 ` Eric Nelson 1 sibling, 0 replies; 11+ messages in thread From: Andrei Gherzan @ 2013-02-28 18:27 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale, Otavio Salvador [-- Attachment #1: Type: text/plain, Size: 7094 bytes --] -- Andrei Gherzan m: +40.744.478.414 | f: +40.31.816.28.12 On Feb 28, 2013 8:16 PM, "Eric Nelson" <eric.nelson@boundarydevices.com> wrote: > > On 02/28/2013 08:34 AM, Andrei Gherzan wrote: >> >> >> On Thu, Feb 28, 2013 at 5:30 PM, Eric Nelson >> <eric.nelson@boundarydevices.com >> <mailto:eric.nelson@boundarydevices.com>> wrote: >> >> Hi Otavio and Andrei, >> >> On 02/28/2013 08:01 AM, Otavio Salvador wrote: >> >> On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan >> <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote: >> >> While using imx6, I faced 2 issues after updating the kernel >> to ver. / rel. >> 1.1.0: >> >> 1. If i boot the board with hdmi monitor connected the boot >> process hangs >> with: >> >> --- >> MIPI DSI driver module loaded >> mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver hdmi >> mxc_hdmi mxc_hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 >> fbcvt: 1920x1080@60: CVT Name - 2.073M9 >> imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), >> 5B(2~5), 5F(6,7) >> Console: switching to colour frame buffer device 240x67 >> mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver lcd >> mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver ldb >> _regulator_get: get() with no identifier >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 0(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 1(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 2(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 3(VIC 1): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 4(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 5(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 6(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 7(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 8(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 9(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 10(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 11(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 12(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 13(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 14(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 15(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 16(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 17(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 18(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> >> mode 19(VIC 0): >> fbcvt: 1920x1080@60: CVT Name - 2.073M9 >> mxc_sdc_fb mxc_sdc_fb.3: register mxc display driver ldb > > > >> >> This all looks valid, though things shouldn't hang here. >> --- >> >> Additional infos: >> >> $ cat /sys/devices/platform/mxc_sdc___fb.0/graphics/fb0/modes >> >> V:640x480p-60 >> U:640x480p-60 >> Was this from a boot without the HDMI monitor connected? The mxc_hdmi >> driver should list all of the display resolutions supported by the >> monitor as reported by EDID. >> >> >> Nope. This is from a boot with HDMI monitor connected. >> >> Kernel command line: console=ttymxc1,115200 >> console=ttymxc1,115200 >> root=/dev/sda2 rootwait >> video=mxcfb0:dev=hdmi,__1920x1080M@60,if=RGB24 >> > > When trying to reproduce things, I noted a > > -- You have two 'console=ttymxc1,115200' clauses here Need to clean uboot env- I'm using uboot from NOR. Tested some stuff. That shouldn't be an issue. I don't even get to 'mount rootfs'. > > -- You appear to be using SATA (/dev/sda2). For SD card boot, > this should be /dev/mmcblk0p2 with a Yocto-standard image > I'm using a SSD device. So I don't see why this would be an issue. I reproduced my issue with mmc too. > -- There's some extraneous stuff (__) in your video= clause > Just a strange copy/paste. > I just booted with a slightly modified kernel command-line to try > and match yours: > Kernel command line: console=ttymxc1,115200 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 fbmem=48M vmalloc=400 root=/dev/mmcblk0p1 rootwait > > What I found is that things booted, and I got a login prompt on the > serial console, but my display isn't functioning properly. > >> >> You'll need to add a an 'fbmem=' clause to the kernel command line. >> For 1080P, I think this should be ~48M and you may need a 'vmalloc' >> clause: >> root=/dev/sda2 rootwait console=ttymxc1,115200 >> video=video=mxcfb0:dev=hdmi,__1920x1080M@60,if=RGB24 fbmem=48M >> >> vmalloc=400 >> >> 2. The first client connected to X server won't show >> anything on screen. But >> absolutely anything -without seeing any issues /errors / >> warnings. >> Restarting application everything works OK. And until reboot >> no related >> issues. After a reboot, the same behavior. >> >> So I've been struggling to get these fixed and search for >> the source of the >> problem. I was pretty sure that was something related to >> kernel so I tried >> some bisects with no luck. After some digging a realized the >> issue was >> something inside the sync-boundary-changes.patch. Without >> this patch 1) and >> 2) are fixed. >> >> I will take a look as we know the source of the problem now. >> But maybe >> somebody who already knows this patch can work with me in >> parallel. >> >> >> Eric, is it a known issue? >> >> >> I'll try to reproduce when I get into the office. >> >> >> Thanks. >> >> >> -- >> *Andrei Gherzan* >> m: +40.744.478.414 | f: +40.31.816.28.12 > > [-- Attachment #2: Type: text/html, Size: 9151 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite 2013-02-28 18:16 ` Eric Nelson 2013-02-28 18:27 ` Andrei Gherzan @ 2013-02-28 18:37 ` Eric Nelson [not found] ` <CAK18fxHH01WMaD8ZitqYV3z1GikGsz4JEdht4v0p9S8u0EGWcQ@mail.gmail.com> 1 sibling, 1 reply; 11+ messages in thread From: Eric Nelson @ 2013-02-28 18:37 UTC (permalink / raw) To: Andrei Gherzan; +Cc: meta-freescale@yoctoproject.org, Otavio Salvador On 02/28/2013 11:16 AM, Eric Nelson wrote: > On 02/28/2013 08:34 AM, Andrei Gherzan wrote: >> >> On Thu, Feb 28, 2013 at 5:30 PM, Eric Nelson >> <eric.nelson@boundarydevices.com >> <mailto:eric.nelson@boundarydevices.com>> wrote: >> >> Hi Otavio and Andrei, >> >> On 02/28/2013 08:01 AM, Otavio Salvador wrote: >> >> On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan >> <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote: >> >> While using imx6, I faced 2 issues after updating the kernel >> to ver. / rel. >> 1.1.0: >> >> 1. If i boot the board with hdmi monitor connected the boot >> process hangs >> with: >> >> --- >> MIPI DSI driver module loaded >> mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver hdmi >> mxc_hdmi mxc_hdmi: Detected HDMI controller >> 0x13:0xa:0xa0:0xc1 >> fbcvt: 1920x1080@60: CVT Name - 2.073M9 >> imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), >> 5B(2~5), 5F(6,7) >> Console: switching to colour frame buffer device 240x67 >> mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver lcd >> mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver ldb >> _regulator_get: get() with no identifier >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 0(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 1(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 2(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 3(VIC 1): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 4(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 5(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 6(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 7(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 8(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 9(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 10(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 11(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 12(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 13(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 14(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 15(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 16(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 17(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 18(VIC 0): >> mxc_hdmi mxc_hdmi: mxc_hdmi_edid_rebuild___modelist: Added >> mode 19(VIC 0): >> fbcvt: 1920x1080@60: CVT Name - 2.073M9 >> mxc_sdc_fb mxc_sdc_fb.3: register mxc display driver ldb > > >> This all looks valid, though things shouldn't hang here. >> --- >> >> Additional infos: >> >> $ cat /sys/devices/platform/mxc_sdc___fb.0/graphics/fb0/modes >> V:640x480p-60 >> U:640x480p-60 >> Was this from a boot without the HDMI monitor connected? The mxc_hdmi >> driver should list all of the display resolutions supported by the >> monitor as reported by EDID. >> >> >> Nope. This is from a boot with HDMI monitor connected. >> >> Kernel command line: console=ttymxc1,115200 >> console=ttymxc1,115200 >> root=/dev/sda2 rootwait >> video=mxcfb0:dev=hdmi,__1920x1080M@60,if=RGB24 >> > > When trying to reproduce things, I noted a > > -- You have two 'console=ttymxc1,115200' clauses here > > -- You appear to be using SATA (/dev/sda2). For SD card boot, > this should be /dev/mmcblk0p2 with a Yocto-standard image > > -- There's some extraneous stuff (__) in your video= clause > > I just booted with a slightly modified kernel command-line to try > and match yours: > Kernel command line: console=ttymxc1,115200 > video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 fbmem=48M vmalloc=400 > root=/dev/mmcblk0p1 rootwait > > What I found is that things booted, and I got a login prompt on the > serial console, but my display isn't functioning properly. > Hi Andrei, A couple of other things I noticed: - The serial port clock appears to get screwed up at around the point at which you say things hang. This is due to a recurring issue related to re-parenting of some of the clocks and will need to be addressed. For me, this causes a bunch of garbage, but my serial port and terminal emulator recover after ~1k of garbage. You might want to try restarting the terminal emulator you're using. - I don't trust my Yocto image. I tried to pull in the 1.1.0 patch set unsuccessfully and even the stock 720P resolution isn't working for me. I get the Yocto splash screen, but my X Server is dying. I'll re-build, but it will take hours. Meanwhile, can you try using the stock 6x_bootscript, which should come up at 720P? Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CAK18fxHH01WMaD8ZitqYV3z1GikGsz4JEdht4v0p9S8u0EGWcQ@mail.gmail.com>]
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite [not found] ` <CAK18fxHH01WMaD8ZitqYV3z1GikGsz4JEdht4v0p9S8u0EGWcQ@mail.gmail.com> @ 2013-03-01 14:13 ` Eric Nelson [not found] ` <CAK18fxHLoPofOew2TcKXMj3tzHgVzu=aOU4D56rDnQLhcrJ_vw@mail.gmail.com> 1 sibling, 0 replies; 11+ messages in thread From: Eric Nelson @ 2013-03-01 14:13 UTC (permalink / raw) To: Andrei Gherzan; +Cc: meta-freescale@yoctoproject.org, Otavio Salvador On 03/01/2013 01:06 AM, Andrei Gherzan wrote: > > > > On Thu, Feb 28, 2013 at 8:37 PM, Eric Nelson > <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>> wrote: > > On 02/28/2013 11:16 AM, Eric Nelson wrote: > > On 02/28/2013 08:34 AM, Andrei Gherzan wrote: > > > On Thu, Feb 28, 2013 at 5:30 PM, Eric Nelson > <eric.nelson@boundarydevices.__com > <mailto:eric.nelson@boundarydevices.com> > <mailto:eric.nelson@__boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>>> wrote: > > Hi Otavio and Andrei, > > On 02/28/2013 08:01 AM, Otavio Salvador wrote: > > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan > <andrei@gherzan.ro <mailto:andrei@gherzan.ro> > <mailto:andrei@gherzan.ro <mailto:andrei@gherzan.ro>>> wrote: > > While using imx6, I faced 2 issues after > updating the kernel > to ver. / rel. > 1.1.0: > > 1. If i boot the board with hdmi monitor > connected the boot > process hangs > with: > > --- > MIPI DSI driver module loaded > mxc_sdc_fb mxc_sdc_fb.0: register mxc display > driver hdmi > mxc_hdmi mxc_hdmi: Detected HDMI controller > 0x13:0xa:0xa0:0xc1 > fbcvt: 1920x1080@60: CVT Name - 2.073M9 > imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH > RESOLUTION: 1(0,1), > 5B(2~5), 5F(6,7) > Console: switching to colour frame buffer > device 240x67 > mxc_sdc_fb mxc_sdc_fb.1: register mxc display > driver lcd > mxc_sdc_fb mxc_sdc_fb.2: register mxc display > driver ldb > _regulator_get: get() with no identifier > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 0(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 1(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 2(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 3(VIC 1): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 4(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 5(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 6(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 7(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 8(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 9(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 10(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 11(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 12(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 13(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 14(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 15(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 16(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 17(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 18(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 19(VIC 0): > fbcvt: 1920x1080@60: CVT Name - 2.073M9 > mxc_sdc_fb mxc_sdc_fb.3: register mxc display > driver ldb > > > > > This all looks valid, though things shouldn't hang here. > --- > > Additional infos: > > $ cat > /sys/devices/platform/mxc_sdc_____fb.0/graphics/fb0/modes > V:640x480p-60 > U:640x480p-60 > Was this from a boot without the HDMI monitor > connected? The mxc_hdmi > driver should list all of the display resolutions > supported by the > monitor as reported by EDID. > > > Nope. This is from a boot with HDMI monitor connected. > > Kernel command line: console=ttymxc1,115200 > console=ttymxc1,115200 > root=/dev/sda2 rootwait > video=mxcfb0:dev=hdmi,____1920x1080M@60,if=RGB24 > > > When trying to reproduce things, I noted a > > -- You have two 'console=ttymxc1,115200' clauses here > > -- You appear to be using SATA (/dev/sda2). For SD card boot, > this should be /dev/mmcblk0p2 with a Yocto-standard image > > -- There's some extraneous stuff (__) in your video= clause > > I just booted with a slightly modified kernel command-line to try > and match yours: > Kernel command line: console=ttymxc1,115200 > video=mxcfb0:dev=hdmi,__1920x1080M@60,if=RGB24 fbmem=48M vmalloc=400 > root=/dev/mmcblk0p1 rootwait > > What I found is that things booted, and I got a login prompt on the > serial console, but my display isn't functioning properly. > > > Hi Andrei, > > A couple of other things I noticed: > - The serial port clock appears to get screwed up at around > the point at which you say things hang. This is due to > a recurring issue related to re-parenting of some of the > clocks and will need to be addressed. > > For me, this causes a bunch of garbage, but my serial > port and terminal emulator recover after ~1k of garbage. > > You might want to try restarting the terminal emulator > you're using. > > - I don't trust my Yocto image. I tried to pull in the > 1.1.0 patch set unsuccessfully and even the stock > 720P resolution isn't working for me. I get the Yocto > splash screen, but my X Server is dying. > > I'll re-build, but it will take hours. Meanwhile, can > you try using the stock 6x_bootscript, which should > come up at 720P? > > > Where can I find this stock script? I would kindly test it. > Hi Andre, This should be installed as a part of the Yocto SD card image. I built using "nitrogen6x" machine type and found that there's a copy of the script in: build/tmp/deploy/images/6x_bootscript-nitrogen6x How are you currently setting your bootargs in U-Boot? The stock script uses HDMI detection and sets up 720P along with other arguments: https://github.com/boundarydevices/u-boot-imx6/blob/production/board/boundary/nitrogen6x/6x_bootscript.txt Ahh. Never mind. I just found out how you're doing this, and oddly, it has my name as the author! https://github.com/Freescale/meta-fsl-arm-extra/commit/ebcb70c68a30bd0d07220d61a378488a512aa6c1 So you're setting and saving 'bootargs' with your video settings directly. If you add this bit, things should work for you. 'video=mxcfb1:off video=mxcfb2:off' Note that you might also need 'enable_wait_mode=off'. We saw some issues during early startup that still haven't been addressed as discussed here: http://boundarydevices.com/wait-a-second-hopefully-less/ Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CAK18fxHLoPofOew2TcKXMj3tzHgVzu=aOU4D56rDnQLhcrJ_vw@mail.gmail.com>]
* Re: Issues with sync-boundary-changes.patch on imx6qsabrelite [not found] ` <CAK18fxHLoPofOew2TcKXMj3tzHgVzu=aOU4D56rDnQLhcrJ_vw@mail.gmail.com> @ 2013-03-01 14:15 ` Eric Nelson 0 siblings, 0 replies; 11+ messages in thread From: Eric Nelson @ 2013-03-01 14:15 UTC (permalink / raw) To: Andrei Gherzan; +Cc: meta-freescale@yoctoproject.org, Otavio Salvador On 03/01/2013 01:28 AM, Andrei Gherzan wrote: > > > > On Fri, Mar 1, 2013 at 10:06 AM, Andrei Gherzan <andrei@gherzan.ro > <mailto:andrei@gherzan.ro>> wrote: > > > > > On Thu, Feb 28, 2013 at 8:37 PM, Eric Nelson > <eric.nelson@boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>> wrote: > > On 02/28/2013 11:16 AM, Eric Nelson wrote: > > On 02/28/2013 08:34 AM, Andrei Gherzan wrote: > > > On Thu, Feb 28, 2013 at 5:30 PM, Eric Nelson > <eric.nelson@boundarydevices.__com > <mailto:eric.nelson@boundarydevices.com> > <mailto:eric.nelson@__boundarydevices.com > <mailto:eric.nelson@boundarydevices.com>>> wrote: > > Hi Otavio and Andrei, > > On 02/28/2013 08:01 AM, Otavio Salvador wrote: > > On Thu, Feb 28, 2013 at 11:42 AM, Andrei Gherzan > <andrei@gherzan.ro <mailto:andrei@gherzan.ro> > <mailto:andrei@gherzan.ro <mailto:andrei@gherzan.ro>>> > wrote: > > While using imx6, I faced 2 issues after > updating the kernel > to ver. / rel. > 1.1.0: > > 1. If i boot the board with hdmi monitor > connected the boot > process hangs > with: > > --- > MIPI DSI driver module loaded > mxc_sdc_fb mxc_sdc_fb.0: register mxc > display driver hdmi > mxc_hdmi mxc_hdmi: Detected HDMI controller > 0x13:0xa:0xa0:0xc1 > fbcvt: 1920x1080@60: CVT Name - 2.073M9 > imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH > RESOLUTION: 1(0,1), > 5B(2~5), 5F(6,7) > Console: switching to colour frame buffer > device 240x67 > mxc_sdc_fb mxc_sdc_fb.1: register mxc > display driver lcd > mxc_sdc_fb mxc_sdc_fb.2: register mxc > display driver ldb > _regulator_get: get() with no identifier > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 0(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 1(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 2(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 3(VIC 1): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 4(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 5(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 6(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 7(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 8(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 9(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 10(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 11(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 12(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 13(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 14(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 15(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 16(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 17(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 18(VIC 0): > mxc_hdmi mxc_hdmi: > mxc_hdmi_edid_rebuild_____modelist: Added > mode 19(VIC 0): > fbcvt: 1920x1080@60: CVT Name - 2.073M9 > mxc_sdc_fb mxc_sdc_fb.3: register mxc > display driver ldb > > > > > This all looks valid, though things shouldn't hang > here. > --- > > Additional infos: > > $ cat > /sys/devices/platform/mxc_sdc_____fb.0/graphics/fb0/modes > V:640x480p-60 > U:640x480p-60 > Was this from a boot without the HDMI monitor > connected? The mxc_hdmi > driver should list all of the display resolutions > supported by the > monitor as reported by EDID. > > > Nope. This is from a boot with HDMI monitor connected. > > Kernel command line: console=ttymxc1,115200 > console=ttymxc1,115200 > root=/dev/sda2 rootwait > > video=mxcfb0:dev=hdmi,____1920x1080M@60,if=RGB24 > > > When trying to reproduce things, I noted a > > -- You have two 'console=ttymxc1,115200' clauses here > > -- You appear to be using SATA (/dev/sda2). For SD card boot, > this should be /dev/mmcblk0p2 with a Yocto-standard image > > -- There's some extraneous stuff (__) in your video= clause > > I just booted with a slightly modified kernel command-line > to try > and match yours: > Kernel command line: console=ttymxc1,115200 > video=mxcfb0:dev=hdmi,__1920x1080M@60,if=RGB24 fbmem=48M > vmalloc=400 > root=/dev/mmcblk0p1 rootwait > > What I found is that things booted, and I got a login prompt > on the > serial console, but my display isn't functioning properly. > > > Hi Andrei, > > A couple of other things I noticed: > - The serial port clock appears to get screwed up at around > the point at which you say things hang. This is due to > a recurring issue related to re-parenting of some of the > clocks and will need to be addressed. > > For me, this causes a bunch of garbage, but my serial > port and terminal emulator recover after ~1k of garbage. > > You might want to try restarting the terminal emulator > you're using. > > - I don't trust my Yocto image. I tried to pull in the > 1.1.0 patch set unsuccessfully and even the stock > 720P resolution isn't working for me. I get the Yocto > splash screen, but my X Server is dying. > > I'll re-build, but it will take hours. Meanwhile, can > you try using the stock 6x_bootscript, which should > come up at 720P? > > > Where can I find this stock script? I would kindly test it. > > > There is another strange issue. By not applying this patch the issues on > hdmi are not reproducible anymore but the second issue is still > reproducible on lvds... > Which patch and which issue? This chain has gotten rather long. Please advise, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-03-01 14:15 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAK18fxF8UjHgX=fu9ZO8c_uLsnkOekxNCtgAgJMpLmqCKdUHSg@mail.gmail.com>
[not found] ` <CAP9ODKrpBg13Vs8o65NYhkHWKzQq7ju80-+Ewc8qHwuqBsTAoA@mail.gmail.com>
[not found] ` <512F7827.5040901@boundarydevices.com>
[not found] ` <CAK18fxFSsmHbwje=obkZgFO+rpCGamC337JT20khQ8CSBDdiNA@mail.gmail.com>
2013-02-28 17:33 ` Issues with sync-boundary-changes.patch on imx6qsabrelite Eric Nelson
2013-02-28 17:47 ` Andrei Gherzan
2013-02-28 17:58 ` Eric Nelson
2013-02-28 18:03 ` Andrei Gherzan
2013-02-28 19:39 ` Eric Nelson
2013-02-28 17:51 ` Otavio Salvador
2013-02-28 18:16 ` Eric Nelson
2013-02-28 18:27 ` Andrei Gherzan
2013-02-28 18:37 ` Eric Nelson
[not found] ` <CAK18fxHH01WMaD8ZitqYV3z1GikGsz4JEdht4v0p9S8u0EGWcQ@mail.gmail.com>
2013-03-01 14:13 ` Eric Nelson
[not found] ` <CAK18fxHLoPofOew2TcKXMj3tzHgVzu=aOU4D56rDnQLhcrJ_vw@mail.gmail.com>
2013-03-01 14:15 ` Eric Nelson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.