omap2/3/4: Multi-omap updates to boot test with omap3_defconfig

Zoom2 and 3 have UARTs only on the external debug board. GPMC needs to be mapped early to use it for DEBUG_LL.

Additionally, 0xfb000000 overlaps with other areas, so use 0xfa400000 for the virtual address instead.

Note that with the pending serial.c patches you need to set console=ttyS0,115200n8 as it will be the only UART mapped. To use DEBUG_LL, you need to pass also earlyprintk in cmdline.

Cc Allen Pais <[email protected]>

Cc Vikram Pandita <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/kernel/head.S                         |   10 ++++++++++
 arch/arm/mach-omap2/board-zoom-debugboard.c    |    2 +-
 arch/arm/mach-omap2/include/mach/debug-macro.S |    4 ++--
 arch/arm/mach-omap2/io.c                       |    9 +++++++++
 arch/arm/plat-omap/include/plat/serial.h       |    2 +-
 5 files changed, 23 insertions(+), 4 deletions(-)

arch/arm/kernel/head.S +0 -0

index eb62bf9..fd870e1 100644
@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif

Quoted 36 lines · Tony Lindgren

Zoom2 and 3 have UARTs only on the external debug board. GPMC needs to be mapped early to use it for DEBUG_LL.

Additionally, 0xfb000000 overlaps with other areas, so use 0xfa400000 for the virtual address instead.

Note that with the pending serial.c patches you need to set console=ttyS0,115200n8 as it will be the only UART mapped. To use DEBUG_LL, you need to pass also earlyprintk in cmdline.

Cc Allen Pais <[email protected]>

Cc Vikram Pandita <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/kernel/head.S                         |   10 ++++++++++
 arch/arm/mach-omap2/board-zoom-debugboard.c    |    2 +-
 arch/arm/mach-omap2/include/mach/debug-macro.S |    4 ++--
 arch/arm/mach-omap2/io.c                       |    9 +++++++++
 arch/arm/plat-omap/include/plat/serial.h       |    2 +-
 5 files changed, 23 insertions(+), 4 deletions(-)

arch/arm/kernel/head.S +6 -0

index eb62bf9..fd870e1 100644
@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3)
+	/*
+	 * Zoom2 and Zoom3 have UARTs only on the debug board.
+	 * The debug board is connected to the GPMC.
+	 */
+	add	r0, r4, #0xfa000000 >> 18

arch/arm/kernel/head.S __create_page_tables: · line 340

Quoted 4 lines

arch/arm/kernel/head.S +4 -0

+	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
+	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
+	str	r3, [r0]
+#endif

I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S

Quoted 38 lines · Kevin Hilman

Quoted 36 lines · Tony Lindgren

Zoom2 and 3 have UARTs only on the external debug board. GPMC needs to be mapped early to use it for DEBUG_LL.

Additionally, 0xfb000000 overlaps with other areas, so use 0xfa400000 for the virtual address instead.

Note that with the pending serial.c patches you need to set console=ttyS0,115200n8 as it will be the only UART mapped. To use DEBUG_LL, you need to pass also earlyprintk in cmdline.

Cc Allen Pais <[email protected]>

Cc Vikram Pandita <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/kernel/head.S                         |   10 ++++++++++
 arch/arm/mach-omap2/board-zoom-debugboard.c    |    2 +-
 arch/arm/mach-omap2/include/mach/debug-macro.S |    4 ++--
 arch/arm/mach-omap2/io.c                       |    9 +++++++++
 arch/arm/plat-omap/include/plat/serial.h       |    2 +-
 5 files changed, 23 insertions(+), 4 deletions(-)

arch/arm/kernel/head.S +6 -0

index eb62bf9..fd870e1 100644
@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3)
+	/*
+	 * Zoom2 and Zoom3 have UARTs only on the debug board.
+	 * The debug board is connected to the GPMC.
+	 */
+	add	r0, r4, #0xfa000000 >> 18

Quoted 8 lines

arch/arm/kernel/head.S __create_page_tables: · line 340

Quoted 4 lines

arch/arm/kernel/head.S +4 -0

+	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
+	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
+	str	r3, [r0]
+#endif

I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S

That mapping does not cover the GPMC area where this UART is.

