mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Boaz Ben-David <boaz.bd@wellsense-tech.com>
To: Baruch Siach <baruch@tkos.co.il>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: iMX35 3stack framebuffer problem
Date: Sun, 29 May 2011 10:14:27 +0300	[thread overview]
Message-ID: <4DE1F253.4050504@wellsense-tech.com> (raw)
In-Reply-To: <20110529063350.GB32378@jasper.tkos.co.il>


[-- 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

  reply	other threads:[~2011-05-29  7:15 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 [this message]
2011-05-29  7:28             ` Baruch Siach
2011-10-09  7:10               ` Boaz Ben-David
2011-10-10  4:44                 ` Baruch Siach
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=4DE1F253.4050504@wellsense-tech.com \
    --to=boaz.bd@wellsense-tech.com \
    --cc=barebox@lists.infradead.org \
    --cc=baruch@tkos.co.il \
    /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