We're debugging Solo (not sololite) board, and meeting a critical problem: system always hang or kernel panic (Oops) when loading android system.
It seems that this problem is caused by surfaceflinger service. kernel can run normally if surfaceflinger removed in init.rc.
kernel panic info:
[<c0095044>] (wq_worker_waking_up+0xc/0x58) from [<c007a480>] (ttwu_do_activate.clone.0+0x2c/0x40)
[<c007a480>] (ttwu_do_activate.clone.0+0x2c/0x40) from [<c007a768>] (try_to_wake_up+0x2d4/0x324)
[<c007a768>] (try_to_wake_up+0x2d4/0x324) from [<c009302c>] (__queue_work+0x150/0x384)
[<c009302c>] (__queue_work+0x150/0x384) from [<c0089b08>] (run_timer_softirq+0x124/0x244)
[<c0089b08>] (run_timer_softirq+0x124/0x244) from [<c0083c18>] (__do_softirq+0xa8/0x170)
[<c0083c18>] (__do_softirq+0xa8/0x170) from [<c0083f2c>] (irq_exit+0x90/0x98)
[<c0083f2c>] (irq_exit+0x90/0x98) from [<c0049fe4>] (handle_IRQ+0x50/0xac)
[<c0049fe4>] (handle_IRQ+0x50/0xac) from [<c004900c>] (__irq_svc+0x4c/0xe8)
[<c004900c>] (__irq_svc+0x4c/0xe8) from [<c05ac500>] (_raw_spin_unlock_irq+0x18/0x40)
[<c05ac500>] (_raw_spin_unlock_irq+0x18/0x40) from [<c004d194>] (die+0xbc/0x2a4)
[<c004d194>] (die+0xbc/0x2a4) from [<c0053e98>] (__do_kernel_fault+0x64/0x84)
[<c0053e98>] (__do_kernel_fault+0x64/0x84) from [<c0054038>] (do_page_fault+0x180/0x2e0)
[<c0054038>] (do_page_fault+0x180/0x2e0) from [<c0043464>] (do_DataAbort+0x34/0x98)
[<c0043464>] (do_DataAbort+0x34/0x98) from [<c0048f90>] (__dabt_svc+0x70/0xa0)
Exception stack(0xd5157ae0 to 0xd5157b28)
Or,
[<c0040d50>] (__dabt_svc+0x70/0xa0) from [<c00617e4>] (mxc_timer_interrupt+0x20/0x38)
[<c00617e4>] (mxc_timer_interrupt+0x20/0x38) from [<c00ab9fc>] (handle_irq_event_percpu+0x50/0x19c)
[<c00ab9fc>] (handle_irq_event_percpu+0x50/0x19c) from [<c00abb9c>] (handle_irq_event+0x54/0x84)
[<c00abb9c>] (handle_irq_event+0x54/0x84) from [<c00adc9c>] (handle_fasteoi_irq+0x84/0x138)
[<c00adc9c>] (handle_fasteoi_irq+0x84/0x138) from [<c00ab634>] (generic_handle_irq+0x30/0x3c)
[<c00ab634>] (generic_handle_irq+0x30/0x3c) from [<c0041b7c>] (handle_IRQ+0x30/0x84)
[<c0041b7c>] (handle_IRQ+0x30/0x84) from [<c0040dcc>] (__irq_svc+0x4c/0xa8)
[<c0040dcc>] (__irq_svc+0x4c/0xa8) from [<c0044c28>] (die+0xbc/0x2c0)
[<c0044c28>] (die+0xbc/0x2c0) from [<c004a8e8>] (__do_kernel_fault+0x64/0x84)
[<c004a8e8>] (__do_kernel_fault+0x64/0x84) from [<c004aa88>] (do_page_fault+0x180/0x2e0)
[<c004aa88>] (do_page_fault+0x180/0x2e0) from [<c003b240>] (do_DataAbort+0x34/0x98)
[<c003b240>] (do_DataAbort+0x34/0x98) from [<c0040d50>] (__dabt_svc+0x70/0xa0)
Have you ever encountered this?
Solved! Go to Solution.
DSIZ bits in MDCTL register is needed to change.
Extracted from IMX6SL RM:
The following registers in the MMDC define the DDR address space:
• MDMISC[DDR_4_BANK]—Defines either 4 or 8 banks in the DDR device
• MDCTL[DSIZ]—Defines the DDR data bus width of x16, x32 or x64
• MDMISC[BI]—Defines whether bank interleaving is on or off
• MDCTL[COL]—Defines the column size of the DDR device
• MDCTL[ROW]—Defines the row size of the DDR device
What version of the BSP are you using?
We are using the 13.4.1 anroid release, and I'm fairly certain it's due to DDR settings.
DDR connecting lead on our board is different from referenc design:
Our board:
Chip1 – CS0/D0-D15
Chip2 – CS0/D16-D31
Chip3 – CS1/D0-D15
Chip4 – CS1/D16-D31
Reference board:
Chip1 – CS0/D0-D15
Chip2 – CS0/D16-D31
Chip3 – CS0/D32-D47
Chip4 – CS0/D48-D63
So we need enable CS1 in flash_header.S, but I'm not clear how to config MMDC1.
DSIZ bits in MDCTL register is needed to change.
Extracted from IMX6SL RM:
The following registers in the MMDC define the DDR address space:
• MDMISC[DDR_4_BANK]—Defines either 4 or 8 banks in the DDR device
• MDCTL[DSIZ]—Defines the DDR data bus width of x16, x32 or x64
• MDMISC[BI]—Defines whether bank interleaving is on or off
• MDCTL[COL]—Defines the column size of the DDR device
• MDCTL[ROW]—Defines the row size of the DDR device
I will try to ask someone in expert team to help you.