All of lore.kernel.org
 help / color / mirror / Atom feed
* IMX257 framebuffer problem
@ 2012-11-02 20:44 Stefan Koch
  2012-11-05 10:20 ` Stefan Koch
  2012-11-07 14:26 ` Stefan Koch
  0 siblings, 2 replies; 7+ messages in thread
From: Stefan Koch @ 2012-11-02 20:44 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

Hi,

I am porting Linux 3.6.2 to a board with Freescale IMX 257 ARM-CPU.

Linux works mostly, kernel can run, and Debian can run with kernel, too.

So I can get access via UART to Debian's Linux console and install 
packages via apt-get and so on.

So the next step is to enable the graphics support.

The line "imx25_add_imx_fb(&mx25cevipro_fb_pdata);" enables this.

Linux kernel works fine when this line is uncommented, but when it is 
active kernel stops before print out the first message on serial line.

So openocd prints with general U-Boot kernel boot:
WARNING: unknown debug reason: 0xf
ThumbEE -- incomplete support
target state: halted
target halted in ThumbEE state due to debug-request, current mode: System
cpsr: 0xffffffff pc: 0xfffffff9
MMU: enabled, D-Cache: enabled, I-Cache: enabled

And if I use gdb for loading and step through the source beginning from 
add_imx_fb(...) line I will get these output from openocd:

Unable to set 32 bit software breakpoint at address 8057c7e0 - check 
that memory is read/writable
Unable to set 32 bit software breakpoint at address 8057c7e0 - check 
that memory is read/writable
breakpoint not set
 > poll
background polling: on
TAP: imx25.cpu (enabled)
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x40000013 pc: 0x8057c7e0
MMU: enabled, D-Cache: enabled, I-Cache: enabled
 > step
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x40000013 pc: 0x8057c7e0
MMU: enabled, D-Cache: enabled, I-Cache: enabled

pc doesn't change anymore.

The board bsp (with the add_imx_fb(...) line) is this one: 
http://paste.debian.net/hidden/10d828f8/
And this is based on bsp from Freescale MX25 3DS board: 
http://paste.debian.net/hidden/50ada4ee/ or 
arch/arm/mach-imx/mach-mx25_3ds.c in kernel tree

There a two screenshots from ddd-Debugger attached.
The on is code view, and the other the backtrace.

What could be the problem?

(Display is connected via LVDS).

Thanks

Stefan Koch