-----Original Message-----
From: Kevin Hilman [mailto:khilman at deeprootsystems.com]
Sent: Friday, April 30, 2010 4:21 PM
To: Tony Lindgren
Cc: linux-arm-kernel at lists.infradead.org; Pandita, Vikram; linux- omap at vger.kernel.org; Pais, Allen
Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

Quoted 25 lines · Tony Lindgren

Quoted 24 lines · Kevin Hilman

Quoted 22 lines · Tony Lindgren

Zoom2 and 3 have UARTs only on the external debug board. GPMC needs to be mapped early to use it for DEBUG_LL.

Additionally, 0xfb000000 overlaps with other areas, so use 0xfa400000 for the virtual address instead.

Note that with the pending serial.c patches you need to set console=ttyS0,115200n8 as it will be the only UART mapped. To use DEBUG_LL, you need to pass also earlyprintk in cmdline.

Cc Allen Pais <[email protected]>

Cc Vikram Pandita <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/kernel/head.S                         |   10 ++++++++++
 arch/arm/mach-omap2/board-zoom-debugboard.c    |    2 +-
 arch/arm/mach-omap2/include/mach/debug-macro.S |    4 ++--
 arch/arm/mach-omap2/io.c                       |    9 +++++++++
 arch/arm/plat-omap/include/plat/serial.h       |    2 +-
 5 files changed, 23 insertions(+), 4 deletions(-)

Quoted 9 lines

Quoted 9 lines

arch/arm/kernel/head.S __create_page_tables: · line 331

Quoted 9 lines

arch/arm/kernel/head.S +1 -0

index eb62bf9..fd870e1 100644
@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) ||

defined(CONFIG_MACH_OMAP_ZOOM3)

Quoted 14 lines

Quoted 13 lines

arch/arm/kernel/head.S __create_page_tables: · line 340

Quoted 9 lines

arch/arm/kernel/head.S +9 -0

+	/*
+	 * Zoom2 and Zoom3 have UARTs only on the debug board.
+	 * The debug board is connected to the GPMC.
+	 */
+	add	r0, r4, #0xfa000000 >> 18
+	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
+	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
+	str	r3, [r0]
+#endif

I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S

Quoted 1 line

That mapping does not cover the GPMC area where this UART is.

Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else.

Kevin

-----Original Message-----

owner at vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Friday, April 30, 2010 4:37 PM
To: Kevin Hilman; Tony Lindgren
Cc: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org; Pais, Allen
Subject: RE: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

Quoted 59 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at deeprootsystems.com]
Sent: Friday, April 30, 2010 4:21 PM
To: Tony Lindgren
Cc: linux-arm-kernel at lists.infradead.org; Pandita, Vikram; linux- omap at vger.kernel.org; Pais, Allen
Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

Quoted 25 lines · Tony Lindgren

Quoted 24 lines · Kevin Hilman

Quoted 22 lines · Tony Lindgren

Zoom2 and 3 have UARTs only on the external debug board. GPMC needs to be mapped early to use it for DEBUG_LL.

Additionally, 0xfb000000 overlaps with other areas, so use 0xfa400000 for the virtual address instead.

Note that with the pending serial.c patches you need to set console=ttyS0,115200n8 as it will be the only UART mapped. To use DEBUG_LL, you need to pass also earlyprintk in cmdline.

Cc Allen Pais <[email protected]>

Cc Vikram Pandita <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/kernel/head.S                         |   10 ++++++++++
 arch/arm/mach-omap2/board-zoom-debugboard.c    |    2 +-
 arch/arm/mach-omap2/include/mach/debug-macro.S |    4 ++--
 arch/arm/mach-omap2/io.c                       |    9 +++++++++
 arch/arm/plat-omap/include/plat/serial.h       |    2 +-
 5 files changed, 23 insertions(+), 4 deletions(-)

Quoted 9 lines

Quoted 9 lines

arch/arm/kernel/head.S __create_page_tables: · line 331

Quoted 9 lines

arch/arm/kernel/head.S +1 -0

index eb62bf9..fd870e1 100644
@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) ||

defined(CONFIG_MACH_OMAP_ZOOM3)

Quoted 14 lines

Quoted 13 lines

arch/arm/kernel/head.S __create_page_tables: · line 340

