mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: Boaz Ben-David <boaz.bd@wellsense-tech.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: iMX35 3stack framebuffer problem
Date: Mon, 10 Oct 2011 06:44:51 +0200	[thread overview]
Message-ID: <20111010044451.GA28707@sapphire.tkos.co.il> (raw)
In-Reply-To: <4E9148E5.6070102@wellsense-tech.com>

Hi Boaz,

On Sun, Oct 09, 2011 at 09:10:29AM +0200, Boaz Ben-David wrote:
> I haven't been able to solve this problem.
> The issue I'm having here is that when I'm using a GPIO to power
> down the LCD during the kernel boot

[snip]

My suggestion was to disable LCD backlight from Barebox BEFORE booting Linux.  
Something along the lines of:

fb0.enable=0
bootz /dev/nand0.kernel.bb

(assuming that your .enable framebuffer callback does the right thing.)
Then, once Linux boots and the kernel framebuffer driver is loaded, enable LCD 
backlight from your board's kernel code, or a shell script. This blanks you 
LCD for a relatively short time during kernel boot, which is better than 
having random flicker.

baruch

> On 05/29/11 10:28, Baruch Siach wrote:
> >On Sun, May 29, 2011 at 10:14:27AM +0300, Boaz Ben-David wrote:
> >>I think I will have to be creative on this.
> >>The only GPIO I can use is the same as the LCD contrast pin.
> >You probably mean LCD brightness here. If so, this is probably the best you
> >can do if you can't power down the LCD completely with a GPIO.
> >
> >>I think I need to
> >>start it as a GPIO, put 0 on it and after the FB is inited mux it
> >>back to LCD contrast function,  if that is possible.
> >Ugly, but definitely possible. You have the .enable callback for that.
> >
> >baruch
> >
> >>On 05/29/11 09:33, Baruch Siach wrote:
> >>>Hi Boaz,
> >>>
> >>>On Sun, May 29, 2011 at 09:08:58AM +0300, Boaz Ben-David wrote:
> >>>>Revisiting the issue below, it there a convinient way
> >>>>to use the FB in barebox without creating a flicker on the LCD in
> >>>>the transition from Barebox to the kernel?
> >>>Probably not, at the moment.
> >>>
> >>>One big problem (not the only one) is that the mx3fb driver uses DMA to
> >>>transfer the display image from the system RAM to the LCD. The ARM booting
> >>>document, however, requires the bootloader to "quiesce all DMA capable
> >>>devices" (Documentation/arm/Booting).
> >>>
> >>>The best you can achieve (assuming you have designed your hardware correctly)
> >>>is to blank your LCD using a GPIO just before booting the kernel, and then
> >>>switch this GPIO again just after painting your logo from the newly boot
> >>>kernel.
> >>>
> >>>baruch
> >>>
> >>>>On 03/08/11 09:10, Baruch Siach wrote:
> >>>>>Hi Boaz,
> >>>>>
> >>>>>On Tue, Mar 08, 2011 at 09:03:55AM +0200, Boaz Ben-David wrote:
> >>>>>>Yes, I am using the freescale kernel unfotunately.
> >>>>>>Do you know of some way to fix this (a patch for the freescale kernel
> >>>>>>maybe)?
> >>>>>A simple way to check whether this is the problems is to just disable the
> >>>>>framebuffer in the kernel build, and make sure that you can boot again.
> >>>>>
> >>>>>Then, the fix for this problem is to move the request_irq() call to the end of
> >>>>>the .probe routine.
> >>>>>
> >>>>>You should not expect any kind of support from Freescale for their released
> >>>>>Linux kernels.
> >>>>>
> >>>>>baruch
> >>>>>
> >>>>>>On Tue, 2011-03-08 at 16:35 +1100, Marc Reilly wrote:
> >>>>>>>On Tuesday, March 08, 2011 03:35:10 am Boaz Ben-David wrote:
> >>>>>>>>Hi,
> >>>>>>>>
> >>>>>>>>When using the iMX35 freescale 3stack we are having some issues with the FB
> >>>>>>>>driver. On device boot we enable the fb using "fb0.enable=1" and then try
> >>>>>>>>to boot the kernel from nand. The problem is that after the kernel is
> >>>>>>>>loaded to RAM and extracted the board hangs. If we do not init the fb0
> >>>>>>>>device but simply boot the kernel it works fine. Trying "fb0.enable=0"
> >>>>>>>>before booting also did not help.
> >>>>>>>>Did anyone encounter this issue yet or are we doing something wrong?
> >>>>>>>Are you using the freescale kernel? It doesn't handle loading the IPU driver
> >>>>>>>if the IPU has been enabled previously.. (an IRQ fires before all the driver
> >>>>>>>structures have been initialized and crashes)
> >>>>>>>
> >>>>>>>Cheers,
> >>>>>>>Marc

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2011-10-10  4:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-07 16:35 Boaz Ben-David
2011-03-08  5:35 ` Marc Reilly
2011-03-08  7:03   ` Boaz Ben-David
2011-03-08  7:10     ` Baruch Siach
2011-05-29  6:08       ` Boaz Ben-David
2011-05-29  6:33         ` Baruch Siach
2011-05-29  7:14           ` Boaz Ben-David
2011-05-29  7:28             ` Baruch Siach
2011-10-09  7:10               ` Boaz Ben-David
2011-10-10  4:44                 ` Baruch Siach [this message]
2011-10-11  6:40                   ` Boaz Ben-David
2011-10-11  6:54                     ` Robert Schwebel
     [not found]                       ` <4E93E8CB.1040504@wellsense-tech.com>
2011-10-11  6:59                         ` Boaz Ben-David
2011-10-11  7:01                         ` Baruch Siach
2011-10-11  7:06                         ` Robert Schwebel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111010044451.GA28707@sapphire.tkos.co.il \
    --to=baruch@tkos.co.il \
    --cc=barebox@lists.infradead.org \
    --cc=boaz.bd@wellsense-tech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox