iMX35 3stack framebuffer problem

iMX35 3stack framebuffer problem

[Boaz Ben-David]

[-- Attachment #1.1: Type: text/plain, Size: 498 bytes --]

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?

Thanks,

Boaz.

[-- Attachment #1.2: Type: text/html, Size: 780 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

Re: iMX35 3stack framebuffer problem

[Marc Reilly]

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

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

Re: iMX35 3stack framebuffer problem

[Boaz Ben-David]

Yes, I am using the freescale kernel unfotunately.
Do you know of some way to fix this (a patch for the freescale kernel
maybe)?

Thanks,

Boaz.


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
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

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

Re: iMX35 3stack framebuffer problem

[Baruch Siach]

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

Re: iMX35 3stack framebuffer problem

[Boaz Ben-David]

[-- Attachment #1.1: Type: text/plain, Size: 2105 bytes --]

Hi,

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?

Thanks,

Boaz.

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 
<redir.aspx?C=e6361e2526464b699e255e33ea5cfebb&URL=http%3a%2f%2fwww.themapsystem.com%2f>

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



[-- Attachment #1.2.1: Type: text/html, Size: 16292 bytes --]

[-- Attachment #1.2.2: image001.jpg --]
[-- Type: image/jpeg, Size: 2930 bytes --]

[-- Attachment #1.2.3: image002.gif --]
[-- Type: image/gif, Size: 510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

Re: iMX35 3stack framebuffer problem

[Baruch Siach]

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

Re: iMX35 3stack framebuffer problem

[Boaz Ben-David]

[-- Attachment #1.1: Type: text/plain, Size: 3095 bytes --]

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 
<redir.aspx?C=e6361e2526464b699e255e33ea5cfebb&URL=http%3a%2f%2fwww.themapsystem.com%2f>

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



[-- Attachment #1.2.1: Type: text/html, Size: 17490 bytes --]

[-- Attachment #1.2.2: image001.jpg --]
[-- Type: image/jpeg, Size: 2930 bytes --]

[-- Attachment #1.2.3: image002.gif --]
[-- Type: image/gif, Size: 510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

Re: iMX35 3stack framebuffer problem

[Baruch Siach]

Hi Boaz,

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
> 
> 
> -- 
> 
> 
> *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 <redir.aspx?C=e6361e2526464b699e255e33ea5cfebb&URL=http%3a%2f%2fwww.themapsystem.com%2f>
> 
> cid:image002.gif@01CBF829.06DE9870 Please consider the impact on the
> environment before printing this e-mail and/or the attachment(s).
> 
> 

-- 
                                                     ~. .~   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

Re: iMX35 3stack framebuffer problem

[Boaz Ben-David]

Hi all,

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
the flicker had already happened. Meaning, when I finally have control 
over the GPIOs it is too late.
As far as I understand the arch specific code is called in the 
start_kernel function, and what I would like to
do is set the controlling GPIO to low before the setup_arch function is 
called in start_kernel function.
Is that even possible? I've been trying to fiddle around using physical 
addresses to do that but all I achieved is
getting the kernel stuck at boot.

Thanks,

Boaz.

On 05/29/11 10:28, Baruch Siach wrote:
> Hi Boaz,
>
> 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
>>
>> --
>>
>>
>> *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<redir.aspx?C=e6361e2526464b699e255e33ea5cfebb&URL=http%3a%2f%2fwww.themapsystem.com%2f>
>>
>> cid:image002.gif@01CBF829.06DE9870 Please consider the impact on the
>> environment before printing this e-mail and/or the attachment(s).
>>
>>
> --
>                                                       ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>     - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6185 (20110606) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>



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

Re: iMX35 3stack framebuffer problem

[Baruch Siach]

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

Re: iMX35 3stack framebuffer problem

[Boaz Ben-David]

[-- Attachment #1.1: Type: text/plain, Size: 4628 bytes --]

On 10/10/11 06:44, Baruch Siach wrote:
> 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

Hi Baruch,


Yes, I didn't mention it, but I tried your suggestion. It works (meaning 
there's no flicker) but

the problem is that the screen is blank for about 8 seconds before I 
have control again to init it.

People here said they prefer flicker over 8 seconds of blank time...

So, this got me to trying to blank the screen from inside the kernel and 
the unblank it after it has been inited properly.

Problem is that when the GPIO module is inited the flicker has already 
happened.

Is there some hope or what I am trying to do is practically imposibble?


Thanks,


Boaz.


[-- Attachment #1.2: Type: text/html, Size: 6463 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

Re: iMX35 3stack framebuffer problem

[Robert Schwebel]

On Tue, Oct 11, 2011 at 08:40:52AM +0200, Boaz Ben-David wrote:
> Yes, I didn't mention it, but I tried your suggestion. It works
> (meaning there's no flicker) but
>
> the problem is that the screen is blank for about 8 seconds before I
> have control again to init it.
>
> People here said they prefer flicker over 8 seconds of blank time...

This is why we have a framebuffer / video driver framework in Barebox.
We do not have a driver for MX35 yet, but that could of course be
changed.

On the other hand, I'm wondering why it needs 8 s until you see
something on the Linux side. We have an MX35 system here which runs at
532 MHz, and it needs about 1 s from power-on into Linux userspace, so
we decided to show the splash screen from there.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

Re: iMX35 3stack framebuffer problem

[Boaz Ben-David]

On 10/11/11 08:57, Boaz Ben-David wrote:
> On 10/11/11 08:54, Robert Schwebel wrote:
>> On Tue, Oct 11, 2011 at 08:40:52AM +0200, Boaz Ben-David wrote:
>>> Yes, I didn't mention it, but I tried your suggestion. It works
>>> (meaning there's no flicker) but
>>>
>>> the problem is that the screen is blank for about 8 seconds before I
>>> have control again to init it.
>>>
>>> People here said they prefer flicker over 8 seconds of blank time...
>> This is why we have a framebuffer / video driver framework in Barebox.
>> We do not have a driver for MX35 yet, but that could of course be
>> changed.
>>
>> On the other hand, I'm wondering why it needs 8 s until you see
>> something on the Linux side. We have an MX35 system here which runs at
>> 532 MHz, and it needs about 1 s from power-on into Linux userspace, so
>> we decided to show the splash screen from there.
>>
>> rsc

The kernel size is almost 5MB (it includes an initramfs).

8 seconds are from the time I call "bootm uImage" and until the init 
script in the initramfs kicks in.

If I can seriously shorten this time I will be glad to know, maybe 
there's something I missed.

Any input will be appreciated.


Thanks,

Boaz.


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

Re: iMX35 3stack framebuffer problem

[Baruch Siach]

Hi Boaz,

On Tue, Oct 11, 2011 at 08:57:15AM +0200, Boaz Ben-David wrote:
> On 10/11/11 08:54, Robert Schwebel wrote:
> 
>     On Tue, Oct 11, 2011 at 08:40:52AM +0200, Boaz Ben-David wrote:
> 
>         Yes, I didn't mention it, but I tried your suggestion. It works
>         (meaning there's no flicker) but
> 
>         the problem is that the screen is blank for about 8 seconds before I
>         have control again to init it.
> 
>         People here said they prefer flicker over 8 seconds of blank time...
> 
>     This is why we have a framebuffer / video driver framework in Barebox.
>     We do not have a driver for MX35 yet, but that could of course be
>     changed.
> 
>     On the other hand, I'm wondering why it needs 8 s until you see
>     something on the Linux side. We have an MX35 system here which runs at
>     532 MHz, and it needs about 1 s from power-on into Linux userspace, so
>     we decided to show the splash screen from there.
> 
>     rsc
> 
> The kernel size is almost 5MB (it includes an initramfs).
> 
> 8 seconds are from the time I call "bootm uImage" and until the init script in
> the initramfs kicks in.
> 
> If I can seriously shorten this time I will be glad to know, maybe there's
> something I missed.
> 
> Any input will be appreciated.

See 
http://elinux.org/images/8/89/ELCE-2010-Barebox-Booting-Linux-Fast-and-Fancy.pdf.  
This presentation (by Robert Schwebel) specifically mentions Barebox on 
i.MX35.

baruch

-- 
                                                     ~. .~   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

Re: iMX35 3stack framebuffer problem

[Robert Schwebel]

On Tue, Oct 11, 2011 at 08:57:15AM +0200, Boaz Ben-David wrote:
> The kernel size is almost 5MB (it includes an initramfs).
>
> 8 seconds are from the time I call "bootm uImage" and until the init script in
> the initramfs kicks in.
>
> If I can seriously shorten this time I will be glad to know, maybe there's
> something I missed.

Do you really need such a big image? Making things as small as possible
in the first place and load everything that's possible at a later time
is a good strategy for quickboot scenarios.

The elinux reference is a good one for boot time reduction. Their wiki
has a long list of possibilities.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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