Quoted 9 lines

arch/arm/kernel/head.S +9 -0

+	/*
+	 * Zoom2 and Zoom3 have UARTs only on the debug board.
+	 * The debug board is connected to the GPMC.
+	 */
+	add	r0, r4, #0xfa000000 >> 18
+	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
+	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
+	str	r3, [r0]
+#endif

I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S

Quoted 5 lines

Quoted 1 line

That mapping does not cover the GPMC area where this UART is.

Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else.

Here is the problem -
with current approach we need two mappings to happen and the MACHINE_START() code allows for only one via .io_pg_offset and .phys_io

Why:
Tony's approach is to pass the information about the debug uart number from the UART1 Scratchpad register.

this introduces a dependency that
UART1 registers also be mapped (virt<->phy).

So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x4800000 based mapping and for external uart zoom3 port, create this extra mapping.

So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem.

Quoted 4 lines

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 22 lines

Quoted 7 lines

Quoted 7 lines

arch/arm/kernel/head.S __create_page_tables: · line 331

Quoted 7 lines

arch/arm/kernel/head.S +1 -0

@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) ||

defined(CONFIG_MACH_OMAP_ZOOM3)

Quoted 14 lines

Quoted 13 lines

arch/arm/kernel/head.S __create_page_tables: · line 340

Quoted 9 lines

arch/arm/kernel/head.S +9 -0

+	/*
+	 * Zoom2 and Zoom3 have UARTs only on the debug board.
+	 * The debug board is connected to the GPMC.
+	 */
+	add	r0, r4, #0xfa000000 >> 18
+	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
+	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
+	str	r3, [r0]
+#endif

I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S

Quoted 5 lines

Quoted 1 line

That mapping does not cover the GPMC area where this UART is.

Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else.

Here is the problem - with current approach we need two mappings to happen and the MACHINE_START() code allows for only one via .io_pg_offset and .phys_io

Why:

Tony's approach is to pass the information about the debug uart number from the UART1 Scratchpad register.

this introduces a dependency that
UART1 registers also be mapped (virt<->phy).

So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x4800000 based mapping and for external uart zoom3 port, create this extra mapping.

So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem.

"Pandita, Vikram" <[email protected]> writes:

[...]

Quoted 44 lines

Quoted 22 lines

Quoted 7 lines

Quoted 7 lines

arch/arm/kernel/head.S __create_page_tables: · line 331

Quoted 7 lines

arch/arm/kernel/head.S +1 -0

@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) ||

defined(CONFIG_MACH_OMAP_ZOOM3)

Quoted 14 lines

Quoted 13 lines

arch/arm/kernel/head.S __create_page_tables: · line 340

Quoted 9 lines

arch/arm/kernel/head.S +9 -0

+	/*
+	 * Zoom2 and Zoom3 have UARTs only on the debug board.
+	 * The debug board is connected to the GPMC.
+	 */
+	add	r0, r4, #0xfa000000 >> 18
+	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
+	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
+	str	r3, [r0]
+#endif

I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S

Quoted 5 lines

Quoted 1 line

That mapping does not cover the GPMC area where this UART is.

Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else.

Here is the problem - with current approach we need two mappings to happen and the MACHINE_START() code allows for only one via .io_pg_offset and .phys_io

Why:

Tony's approach is to pass the information about the debug uart number from the UART1 Scratchpad register.

this introduces a dependency that
UART1 registers also be mapped (virt<->phy).

So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x4800000 based mapping and for external uart zoom3 port, create this extra mapping.

Quoted 2 lines

So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem.

Ah, yet another reason to use a memory location instead of UART1 SCR to pass the UART info (c.f. [1])

Kevin

[1] http://marc.info/?l=linux-omap&m=127266219130713&w=2

Quoted 48 lines · Kevin Hilman

"Pandita, Vikram" <[email protected]> writes:

[...]

Quoted 44 lines

Quoted 22 lines

Quoted 7 lines

Quoted 7 lines

arch/arm/kernel/head.S __create_page_tables: · line 331

Quoted 7 lines

arch/arm/kernel/head.S +1 -0

@@ -328,6 +328,16 @@ __create_page_tables:
 	add	r0, r4, #0xd8000000 >> 18
 	str	r3, [r0]
 #endif
