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@xxxxxxxxxx - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
