Thanks, I think I will have to be creative on this. The only GPIO I can use is the same as the LCD contrast pin. 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. Boaz. 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 -- *Boaz Ben-David* R&D Engineer cid:image001.jpg@01CBF829.06DE9870 *Tel:*+972.2.6470.709 *Mob:*+972.54.678.1511** *Email**: *boaz.bd@wellsense-tech.com www.themapsystem.com cid:image002.gif@01CBF829.06DE9870 Please consider the impact on the environment before printing this e-mail and/or the attachment(s).