+#if defined(CONFIG_MACH_OMAP_ZOOM2) ||

defined(CONFIG_MACH_OMAP_ZOOM3)

Quoted 14 lines

Quoted 13 lines

arch/arm/kernel/head.S __create_page_tables: · line 340

Quoted 9 lines

arch/arm/kernel/head.S +9 -0

+	/*
+	 * Zoom2 and Zoom3 have UARTs only on the debug board.
+	 * The debug board is connected to the GPMC.
+	 */
+	add	r0, r4, #0xfa000000 >> 18
+	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
+	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
+	str	r3, [r0]
+#endif

I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S

Quoted 5 lines

Quoted 1 line

That mapping does not cover the GPMC area where this UART is.

Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else.

Here is the problem - with current approach we need two mappings to happen and the MACHINE_START() code allows for only one via .io_pg_offset and .phys_io

Why:

Tony's approach is to pass the information about the debug uart number from the UART1 Scratchpad register.

this introduces a dependency that
UART1 registers also be mapped (virt<->phy).

So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x4800000 based mapping and for external uart zoom3 port, create this extra mapping.

Quoted 5 lines

Quoted 2 lines

So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem.

Ah, yet another reason to use a memory location instead of UART1 SCR to pass the UART info (c.f. [1])

That should work if we don't need to access any L4 registers early on before .map_io.

Quoted 13 lines · Tony Lindgren

Quoted 11 lines · Kevin Hilman

Quoted 7 lines · Vikram

So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x4800000 based mapping and for external uart zoom3 port, create this extra mapping.

So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem.

Ah, yet another reason to use a memory location instead of UART1 SCR to pass the UART info (c.f. [1])

Quoted 2 lines

That should work if we don't need to access any L4 registers early on before .map_io.

I'd say if we're accessing L4 regs before .map_io, it's a bug that needs to be fixed, but I don't think we are. If we were, we'd notice a hang when !CONFIG_DEBUG_LL since the .phys_io and .io_pg_offst are only mapped in when CONFIG_DEBUG_LL=y.

I think we've been using .phys_io/.io_pg_offset incorrectly in OMAP as an early mapping of all the IO space, when it is intended just for use as early UART access, indicated by the comments in head.S and the fact that it's only used when CONFIG_DEBUG_LL=y

So far only tested on n900, will give it a try also on zoom3 after updating the zoom3 related patch.

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Friday, April 30, 2010 8:51 PM
To: Kevin Hilman
Cc: Pandita, Vikram; linux-arm-kernel at lists.infradead.org; linux- omap at vger.kernel.org; Pais, Allen
Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

Quoted 3 lines · Tony Lindgren

So far only tested on n900, will give it a try also on zoom3 after updating the zoom3 related patch.

And here's the updated zoom debug_ll patch, seems to work.

Quoted 11 lines

arch/arm/plat-omap/include/plat/uncompress.h +2 -0

@@ -20,27 +20,22 @@
 #include <linux/types.h>
 #include <linux/serial_reg.h>
 
+#include <asm/memory.h>
+#include <asm/io.h>
 #include <asm/mach-types.h>
 

arch/arm/plat-omap/include/plat/uncompress.h line 27

Quoted 1 line

arch/arm/plat-omap/include/plat/uncompress.h +0 -0

 #include <plat/serial.h>

BTW, the include of asm/io.h is not needed, I'll remove that.

Regards,

Tony

Quoted 12 lines

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Friday, April 30, 2010 8:51 PM
To: Kevin Hilman
Cc: Pandita, Vikram; linux-arm-kernel at lists.infradead.org; linux- omap at vger.kernel.org; Pais, Allen
Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

Quoted 1 line · Tony Lindgren

Quoted 4 lines

Quoted 2 lines

So far only tested on n900, will give it a try also on zoom3 after updating the zoom3 related patch.

And here's the updated zoom debug_ll patch, seems to work.

For testing if I put this printk hack (the good old days patch), Zoom3 does not boot after applying your patch.

