iMX35 3stack framebuffer problem

Boaz Ben-David at
Sun May 29 03:14:27 EDT 2011


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.


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 at 01CBF829.06DE9870





*Email**: * at 

cid:image002.gif at 01CBF829.06DE9870 Please consider the impact on the 
environment before printing this e-mail and/or the attachment(s).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2930 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 510 bytes
Desc: not available
URL: <>

More information about the barebox mailing list