[-- Attachment #2: code.png --]
[-- Type: image/png, Size: 59986 bytes --]

[-- Attachment #3: backtrace.png --]
[-- Type: image/png, Size: 15553 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: IMX257 framebuffer problem
  2012-11-02 20:44 IMX257 framebuffer problem Stefan Koch
@ 2012-11-05 10:20 ` Stefan Koch
  2012-11-05 10:43   ` richard -rw- weinberger
  2012-11-07 14:26 ` Stefan Koch
  1 sibling, 1 reply; 7+ messages in thread
From: Stefan Koch @ 2012-11-05 10:20 UTC (permalink / raw)
  To: linux-kernel

I have moved this message to linux-fbdev mailing list.

Am 02.11.2012 21:44, schrieb Stefan Koch:
> Hi,
>
> I am porting Linux 3.6.2 to a board with Freescale IMX 257 ARM-CPU.
>
> Linux works mostly, kernel can run, and Debian can run with kernel, too.
>
> So I can get access via UART to Debian's Linux console and install 
> packages via apt-get and so on.
>
> So the next step is to enable the graphics support.
>
> The line "imx25_add_imx_fb(&mx25cevipro_fb_pdata);" enables this.
>
> Linux kernel works fine when this line is uncommented, but when it is 
> active kernel stops before print out the first message on serial line.
>
> So openocd prints with general U-Boot kernel boot:
> WARNING: unknown debug reason: 0xf
> ThumbEE -- incomplete support
> target state: halted
> target halted in ThumbEE state due to debug-request, current mode: System
> cpsr: 0xffffffff pc: 0xfffffff9
> MMU: enabled, D-Cache: enabled, I-Cache: enabled
>
> And if I use gdb for loading and step through the source beginning 
> from add_imx_fb(...) line I will get these output from openocd:
>
> Unable to set 32 bit software breakpoint at address 8057c7e0 - check 
> that memory is read/writable
> Unable to set 32 bit software breakpoint at address 8057c7e0 - check 
> that memory is read/writable
> breakpoint not set
> > poll
> background polling: on
> TAP: imx25.cpu (enabled)
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x40000013 pc: 0x8057c7e0
> MMU: enabled, D-Cache: enabled, I-Cache: enabled
> > step
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x40000013 pc: 0x8057c7e0
> MMU: enabled, D-Cache: enabled, I-Cache: enabled
>
> pc doesn't change anymore.
>
> The board bsp (with the add_imx_fb(...) line) is this one: 
> http://paste.debian.net/hidden/10d828f8/
> And this is based on bsp from Freescale MX25 3DS board: 
> http://paste.debian.net/hidden/50ada4ee/ or 
> arch/arm/mach-imx/mach-mx25_3ds.c in kernel tree
>
> There a two screenshots from ddd-Debugger attached.
> The on is code view, and the other the backtrace.
>
> What could be the problem?
>
> (Display is connected via LVDS).
>
> Thanks
>
> Stefan Koch
>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: IMX257 framebuffer problem
  2012-11-05 10:20 ` Stefan Koch
@ 2012-11-05 10:43   ` richard -rw- weinberger
  2012-11-05 12:25     ` Stefan Koch
  2012-11-05 15:21     ` Stefan Koch
  0 siblings, 2 replies; 7+ messages in thread
From: richard -rw- weinberger @ 2012-11-05 10:43 UTC (permalink / raw)
  To: Stefan Koch; +Cc: linux-kernel

On Mon, Nov 5, 2012 at 11:20 AM, Stefan Koch <stefan.koch10@gmail.com> wrote:
>> What could be the problem?

Find out what exactly is happening after calling add_imx_fb().
Call it a bit later so that you can see everything on the UART.
You can hack the call into init/main.c or something else...

-- 
Thanks,
//richard

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: IMX257 framebuffer problem
  2012-11-05 10:43   ` richard -rw- weinberger
@ 2012-11-05 12:25     ` Stefan Koch
  2012-11-05 13:35       ` Stefan Koch
  2012-11-05 15:21     ` Stefan Koch
  1 sibling, 1 reply; 7+ messages in thread
From: Stefan Koch @ 2012-11-05 12:25 UTC (permalink / raw)
  To: richard -rw- weinberger, linux-kernel

I'll try it...

Could be this a problem?:
"imx-sdma imx35-sdma: firmware not found" appears when booting the 
kernel without enabled fb.

In FB enabled kernel's the last debugable function is 
imx_add_platform_device_dmamask()

Both have "dma" in the string...

But for loading a firmware from filesystem, the kernel crashes to early, 
I think.

If you subscribed to linux-fbdev mailing list, can you check If my 
message is come in there?
Because marc.info archives does not show my messages on linux-fbdev, but 
all from other people after my message.
I have send the message more times.

Thanks


Am 05.11.2012 11:43, schrieb richard -rw- weinberger:
> On Mon, Nov 5, 2012 at 11:20 AM, Stefan Koch<stefan.koch10@gmail.com>  wrote:
>>> What could be the problem?
> Find out what exactly is happening after calling add_imx_fb().
> Call it a bit later so that you can see everything on the UART.
> You can hack the call into init/main.c or something else...
>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: IMX257 framebuffer problem
  2012-11-05 12:25     ` Stefan Koch
@ 2012-11-05 13:35       ` Stefan Koch
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Koch @ 2012-11-05 13:35 UTC (permalink / raw)
  To: richard -rw- weinberger, linux-kernel

Ignore my first message that I have moved this message to linux-fbdev. 
This was not successful so this message is still at linux-kernel.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: IMX257 framebuffer problem
  2012-11-05 10:43   ` richard -rw- weinberger
  2012-11-05 12:25     ` Stefan Koch
@ 2012-11-05 15:21     ` Stefan Koch
  1 sibling, 0 replies; 7+ messages in thread
From: Stefan Koch @ 2012-11-05 15:21 UTC (permalink / raw)
  To: linux-kernel; +Cc: richard -rw- weinberger

If I add "video=imxfb:SVGA-16@60" to kernel command line, then there are 
new messages when init fb within BSP file:

Division by zero in kernel.
[<80019ba4>] (unwind_backtrace+0x0/0xf4) from [<8022accc>] (Ldiv0+0x8/0x10)
[<8022accc>] (Ldiv0+0x8/0x10) from [<8022ac9c>] (__aeabi_uidivmod+0x8/0x18)
[<8022ac9c>] (__aeabi_uidivmod+0x8/0x18) from [<80254198>] 
(cfb_imageblit+0x1fc/0x4b0)
[<80254198>] (cfb_imageblit+0x1fc/0x4b0) from [<80251c94>] 
(soft_cursor+0x158/0x1bc)
[<80251c94>] (soft_cursor+0x158/0x1bc) from [<80251664>] 
(bit_cursor+0x4ac/0x4c8)
[<80251664>] (bit_cursor+0x4ac/0x4c8) from [<8024bcd8>] 
(fb_flashcursor+0x108/0x124)
[<8024bcd8>] (fb_flashcursor+0x108/0x124) from [<8003cc00>] 
(process_one_work+0x188/0x4fc)
[<8003cc00>] (process_one_work+0x188/0x4fc) from [<8003d458>] 
(worker_thread+0x130/0x598)
[<8003d458>] (worker_thread+0x130/0x598) from [<80043ef0>] 
(kthread+0x8c/0x98)
[<80043ef0>] (kthread+0x8c/0x98) from [<80015268>] 
(kernel_thread_exit+0x0/0x8)
Division by zero in kernel.
[<80019ba4>] (unwind_backtrace+0x0/0xf4) from [<8022accc>] (Ldiv0+0x8/0x10)
[<8022accc>] (Ldiv0+0x8/0x10) from [<8022ac9c>] (__aeabi_uidivmod+0x8/0x18)
[<8022ac9c>] (__aeabi_uidivmod+0x8/0x18) from [<80254198>] 
(cfb_imageblit+0x1fc/0x4b0)
[<80254198>] (cfb_imageblit+0x1fc/0x4b0) from [<80251c94>] 
(soft_cursor+0x158/0x1bc)
[<80251c94>] (soft_cursor+0x158/0x1bc) from [<80251664>] 
(bit_cursor+0x4ac/0x4c8)
[<80251664>] (bit_cursor+0x4ac/0x4c8) from [<8024bcd8>] 
(fb_flashcursor+0x108/0x124)
[<8024bcd8>] (fb_flashcursor+0x108/0x124) from [<8003cc00>] 
(process_one_work+0x188/0x4fc)
[<8003cc00>] (process_one_work+0x188/0x4fc) from [<8003d458>] 
(worker_thread+0x130/0x598)
[<8003d458>] (worker_thread+0x130/0x598) from [<80043ef0>] 
(kthread+0x8c/0x98)
[<80043ef0>] (kthread+0x8c/0x98) from [<80015268>] 
(kernel_thread_exit+0x0/0x8)
Division by zero in kernel.

Without this command line parameter the "cpsr: 0xffffffff pc: 
0xfffffff9" error still occurs.

The boot works fine when I add the fb_init as you suggested in the 
main.c from kernel.
But I have no /dev/fb0 device. And there are no messages about 
framebuffer in dmesg.

Thanks

Am 05.11.2012 11:43, schrieb richard -rw- weinberger:
> On Mon, Nov 5, 2012 at 11:20 AM, Stefan Koch<stefan.koch10@gmail.com>  wrote:
>>> What could be the problem?
> Find out what exactly is happening after calling add_imx_fb().
> Call it a bit later so that you can see everything on the UART.
> You can hack the call into init/main.c or something else...
>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: IMX257 framebuffer problem
  2012-11-02 20:44 IMX257 framebuffer problem Stefan Koch
  2012-11-05 10:20 ` Stefan Koch
@ 2012-11-07 14:26 ` Stefan Koch
  1 sibling, 0 replies; 7+ messages in thread
From: Stefan Koch @ 2012-11-07 14:26 UTC (permalink / raw)
  To: linux-kernel

At last posting this message to linux-fbdev has worked.
Refer to this: http://marc.info/?l=linux-fbdev&m=135229680920277&w=2


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-11-07 14:26 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-02 20:44 IMX257 framebuffer problem Stefan Koch
2012-11-05 10:20 ` Stefan Koch
2012-11-05 10:43   ` richard -rw- weinberger
2012-11-05 12:25     ` Stefan Koch
2012-11-05 13:35       ` Stefan Koch
2012-11-05 15:21     ` Stefan Koch
2012-11-07 14:26 ` Stefan Koch

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.