So looks like we are still missing something for zoom2/3 to work. Can debug tomorrow.

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Monday, May 03, 2010 7:59 PM
To: Pandita, Vikram
Cc: Kevin Hilman; linux-arm-kernel at lists.infradead.org; linux- omap at vger.kernel.org; Pais, Allen
Subject: [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

And here's this patch one more time. Both 2a and 2b are needed for zoom debug uart to work.

Regards,

Tony

Tony

Quoted 10 lines

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Monday, May 03, 2010 7:59 PM
To: Pandita, Vikram
Cc: Kevin Hilman; linux-arm-kernel at lists.infradead.org; linux- omap at vger.kernel.org; Pais, Allen
Subject: [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

And here's this patch one more time. Both 2a and 2b are needed for zoom debug uart to work.

Test 1:
Tested on Zoom3 with 02a and 02b applied. Enabled DEBUG_LL. Booted fine.

Test 2:
Applied Hack printk.patch (attached)
Booted fine and duplicate logs can be seen on console => printascii is working.

Ack-by Vikram Pandita <[email protected]>

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Tony Lindgren
Sent: Saturday, May 01, 2010 2:04 AM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org
Subject: [PATCH 06/11] omap4: Fix omap_l2_cache_init not to run for other omaps

In multi-omap configuration all the initcalls run. To avoid bad things from happening with 44xx specific initcalls on other omaps, we need to check that the booted system is omap4 before running.

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/mach-omap2/board-4430sdp.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/board-4430sdp.c +0 -0

index b88f28c..e603b00 100644

arch/arm/mach-omap2/board-4430sdp.c +0 -0

 	/* To avoid code running on other OMAPs in
 	 * multi-omap builds
 	 */

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Tony,

Quoted 26 lines

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Tony Lindgren
Sent: Saturday, May 01, 2010 2:04 AM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org
Subject: [PATCH 06/11] omap4: Fix omap_l2_cache_init not to run for other omaps

In multi-omap configuration all the initcalls run. To avoid bad things from happening with 44xx specific initcalls on other omaps, we need to check that the booted system is omap4 before running.

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/mach-omap2/board-4430sdp.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/board-4430sdp.c +0 -0

index b88f28c..e603b00 100644
@@ -55,6 +55,9 @@ static int __init omap_l2_cache_init(void)
 	extern void omap_smc1(u32 fn, u32 arg);
 	void __iomem *l2cache_base;
 

arch/arm/mach-omap2/board-4430sdp.c static int __init omap_l2_cache_init(void) · line 60

Quoted 3 lines

arch/arm/mach-omap2/board-4430sdp.c +3 -0

+	if (!cpu_is_omap44xx())
+		return -ENODEV;
+

This check is already present just 3 lines below.

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

Quoted 3 lines · Tony Lindgren

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This one I'll drop as soon as the problem is sorted out with CONFIG_FB_OMAP.

Quoted 7 lines · Tony Lindgren

Quoted 3 lines · Tony Lindgren

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This one I'll drop as soon as the problem is sorted out with CONFIG_FB_OMAP.

This one seems to be something under drivers/video/omap, so I'll change CONFIG_FB_OMAP to be a module now. Updated patch below.

I'll update omap for-next accordingly, then Tomi can figure it out :)

Hi,

Quoted 13 lines · ext Tony Lindgren

Quoted 7 lines · Tony Lindgren

Quoted 3 lines · Tony Lindgren

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This one I'll drop as soon as the problem is sorted out with CONFIG_FB_OMAP.

This one seems to be something under drivers/video/omap, so I'll change CONFIG_FB_OMAP to be a module now. Updated patch below.

Quoted 2 lines

I'll update omap for-next accordingly, then Tomi can figure it out :)

This sounds... interesting... =) Any more info on what happens? Does it also affect new omapfb driver?

Quoted 19 lines · Tomi Valkeinen

Hi,

Quoted 15 lines · ext Tony Lindgren

Quoted 7 lines · Tony Lindgren

Quoted 3 lines · Tony Lindgren

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This one I'll drop as soon as the problem is sorted out with CONFIG_FB_OMAP.

This one seems to be something under drivers/video/omap, so I'll change CONFIG_FB_OMAP to be a module now. Updated patch below.

I'll update omap for-next accordingly, then Tomi can figure it out :)

Quoted 2 lines

This sounds... interesting... =) Any more info on what happens? Does it also affect new omapfb driver?

Yeah this is interesting, it seems like the kernel cmdline gets somehow corrupted for zoom3 with the omap3_defconfig if CONFIG_FB_OMAP=y. Some options seem to be there, but for example rootwait option is ignored and the root on MMC never mounts. This is in the current omap for-next branch.

Hmm, what do you mean with "new omapfb" driver, the stuff you have queued up?

Quoted 23 lines · ext Tony Lindgren

Quoted 21 lines · Tomi Valkeinen

Hi,

Quoted 9 lines · ext Tony Lindgren

Quoted 7 lines · Tony Lindgren

Quoted 3 lines · Tony Lindgren

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This one I'll drop as soon as the problem is sorted out with CONFIG_FB_OMAP.

Quoted 6 lines

This one seems to be something under drivers/video/omap, so I'll change CONFIG_FB_OMAP to be a module now. Updated patch below.

I'll update omap for-next accordingly, then Tomi can figure it out :)

This sounds... interesting... =) Any more info on what happens? Does it also affect new omapfb driver?

Quoted 5 lines

Yeah this is interesting, it seems like the kernel cmdline gets somehow corrupted for zoom3 with the omap3_defconfig if CONFIG_FB_OMAP=y. Some options seem to be there, but for example rootwait option is ignored and the root on MMC never mounts. This is in the current omap for-next branch.

Ok, so the cmdline parsing in omapfb could be broken. I'll check it out.

Quoted 2 lines

Hmm, what do you mean with "new omapfb" driver, the stuff you have queued up?

No, I mean the DSS2 version. drivers/video/omap is the old one, written mostly by Imre, and drivers/video/omap2 is the new one, written mostly by me.

I guess most boards are still using the old omapfb driver.

-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Friday, April 30, 2010 3:34 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org
Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This allows booting omap3_defconfig on various omaps. Tested on 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 still has issues with starting user space because of TLS and VFP.

Tony,

Quoted 9 lines

-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Friday, April 30, 2010 3:34 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org
Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig

Quoted 8 lines

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This allows booting omap3_defconfig on various omaps. Tested on 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 still has issues with starting user space because of TLS and VFP.

(Looping Tomi)

Unfortunately, your patch is uncovering an issue with old DSS code to compile it as module, which I think is caused by this:

A single omapfb.ko is attempted to be created in drivers/video/omap/ folder, but the included source files (DSS code + lcd drivers), results in multiple module_init entries added in a single module, and therefore giving errors of duplicate init_module entries between omapfb_main.c and the lcd_*.c files.

So, either you disable old DSS driver completely, or you have it as built-in.

Quoted 20 lines

Tony,

Quoted 9 lines

-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Friday, April 30, 2010 3:34 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org
Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig

Quoted 8 lines

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This allows booting omap3_defconfig on various omaps. Tested on 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 still has issues with starting user space because of TLS and VFP.

Quoted 6 lines

(Looping Tomi)

Unfortunately, your patch is uncovering an issue with old DSS code to compile it as module, which I think is caused by this:

A single omapfb.ko is attempted to be created in drivers/video/omap/

folder,

Quoted 1 line

but the included source files (DSS code + lcd drivers), results in

multiple

Quoted 1 line

module_init entries added in a single module, and therefore giving

errors of

Quoted 1 line

duplicate init_module entries between omapfb_main.c and the lcd_*.c

files.

Quoted 3 lines

So, either you disable old DSS driver completely, or you have it as built-in.

OK thanks for pointing that out. I'll disable it so we have a booting omap3_defconfig (with the modules compiling).

Regards,

Tony

Tony,

Quoted 9 lines

-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Friday, April 30, 2010 3:34 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org
Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig

Quoted 8 lines

Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed.

This allows booting omap3_defconfig on various omaps. Tested on 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 still has issues with starting user space because of TLS and VFP.

(Looping Tomi)

Unfortunately, your patch is uncovering an issue with old DSS code to compile it as module, which I think is caused by this:

A single omapfb.ko is attempted to be created in drivers/video/omap/ folder, but the included source files (DSS code + lcd drivers), results in multiple module_init entries added in a single module, and therefore giving errors of duplicate init_module entries between omapfb_main.c and the lcd_*.c files.

So, either you disable old DSS driver completely, or you have it as built-in.