Skip to contentSkip to conversation

4430SDP boot failure

PATCH New Russell King - ARM Linux 10 participants 69 messages Jan 6, 2011 – Feb 25, 2011

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37...

It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built.

Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment.

For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on.

Texas Instruments X-Loader 1.41 (Apr 19 2010 - 13:31:11) mmc read: Invalid size
Starting OS Bootloader from MMC/SD1 ...

U-Boot 1.1.4-g9e955085-dirty (Nov 19 2009 - 13:01:21)

Load address: 0x80e80000
DRAM:  512 MB
Flash:  0 kB

*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0

OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk1p2 rw mem=512M console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0
OMAP44XX SDP # fatload mmc 0 0x80300000 uImage-test
mmc read: Invalid size

1843088 bytes read
OMAP44XX SDP # bootm 80300000
## Booting image at 80300000 ...

   Image Name:   Linux-2.6.37+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1843024 Bytes =  1.8 MB

Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
X-Loader hangs

#1 lore raw

Russell King - ARM Linux had written, on 01/06/2011 11:08 AM, the following:
[..]

Quoted 2 lines

For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on.

[..]

Quoted 12 lines

1843088 bytes read
OMAP44XX SDP # bootm 80300000
## Booting image at 80300000 ...

   Image Name:   Linux-2.6.37+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1843024 Bytes =  1.8 MB

Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
OK

Quoted 4 lines

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
X-Loader hangs

http://gitorious.org/x-loader/x-loader/blobs/master/cpu/omap4/start.S#line40
I think we can improve this to provide rationale if data abort/ other causes for the hang. But in this case, I am not sure it might help - what we need to add is "boot reason" information probably. It does look to me that a reset took place (u-boot hooks up it's own handlers for irq,fiq,abort etc, but they were'nt triggered) - so either kernel abort took place and a wdt trigger caused x-loader to come up in some unexpected configuration that it could'nt handle OR a reset of somesort took place.

Signature · 2 lines
Regards,
Nishanth Menon
#2 lore raw
In reply to Russell King - ARM Linux
Quoted 16 lines · Russell King - ARM Linux

This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37...

It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built.

Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment.

Quoted 2 lines

For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on.

And another thing: turning on DEBUG in the decompressor breaks the build on OMAP:

.data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o .data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o

Is there a reason why this:

.pushsection .data

omap_uart_phys: .word   0
omap_uart_virt: .word   0
omap_uart_lsr:  .word   0

.popsection

can't be in the BSS section?

With that fixed, and a debug version of the decompressor built, when I load and run this I get the same results - without the debugging output. If I put additional debugging earlier in the decompressor, I don't see it decompressing the kernel at all.

Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port.

#3 lore raw
Quoted 3 lines · Russell King - ARM Linux

Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port.

I'm sorry, I think this crap has to go. Trying to make it fit every platform in one kernel is just too complicated. It _needs_ to be something so damned simple that it always works without fail, every single time someone wants to use it.

The current code really hasn't a hope of doing that.

Yes, that means you only configure it when you're not building a multi- platform kernel, but that's worth giving up if in return we have something that is 100% reliable.

As it is, I need to invent new debugging code to debug this mess. Sorry, I'm actually not going to bother - as the LL debug stuff was my debugging code to debug exactly these kinds of boot problems. Someone else can have the pain of sorting out this breakage, and tell me when they expect OMAP to work again.

maintainer
#4 lore raw
Quoted 16 lines · Russell King - ARM Linux
Quoted 3 lines · Russell King - ARM Linux

Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port.

I'm sorry, I think this crap has to go. Trying to make it fit every platform in one kernel is just too complicated. It _needs_ to be something so damned simple that it always works without fail, every single time someone wants to use it.

The current code really hasn't a hope of doing that.

Yes, that means you only configure it when you're not building a multi- platform kernel, but that's worth giving up if in return we have something that is 100% reliable.

Quoted 5 lines

As it is, I need to invent new debugging code to debug this mess. Sorry, I'm actually not going to bother - as the LL debug stuff was my debugging code to debug exactly these kinds of boot problems. Someone else can have the pain of sorting out this breakage, and tell me when they expect OMAP to work again.

Something that could help with the DEBUG_LL code is to pass optional debug UART info masked into the machine_id using the high bits..

Regards,

Tony

maintainer
#5 lore raw
In reply to Russell King - ARM Linux
Quoted 28 lines · Russell King - ARM Linux
Quoted 16 lines · Russell King - ARM Linux

This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37...

It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built.

Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment.

Quoted 2 lines

For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on.

And another thing: turning on DEBUG in the decompressor breaks the build on OMAP:

.data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o .data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o

Is there a reason why this:

Quoted 7 lines

.pushsection .data

omap_uart_phys: .word   0
omap_uart_virt: .word   0
omap_uart_lsr:  .word   0

.popsection

can't be in the BSS section?

BSS works too, got a patch for that?

Quoted 8 lines

With that fixed, and a debug version of the decompressor built, when I load and run this I get the same results - without the debugging output. If I put additional debugging earlier in the decompressor, I don't see it decompressing the kernel at all.

Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port.

Can you please check if you have some older bootloader that passes some wrong machine ID?

Tony

maintainer
#6 lore raw
Quoted 17 lines · Tony Lindgren
Quoted 16 lines · Russell King - ARM Linux

On Thu, Jan 06, 2011 at 05:08:05PM +0000, Russell King - ARM Linux wrote:

And another thing: turning on DEBUG in the decompressor breaks the build on OMAP:

.data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o .data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o

Is there a reason why this:

.pushsection .data

omap_uart_phys: .word   0
omap_uart_virt: .word   0
omap_uart_lsr:  .word   0

.popsection

Quoted 3 lines
Quoted 1 line

can't be in the BSS section?

BSS works too, got a patch for that?

Actually BSS won't work here, that's not initialized early enough..

But it seems that the only patch that's needed is the following. Care to give it a try?

Here's what I'm getting with this patch and DEBUG enabled for the uncompress code on my omap4 panda:

Uncompressing Linux... done, booting the kernel.

00AC3990:00000AE7:00C5187F
802C9EBC-80849D3C>80008000
80849D9C

80008000: E321F0D3 EE109F10 EB0F216F E1B0A005  0A0F217E EB0000D8 E1B08005 0A000094
80008020: EB0000E5 EB0F214B EB000004 E59FD008  E28FE000 E28AF010 EA0F213B C00083F4
80008040: E59F4204 E1A00004 E3A03000 E2806901  E4803004 E4803004 E4803004 E4803004
80008060: E1300006 1AFFFFF9 E59A7008 E28F0F7D  E8900068 E0400003 E0855000 E0866000
80008080: E1A05A25 E1A06A26 E1873A05 E7843105  E1350006 12855001 1AFFFFFA E1A0300F
800080A0: E1A03A23 E1873A03 E2840A03 E5A03000  E59F6198 E2800004 E0846926 E1500006
800080C0: E2833601 94803004 9AFFFFFB E2840A03  E3876102 E5806000 EE117F10 E3170001
800080E0: 059F716C 159F716C E2873004 E5977000  E5933000 E3570000 13530000 1A000043
[    0.000000] Linux version 2.6.37-00001-g98859f0-dirty (tmlind@baageli) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #468 SMP Thu Jan 6 11:46:09 PST 2011
[    0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: OMAP4 Panda board
[    0.000000] bootconsole [earlycon0] enabled

...

Regards,

Tony

From: Tony Lindgren <[email protected]>
Date: Thu, 6 Jan 2011 11:29:39 -0800
Subject: [PATCH] ARM: Fix low-level decompress debug code for omap

If DEBUG is enabled for decompress code, the system will hang as the debug UART is not specified. Fix this by adding the necessary code for omap2plus.

Note that this won't work properly with multi-omap support compiled in. Also the debug UART used needs to be patched in if not omap UART3.

arch/arm/boot/compressed/head.S +17 -0
@@ -71,6 +71,23 @@ wait:		mrc	p14, 0, pc, c0, c1, 0
 		mov	\rb, #0x50000000
 		add	\rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
 		.endm
+#elif defined(CONFIG_ARCH_OMAP2PLUS)
+#include <plat/multi.h>
+#ifdef MULTI_OMAP2)
+#error Low-level uncompress debug code won't work with multi-omap
+#elif defined(CONFIG_ARCH_OMAP2)
+		.macro loadsp, rb, tmp
+		ldr	\rb, =OMAP2_UART3_BASE	/* patch accordingly */
+		.endm
+#elif defined(CONFIG_ARCH_OMAP3)
+		.macro loadsp, rb, tmp
+		ldr	\rb, =OMAP3_UART3_BASE	/* patch accordingly */
+		.endm
+#elif defined(CONFIG_ARCH_OMAP4)
+		.macro loadsp, rb, tmp
+		ldr	\rb, =OMAP4_UART3_BASE	/* patch accordingly */
+		.endm
+#endif
 #else
 		.macro	loadsp,	rb, tmp
 		addruart \rb, \tmp
maintainer
#7 lore raw

arch/arm/boot/compressed/head.S wait: mrc p14, 0, pc, c0, c1, 0 · line 76

Quoted 9 lines · Tony Lindgren
arch/arm/boot/compressed/head.S +3 -0
@@ -71,6 +71,23 @@ wait:		mrc	p14, 0, pc, c0, c1, 0
 		mov	\rb, #0x50000000
 		add	\rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
 		.endm
+#elif defined(CONFIG_ARCH_OMAP2PLUS)
+#include <plat/multi.h>
+#ifdef MULTI_OMAP2)
                     ^

Looks like my last change to this patch from if defined to ifdef broke the warning above with an unbalanced bracket..

Thanks Nishant for catching that, updated patch below.

Regards,

Tony

From: Tony Lindgren <[email protected]>
Date: Thu, 6 Jan 2011 11:29:39 -0800
Subject: [PATCH] ARM: Fix low-level decompress debug code for omap

If DEBUG is enabled for decompress code, the system will hang as the debug UART is not specified. Fix this by adding the necessary code for omap2plus.

Note that this won't work properly with multi-omap support compiled in. Also the debug UART used needs to be patched in if not omap UART3.

arch/arm/boot/compressed/head.S +17 -0
@@ -71,6 +71,23 @@ wait:		mrc	p14, 0, pc, c0, c1, 0
 		mov	\rb, #0x50000000
 		add	\rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
 		.endm
+#elif defined(CONFIG_ARCH_OMAP2PLUS)
+#include <plat/multi.h>
+#ifdef MULTI_OMAP2
+#error Low-level uncompress debug code won't work with multi-omap
+#elif defined(CONFIG_ARCH_OMAP2)
+		.macro loadsp, rb, tmp
+		ldr	\rb, =OMAP2_UART3_BASE	/* patch accordingly */
+		.endm
+#elif defined(CONFIG_ARCH_OMAP3)
+		.macro loadsp, rb, tmp
+		ldr	\rb, =OMAP3_UART3_BASE	/* patch accordingly */
+		.endm
+#elif defined(CONFIG_ARCH_OMAP4)
+		.macro loadsp, rb, tmp
+		ldr	\rb, =OMAP4_UART3_BASE	/* patch accordingly */
+		.endm
+#endif
 #else
 		.macro	loadsp,	rb, tmp
 		addruart \rb, \tmp
#8 lore raw
Quoted 11 lines · Tony Lindgren

arch/arm/boot/compressed/head.S wait: mrc p14, 0, pc, c0, c1, 0 · line 76

Quoted 9 lines · Tony Lindgren
arch/arm/boot/compressed/head.S +3 -0
@@ -71,6 +71,23 @@ wait:		mrc	p14, 0, pc, c0, c1, 0
 		mov	\rb, #0x50000000
 		add	\rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
 		.endm
+#elif defined(CONFIG_ARCH_OMAP2PLUS)
+#include <plat/multi.h>
+#ifdef MULTI_OMAP2)
                     ^
Quoted 4 lines

Looks like my last change to this patch from if defined to ifdef broke the warning above with an unbalanced bracket..

Thanks Nishant for catching that, updated patch below.

Just tried that patch, but I now have bigger problems:

OMAP44XX SDP # mmcinit 0
OMAP44XX SDP # fatload mmc 0 0x80300000 uImage-test

0 bytes read
OMAP44XX SDP #

God knows why it's doing this now, as the file is present on the SD card:

-rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 20:35 uImage-test

is what's on the SD card - with no FAT errors:

$ fsck.msdos /dev/mmcblk0p1
dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
/dev/mmcblk0p1: 8 files, 10249/142266 clusters

The file's not corrupt either:

$ md5sum /media/boot/uImage-test
be3edd928f1dbb3c15215b1a8a62fa1f  /media/boot/uImage-test
$ md5sum ../build/omap4/arch/arm/boot/uImage
be3edd928f1dbb3c15215b1a8a62fa1f  ../build/omap4/arch/arm/boot/uImage

Nope, still won't work:

OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0
OMAP44XX SDP # fatload mmc 0 0x80300000 uImage-test

0 bytes read
OMAP44XX SDP #

However, it can still boot the uImage contained on the SD card, so the card must be okay, and the SDP must still be able to successfully read from the card. I can only assume that uboot's FAT support is buggered in some way.

We _really_ need a _decent_ boot loader on these boards, one which can do network booting _and_ can be configured to do so from bootup. SD cards just don't hack it for kernel development. It's a far too long- winded process for each cycle, and with all the additional problems (such as SD cards not being recognised 50% of the time, FAT filesystem bugs in boot loaders, etc) it's really not funny.

So, I give up at this point with the OMAP4430SDP board. It's not worth spending the time with this kind of unreliability.

#9 lore raw
Quoted 9 lines · Russell King - ARM Linux

We _really_ need a _decent_ boot loader on these boards, one which can do network booting _and_ can be configured to do so from bootup. SD cards just don't hack it for kernel development. It's a far too long- winded process for each cycle, and with all the additional problems (such as SD cards not being recognised 50% of the time, FAT filesystem bugs in boot loaders, etc) it's really not funny.

So, I give up at this point with the OMAP4430SDP board. It's not worth spending the time with this kind of unreliability.

To top it off, the crappy 3rd party ftdi_sio driver I have to use for the SDP board just oopsed my x86 kernel. Do you get the impression that if something can go wrong, it will go wrong...

I think I'll leave the 4430SDP alone until I have more patience for it. I might see about setting up the ARM Realview platform as a remote terminal for the 4430SDP so at least these kinds of crashes don't take out my work machine.

#10 lore raw
In reply to Russell King - ARM Linux
Quoted 64 lines · Russell King - ARM Linux
Quoted 11 lines · Tony Lindgren

arch/arm/boot/compressed/head.S wait: mrc p14, 0, pc, c0, c1, 0 · line 76

Quoted 9 lines · Tony Lindgren
arch/arm/boot/compressed/head.S +3 -0
@@ -71,6 +71,23 @@ wait:		mrc	p14, 0, pc, c0, c1, 0
 		mov	\rb, #0x50000000
 		add	\rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
 		.endm
+#elif defined(CONFIG_ARCH_OMAP2PLUS)
+#include <plat/multi.h>
+#ifdef MULTI_OMAP2)
                     ^
Quoted 4 lines

Looks like my last change to this patch from if defined to ifdef broke the warning above with an unbalanced bracket..

Thanks Nishant for catching that, updated patch below.

Just tried that patch, but I now have bigger problems:

OMAP44XX SDP # mmcinit 0
OMAP44XX SDP # fatload mmc 0 0x80300000 uImage-test

0 bytes read
OMAP44XX SDP #

God knows why it's doing this now, as the file is present on the SD card:

-rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 20:35 uImage-test

is what's on the SD card - with no FAT errors:

$ fsck.msdos /dev/mmcblk0p1
dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
/dev/mmcblk0p1: 8 files, 10249/142266 clusters

The file's not corrupt either:

$ md5sum /media/boot/uImage-test
be3edd928f1dbb3c15215b1a8a62fa1f  /media/boot/uImage-test
$ md5sum ../build/omap4/arch/arm/boot/uImage
be3edd928f1dbb3c15215b1a8a62fa1f  ../build/omap4/arch/arm/boot/uImage

Nope, still won't work:

OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0
OMAP44XX SDP # fatload mmc 0 0x80300000 uImage-test

0 bytes read
OMAP44XX SDP #

However, it can still boot the uImage contained on the SD card, so the card must be okay, and the SDP must still be able to successfully read from the card. I can only assume that uboot's FAT support is buggered in some way.

We _really_ need a _decent_ boot loader on these boards, one which can do network booting _and_ can be configured to do so from bootup. SD cards just don't hack it for kernel development. It's a far too long- winded process for each cycle, and with all the additional problems (such as SD cards not being recognised 50% of the time, FAT filesystem bugs in boot loaders, etc) it's really not funny.

Quoted 2 lines

So, I give up at this point with the OMAP4430SDP board. It's not worth spending the time with this kind of unreliability.

OMAP44XX SDP # fatls mmc 0

  1935000   uimage
   149104   u-boot.bin
    18984   mlo
  1836636   uimage-test
  1130288   uimage-ss
    19040   mlo.old

Invalid FAT entry

6 file(s), 0 dir(s)

"Invalid FAT entry" ? I don't think so. The thing actually contains:

-rwxr-xr-x. 1 rmk rmk 1935000 Feb  4  2010 uImage
-rwxr-xr-x. 1 rmk rmk  149104 Feb  4  2010 u-boot.bin
-rwxr-xr-x. 1 rmk rmk   18984 Jan  1  2000 mlo
-rwxr-xr-x. 1 rmk rmk 1836636 Jan  6 21:35 uImage-test
-rwxr-xr-x. 1 rmk rmk 1130288 Jan  1  2000 uImage-ss
-rwxr-xr-x. 1 rmk rmk   19040 Feb  4  2010 mlo.old
-rwxr-xr-x. 1 rmk rmk  154904 Jan  1  2000 u-boot.new

The hexdump of the directory on the SD card is:

0011a000  62 6f 6f 74 20 20 20 20  20 20 20 08 00 00 87 b6  |boot       .....|
0011a010  3e 3c 3e 3c 00 00 87 b6  3e 3c 00 00 00 00 00 00  |><><....><......|
0011a020  41 75 00 49 00 6d 00 61  00 67 00 0f 00 46 65 00  |Au.I.m.a.g...Fe.|
0011a030  00 00 ff ff ff ff ff ff  ff ff 00 00 ff ff ff ff  |................|
0011a040  55 49 4d 41 47 45 20 20  20 20 20 20 00 64 6d 65  |UIMAGE      .dme|
0011a050  44 3c 26 3e 00 00 6d 65  44 3c 4a 0e 98 86 1d 00  |D<&>..meD<J.....|
0011a060  41 75 00 2d 00 62 00 6f  00 6f 00 0f 00 30 74 00  |Au.-.b.o.o...0t.|
0011a070  2e 00 62 00 69 00 6e 00  00 00 00 00 ff ff ff ff  |..b.i.n.........|
0011a080  55 2d 42 4f 4f 54 20 20  42 49 4e 20 00 64 6f 65  |U-BOOT  BIN .doe|
0011a090  44 3c bc 3c 00 00 6f 65  44 3c 0e 1d 70 46 02 00  |D<.<..oeD<..pF..|
0011a0a0  41 6d 00 6c 00 6f 00 00  00 ff ff 0f 00 c8 ff ff  |Am.l.o..........|
0011a0b0  ff ff ff ff ff ff ff ff  ff ff 00 00 ff ff ff ff  |................|
0011a0c0  4d 4c 4f 20 20 20 20 20  20 20 20 20 00 00 28 00  |MLO         ..(.|
0011a0d0  21 28 26 3e 00 00 28 00  21 28 21 2d 28 4a 00 00  |!(&>..(.!(!-(J..|
0011a0e0  41 75 00 49 00 6d 00 61  00 67 00 0f 00 4e 65 00  |Au.I.m.a.g...Ne.|
0011a0f0  2d 00 74 00 65 00 73 00  74 00 00 00 00 00 ff ff  |-.t.e.s.t.......|
0011a100  55 49 4d 41 47 45 7e 31  20 20 20 20 00 64 7b ac  |UIMAGE~1    .d{.|
0011a110  26 3e 26 3e 00 00 7b ac  26 3e ce fb 5c 06 1c 00  |&>&>..{.&>..\...|
0011a120  e5 75 00 2d 00 62 00 6f  00 6f 00 0f 00 14 74 00  |.u.-.b.o.o....t.|
0011a130  2e 00 42 00 49 00 32 00  00 00 00 00 ff ff ff ff  |..B.I.2.........|
0011a140  e5 2d 42 4f 4f 54 20 20  42 49 32 20 00 64 6f 65  |.-BOOT  BI2 .doe|
0011a150  44 3c bc 3c 00 00 6f 65  44 3c 0e 1d 70 46 02 00  |D<.<..oeD<..pF..|
0011a160  41 75 00 49 00 6d 00 61  00 67 00 0f 00 6e 65 00  |Au.I.m.a.g...ne.|
0011a170  2d 00 73 00 73 00 00 00  ff ff 00 00 ff ff ff ff  |-.s.s...........|
0011a180  55 49 4d 41 47 45 7e 32  20 20 20 20 00 64 bb 00  |UIMAGE~2    .d..|
0011a190  21 28 26 3e 00 00 bb 00  21 28 76 2e 30 3f 11 00  |!(&>....!(v.0?..|
0011a1a0  41 6d 00 6c 00 6f 00 2e  00 6f 00 0f 00 4e 6c 00  |Am.l.o...o...Nl.|
0011a1b0  64 00 00 00 ff ff ff ff  ff ff 00 00 ff ff ff ff  |d...............|
0011a1c0  4d 4c 4f 20 20 20 20 20  4f 4c 44 20 00 64 73 65  |MLO     OLD .dse|
0011a1d0  44 3c 6a 3c 00 00 73 65  44 3c 32 1e 60 4a 00 00  |D<j<..seD<2.`J..|
0011a1e0  41 75 00 2d 00 62 00 6f  00 6f 00 0f 00 fa 74 00  |Au.-.b.o.o....t.|
0011a1f0  2e 00 6e 00 65 00 77 00  00 00 00 00 ff ff ff ff  |..n.e.w.........|

... and the directory continues in a different sector ...

00a29200  55 2d 42 4f 4f 54 20 20  4e 45 57 20 00 00 3d 00  |U-BOOT  NEW ..=.|
00a29210  21 28 26 3e 00 00 3d 00  21 28 47 2d 18 5d 02 00  |!(&>..=.!(G-.]..|
00a29220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The relevant parts of the FAT table are:

00004000 f8 ff ff 0f ff ff ff 0f 7b 48 00 00 00 00 00 00 |........{H......|
^^^^^ entry linking to next root-dir sector
...
000161e0 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff 0f |................|

                                               ^^^^^^^^^^^ terminator

Cluster 2 = root dir start.
Cluster 2 image address = 0x119c00 + 2 * 0x200 = 0x11a000. Cluster 2 FAT address = 0x4000 + 2 * 4 = 0x4008. Following cluster = 0x487b.
Cluster 0x487b image address = 0x119c00 + 0x487b * 0x200 = 0xa29200 Cluster 0x487b FAT address = 0x4000 + 0x487b * 4 = 0x161ec. Following cluster = 0x0fffffff = FAT-32 EOF.

So, uboot's FAT code can't deal with a directory larger than one sector that doesn't continue. While we're here, lets confirm by hand that there's nothing wrong with the uImage-test file and it's yet again uboot being idiotic.

The directory entry for loading my uImage-test file is:

0011a0e0  41 75 00 49 00 6d 00 61  00 67 00 0f 00 4e 65 00  |Au.I.m.a.g...Ne.|
0011a0f0  2d 00 74 00 65 00 73 00  74 00 00 00 00 00 ff ff  |-.t.e.s.t.......|
0011a100  55 49 4d 41 47 45 7e 31  20 20 20 20 00 64 7b ac  |UIMAGE~1    .d{.|
0011a110  26 3e 26 3e 00 00 7b ac  26 3e ce fb 5c 06 1c 00  |&>&>..{.&>..\...|

Decoding this entry gives:
creation time = 0xac7b
creation date = 0x3e26
access date = 0x3e26
time = 0xac7b
date = 0x3e26
start cluster = 0x0000fbce
size = 0x001c065c (1836636 bytes)

Cluster 0xfbce = image address 0x119c00 + 0xfbce*0x200 = 0x2093800:
Cluster 0xfbce FAT entry address = 0x4000 + 0xfbce * 4 = 0x42f38

00042f30  00 00 00 00 00 00 00 00  cf fb 00 00 d0 fb 00 00  |................|
00042f40  d1 fb 00 00 d2 fb 00 00  d3 fb 00 00 d4 fb 00 00  |................|

Next cluster = 0xfbcf, then 0xfbd0 and so on.

The data on the SD card for this file:

02093800  27 05 19 56 76 ed 63 cb  4d 26 27 76 00 1c 06 1c  |'..Vv.c.M&'v....|
02093810  80 00 80 00 80 00 80 00  ad 09 bd ce 05 02 02 00  |................|
02093820  4c 69 6e 75 78 2d 32 2e  36 2e 33 37 2b 00 00 00  |Linux-2.6.37+...|
02093830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
02093840  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|
*
02093860  02 00 00 ea 18 28 6f 01  00 00 00 00 1c 06 1c 00  |.....(o.........|
02093870  01 70 a0 e1 02 80 a0 e1  00 20 0f e1 03 00 12 e3  |.p....... ......|
02093880  01 00 00 1a 17 00 a0 e3  56 34 12 ef 00 20 0f e1  |........V4... ..|

and the corresponding version from my build tree:

00000000  27 05 19 56 76 ed 63 cb  4d 26 27 76 00 1c 06 1c  |'..Vv.c.M&'v....|
00000010  80 00 80 00 80 00 80 00  ad 09 bd ce 05 02 02 00  |................|
00000020  4c 69 6e 75 78 2d 32 2e  36 2e 33 37 2b 00 00 00  |Linux-2.6.37+...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|
*
00000060  02 00 00 ea 18 28 6f 01  00 00 00 00 1c 06 1c 00  |.....(o.........|
00000070  01 70 a0 e1 02 80 a0 e1  00 20 0f e1 03 00 12 e3  |.p....... ......|
00000080  01 00 00 1a 17 00 a0 e3  56 34 12 ef 00 20 0f e1  |........V4... ..|

matches. So there's no problem here with the filesystem itself - it's just uboot not parsing the FAT filesystem correctly. I *really* want to throw this version of uboot in the circular filing cabinet now.

Can we _please_ have a version of uboot for the SDP4430 platform which can be configured at runtime _and_ which is capable of DHCP/TFTP ? I really don't want to mess about anymore with buggy boot loaders.

maintainer
#11 lore raw
Quoted 6 lines · Russell King - ARM Linux
Quoted 5 lines · Russell King - ARM Linux

OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0
OMAP44XX SDP # fatload mmc 0 0x80300000 uImage-test

Quoted 7 lines
Quoted 7 lines

0 bytes read
OMAP44XX SDP #

However, it can still boot the uImage contained on the SD card, so the card must be okay, and the SDP must still be able to successfully read from the card. I can only assume that uboot's FAT support is buggered in some way.

Sorry no idea about this problem, have not seen it myself.

Quoted 6 lines
Quoted 6 lines

We _really_ need a _decent_ boot loader on these boards, one which can do network booting _and_ can be configured to do so from bootup. SD cards just don't hack it for kernel development. It's a far too long- winded process for each cycle, and with all the additional problems (such as SD cards not being recognised 50% of the time, FAT filesystem bugs in boot loaders, etc) it's really not funny.

I totally agree. Flipping micro-SD cards for development is no fun.

Regards,

Tony

#12 lore raw
In reply to Russell King - ARM Linux
Quoted 6 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 5:22 AM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

[..]

Quoted 25 lines

OMAP44XX SDP # fatls mmc 0

  1935000   uimage
   149104   u-boot.bin
    18984   mlo
  1836636   uimage-test
  1130288   uimage-ss
    19040   mlo.old

Invalid FAT entry

6 file(s), 0 dir(s)

"Invalid FAT entry" ? I don't think so. The thing actually contains:

(quoted diff) +0 -7
-rwxr-xr-x. 1 rmk rmk 1935000 Feb  4  2010 uImage
-rwxr-xr-x. 1 rmk rmk  149104 Feb  4  2010 u-boot.bin
-rwxr-xr-x. 1 rmk rmk   18984 Jan  1  2000 mlo
-rwxr-xr-x. 1 rmk rmk 1836636 Jan  6 21:35 uImage-test
-rwxr-xr-x. 1 rmk rmk 1130288 Jan  1  2000 uImage-ss
-rwxr-xr-x. 1 rmk rmk   19040 Feb  4  2010 mlo.old
-rwxr-xr-x. 1 rmk rmk  154904 Jan  1  2000 u-boot.new

[..]

Quoted 7 lines

So, uboot's FAT code can't deal with a directory larger than one sector
that doesn't continue. While we're here, lets confirm by hand that there's nothing wrong with the uImage-test file and it's yet again uboot
being idiotic.

[..]

Quoted 4 lines

Can we _please_ have a version of uboot for the SDP4430 platform which
can be configured at runtime _and_ which is capable of DHCP/TFTP ? I really don't want to mess about anymore with buggy boot loaders.

Just read this thread. Looks like you are not able to boot the kernel at all. 2.6.37 + Tony's queue booted for me without any issues.

I can give a try on 2.6.37.

TFTP is already supported on the latest bootloaders.
http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=shortlog;h=refs/heads/o
map4_dev

Will send you binaries in another email.

Regards

Santosh

#13 lore raw
Quoted 6 lines · Santosh Shilimkar
Quoted 4 lines

Can we _please_ have a version of uboot for the SDP4430 platform which
can be configured at runtime _and_ which is capable of DHCP/TFTP ? I really don't want to mess about anymore with buggy boot loaders.

Just read this thread. Looks like you are not able to boot the kernel at all. 2.6.37 + Tony's queue booted for me without any issues.

I can only boot older kernels. I can't debug later kernels because as soon as I access the UART, I get this very bland 'X-loader hangs' message which is no help what so ever (for the amount of use it is, it might as well not even print that.)

I don't know whether that's because I'm doing something wrong or what as there's no way to get any diagnostics out of the system.

The u-boot SD card issues are just another layer of timewasting frustration which really doesn't help. I don't want to spend many hours debugging the boot loader because it also doesn't work properly. I want something which works every time without fail.

BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board.

#14 lore raw
Quoted 24 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 2:58 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 3 lines · Santosh Shilimkar
Quoted 3 lines

Can we _please_ have a version of uboot for the SDP4430 platform which
can be configured at runtime _and_ which is capable of DHCP/TFTP

?

Quoted 1 line
Quoted 1 line

I really don't want to mess about anymore with buggy boot

loaders.

Quoted 1 line

Just read this thread. Looks like you are not able to boot the

kernel

Quoted 1 line

at all. 2.6.37 + Tony's queue booted for me without any issues.

I can only boot older kernels. I can't debug later kernels because as soon as I access the UART, I get this very bland 'X-loader hangs' message which is no help what so ever (for the amount of use it is, it
might as well not even print that.)

Quoted 4 lines

I don't know whether that's because I'm doing something wrong or what as
there's no way to get any diagnostics out of the system.

Ok. Will try 2.6.37 major version.

Quoted 11 lines

The u-boot SD card issues are just another layer of timewasting frustration
which really doesn't help. I don't want to spend many hours debugging
the boot loader because it also doesn't work properly. I want something
which works every time without fail.

BTW, if it makes any difference to the boot loader, please note that I'm
still waiting for the upgrade for the SDP board.

That means your board is with ES1.0. I shall try 2.6.37 on ES1.0

#15 lore raw
Quoted 3 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:[email protected]]
Sent: Friday, January 07, 2011 3:23 PM

Ruessell,

Quoted 4 lines

To: Russell King - ARM Linux
Cc: [email protected]; Tony Lindgren
Subject: RE: 4430SDP boot failure

[....]

Quoted 6 lines
Quoted 1 line

BTW, if it makes any difference to the boot loader, please note

that

Quoted 2 lines

I'm
still waiting for the upgrade for the SDP board.

That means your board is with ES1.0. I shall try 2.6.37 on ES1.0

ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver.

Can you try "console=ttyO2" instead of existing ""console=ttyS2" ??

Will send you the latest boot-loader after doing a boot test.

----------------------------------------
## Booting image at 80300000 ...

   Image Name:   Linux-2.6.37
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2898440 Bytes =  2.8 MB

Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

[    0.000000] Linux version 2.6.37 (a0393909@a0393909-desktop) (gcc
version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #6 SMP Fri Jan 7 17:12:26
IST 2011
[    0.000000] CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7),
cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction
cache
[    0.000000] Machine: OMAP4430 4430SDP board
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] OMAP4430 ES1.0
[    0.000000] SRAM: Mapped pa 0x40300000 to va 0xfe400000 size: 0xe000
[    0.000000] FIXME: omap44xx_sram_init not implemented
[    0.000000] PERCPU: Embedded 7 pages/cpu @c0f3d000 s6080 r8192 d14400
u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 130048
[    0.000000] Kernel command line: console=ttyO2,115200n8 noinitrd
root=/dev/nfs rw
nfsroot=172.24.190.46:/ubuntu/nfs-share/omap4_next/,nolock,tcp,rsize=1024,
wsize=1024 ip=dhcp
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[    0.000000] Memory: 512MB = 512MB total
[    0.000000] Memory: 508228k/508228k available, 16060k reserved, 0K
highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
[    0.000000]     vmalloc : 0xe0800000 - 0xf8000000   ( 376 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .init : 0xc0008000 - 0xc004a000   ( 264 kB)
[    0.000000]       .text : 0xc004a000 - 0xc056904c   (5245 kB)
[    0.000000]       .data : 0xc056a000 - 0xc05dadc0   ( 452 kB)
[    0.000000] Hierarchical RCU implementation.
#16 lore raw

Sorry,

Quoted 24 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:[email protected]]
Sent: Friday, January 07, 2011 5:49 PM
To: Russell King - ARM Linux
Cc: [email protected]; Tony Lindgren
Subject: RE: 4430SDP boot failure

Quoted 3 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:[email protected]]
Sent: Friday, January 07, 2011 3:23 PM

Ruessell,

Quoted 4 lines

To: Russell King - ARM Linux
Cc: [email protected]; Tony Lindgren
Subject: RE: 4430SDP boot failure

[....]

Quoted 4 lines
Quoted 1 line

BTW, if it makes any difference to the boot loader, please note

that

Quoted 2 lines

I'm
still waiting for the upgrade for the SDP board.

Quoted 9 lines
Quoted 2 lines

That means your board is with ES1.0. I shall try 2.6.37 on ES1.0

ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver.

Can you try "console=ttyO2" instead of existing ""console=ttyS2" ??

Ignore my last email. You have tried that already Will send you updated boot-loaders in next few mins.

#17 lore raw
In reply to Santosh Shilimkar
Quoted 17 lines · Santosh Shilimkar
Quoted 3 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:[email protected]]
Sent: Friday, January 07, 2011 3:23 PM

Ruessell,

Quoted 4 lines

To: Russell King - ARM Linux
Cc: [email protected]; Tony Lindgren
Subject: RE: 4430SDP boot failure

[....]

Quoted 4 lines
Quoted 1 line

BTW, if it makes any difference to the boot loader, please note

that

Quoted 2 lines

I'm
still waiting for the upgrade for the SDP board.

Quoted 8 lines
Quoted 2 lines

That means your board is with ES1.0. I shall try 2.6.37 on ES1.0

ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver.

Can you try "console=ttyO2" instead of existing ""console=ttyS2" ??

This is the command line I've been giving it:

setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2'

and in my .config, I have:

CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y

so the driver is also enabled. I found this on the 3430LDP, and so switched both OMAP3 and OMAP4 stuff over to the new driver.

That wouldn't explain why I'm getting the "X-loader hangs" message which brings everything to a halt, and why the low level debug stuff doesn't work.

#18 lore raw
Quoted 39 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 6:22 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 6 lines · Santosh Shilimkar
Quoted 3 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:[email protected]]
Sent: Friday, January 07, 2011 3:23 PM

Ruessell,

Quoted 8 lines
Quoted 4 lines

To: Russell King - ARM Linux
Cc: [email protected]; Tony Lindgren
Subject: RE: 4430SDP boot failure

[....]

Quoted 1 line
Quoted 1 line

BTW, if it makes any difference to the boot loader, please

note

Quoted 7 lines
Quoted 5 lines

that

Quoted 2 lines

I'm
still waiting for the upgrade for the SDP board.

That means your board is with ES1.0. I shall try 2.6.37 on ES1.0

ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing

an

Quoted 4 lines

issue. The console is changed to OMAP serial driver from 8250 driver.

Can you try "console=ttyO2" instead of existing ""console=ttyS2"

??

This is the command line I've been giving it:

Quoted 8 lines

setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2'

and in my .config, I have:

CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y

Yep. Noticed that after the post.

Quoted 6 lines

so the driver is also enabled. I found this on the 3430LDP, and so switched both OMAP3 and OMAP4 stuff over to the new driver.

That wouldn't explain why I'm getting the "X-loader hangs" message which brings everything to a halt, and why the low level debug stuff doesn't work.

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Low level debug as you reported seems to be broken though.

Regards,
Santosh

#19 lore raw
Quoted 4 lines · Santosh Shilimkar

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel.

#20 lore raw
Quoted 8 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:

Quoted 8 lines
Quoted 4 lines

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel.

Glad to hear that.

Regards,
Santosh

#21 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 11 lines · Santosh Shilimkar
Quoted 11 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 3 lines · Santosh Shilimkar

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel.

Glad to hear that.

And, with one ARM errata disabled, the kernel finally boots. So the "X-Loader hangs" message means that we did something that non-secure mode prevented us from doing.

It would be a good idea if X-loader could tell dump out the exception, register dump, and for data/prefetch aborts, the relevent FSR and FAR registers - that would make debugging this kind of failure a lot easier.

=================
Subject: Fix DMA API usage in OMAP MCSPI driver

Running the latest kernel on the 4430SDP board with DMA API debugging enabled results in this:

WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated
[device address=0x000000008129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[<c003cbe0>] (dump_backtrace+0x0/0x10c) from [<c0278da8>] (dump_stack+0x18/0x1c)
 r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:00000323
[<c0278d90>] (dump_stack+0x0/0x1c) from [<c005b158>] (warn_slowpath_common+0x58/0x70)
[<c005b100>] (warn_slowpath_common+0x0/0x70) from [<c005b214>] (warn_slowpath_fmt+0x38/0x40)
 r8:c1839e40 r7:00000000 r6:00000104 r5:00000000 r4:8129901a
[<c005b1dc>] (warn_slowpath_fmt+0x0/0x40) from [<c0198578>] (check_unmap+0x19c/0x6f0)
 r3:c03110de r2:c0304e6b
[<c01983dc>] (check_unmap+0x0/0x6f0) from [<c0198cd8>] (debug_dma_unmap_page+0x74/0x80)
[<c0198c64>] (debug_dma_unmap_page+0x0/0x80) from [<c01d5ad8>] (omap2_mcspi_work+0x514/0xbf0)
[<c01d55c4>] (omap2_mcspi_work+0x0/0xbf0) from [<c006dfb0>] (process_one_work+0x294/0x400)
[<c006dd1c>] (process_one_work+0x0/0x400) from [<c006e50c>] (worker_thread+0x220/0x3f8)
[<c006e2ec>] (worker_thread+0x0/0x3f8) from [<c00738d0>] (kthread+0x88/0x90)
[<c0073848>] (kthread+0x0/0x90) from [<c005e924>] (do_exit+0x0/0x5fc)
 r7:00000013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---

I've no idea why this driver uses NULL for dma_unmap_single instead of the &spi->dev that is laying around just waiting to be used in that function - but it's an easy fix.

Also replace this comment with a FIXME comment:
/* Do DMA mapping "early" for better error reporting and
* dcache use. Note that if dma_unmap_single() ever starts
* to do real work on ARM, we'd need to clean up mappings
* for previous transfers on *ALL* exits of this loop... */
as the comment is not true - we do work in dma_unmap() functions, particularly on ARMv6 and above. I've corrected the existing unmap functions but if any others are required they must be added ASAP.

---
I'm surprised this driver got merged as it has such a comment, and is abusing the DMA API... well, at least with the DMA API debugging we can now catch this stuff.

drivers/spi/omap2_mcspi.c +3 -8
index 951a160..abb1ffb 100644
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
 
 	if (tx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_tx_completion);
-		dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
 
 		/* for TX_ONLY mode, be sure all words have shifted out */
 		if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
 
 	if (rx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_rx_completion);
-		dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->rx_dma, count, DMA_FROM_DEVICE);
 		omap2_mcspi_set_enable(spi, 0);
 
 		if (l & OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi, struct spi_message *m)
 		if (m->is_dma_mapped || len < DMA_MIN_BYTES)
 			continue;
 
-		/* Do DMA mapping "early" for better error reporting and
-		 * dcache use.  Note that if dma_unmap_single() ever starts
-		 * to do real work on ARM, we'd need to clean up mappings
-		 * for previous transfers on *ALL* exits of this loop...
-		 */
 		if (tx_buf != NULL) {
 			t->tx_dma = dma_map_single(&spi->dev, (void *) tx_buf,
 					len, DMA_TO_DEVICE);
@@ -1046,7 +1041,7 @@ static int omap2_mcspi_transfer(struct spi_device *spi, struct spi_message *m)
 				dev_dbg(&spi->dev, "dma %cX %d bytes error\n",
 						'R', len);
 				if (tx_buf != NULL)
-					dma_unmap_single(NULL, t->tx_dma,
+					dma_unmap_single(&spi->dev, t->tx_dma,
 							len, DMA_TO_DEVICE);
 				return -EINVAL;
 			}
maintainer Acked-by
#22 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

Grant,

Care to queue or ack the following fix?

Quoted 70 lines · Russell King - ARM Linux
Quoted 11 lines · Santosh Shilimkar
Quoted 11 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 3 lines · Santosh Shilimkar

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel.

Glad to hear that.

And, with one ARM errata disabled, the kernel finally boots. So the "X-Loader hangs" message means that we did something that non-secure mode prevented us from doing.

It would be a good idea if X-loader could tell dump out the exception, register dump, and for data/prefetch aborts, the relevent FSR and FAR registers - that would make debugging this kind of failure a lot easier.

=================
Subject: Fix DMA API usage in OMAP MCSPI driver

Running the latest kernel on the 4430SDP board with DMA API debugging enabled results in this:

WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated
[device address=0x000000008129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[<c003cbe0>] (dump_backtrace+0x0/0x10c) from [<c0278da8>] (dump_stack+0x18/0x1c)
 r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:00000323
[<c0278d90>] (dump_stack+0x0/0x1c) from [<c005b158>] (warn_slowpath_common+0x58/0x70)
[<c005b100>] (warn_slowpath_common+0x0/0x70) from [<c005b214>] (warn_slowpath_fmt+0x38/0x40)
 r8:c1839e40 r7:00000000 r6:00000104 r5:00000000 r4:8129901a
[<c005b1dc>] (warn_slowpath_fmt+0x0/0x40) from [<c0198578>] (check_unmap+0x19c/0x6f0)
 r3:c03110de r2:c0304e6b
[<c01983dc>] (check_unmap+0x0/0x6f0) from [<c0198cd8>] (debug_dma_unmap_page+0x74/0x80)
[<c0198c64>] (debug_dma_unmap_page+0x0/0x80) from [<c01d5ad8>] (omap2_mcspi_work+0x514/0xbf0)
[<c01d55c4>] (omap2_mcspi_work+0x0/0xbf0) from [<c006dfb0>] (process_one_work+0x294/0x400)
[<c006dd1c>] (process_one_work+0x0/0x400) from [<c006e50c>] (worker_thread+0x220/0x3f8)
[<c006e2ec>] (worker_thread+0x0/0x3f8) from [<c00738d0>] (kthread+0x88/0x90)
[<c0073848>] (kthread+0x0/0x90) from [<c005e924>] (do_exit+0x0/0x5fc)
 r7:00000013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---

I've no idea why this driver uses NULL for dma_unmap_single instead of the &spi->dev that is laying around just waiting to be used in that function - but it's an easy fix.

Also replace this comment with a FIXME comment:
/* Do DMA mapping "early" for better error reporting and
* dcache use. Note that if dma_unmap_single() ever starts
* to do real work on ARM, we'd need to clean up mappings
* for previous transfers on *ALL* exits of this loop... */
as the comment is not true - we do work in dma_unmap() functions, particularly on ARMv6 and above. I've corrected the existing unmap functions but if any others are required they must be added ASAP.

Quoted 1 line
Quoted 49 lines

---
I'm surprised this driver got merged as it has such a comment, and is abusing the DMA API... well, at least with the DMA API debugging we can now catch this stuff.

drivers/spi/omap2_mcspi.c +3 -8
index 951a160..abb1ffb 100644
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
 
 	if (tx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_tx_completion);
-		dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
 
 		/* for TX_ONLY mode, be sure all words have shifted out */
 		if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
 
 	if (rx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_rx_completion);
-		dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->rx_dma, count, DMA_FROM_DEVICE);
 		omap2_mcspi_set_enable(spi, 0);
 
 		if (l & OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi, struct spi_message *m)
 		if (m->is_dma_mapped || len < DMA_MIN_BYTES)
 			continue;
 
-		/* Do DMA mapping "early" for better error reporting and
-		 * dcache use.  Note that if dma_unmap_single() ever starts
-		 * to do real work on ARM, we'd need to clean up mappings
-		 * for previous transfers on *ALL* exits of this loop...
-		 */
 		if (tx_buf != NULL) {
 			t->tx_dma = dma_map_single(&spi->dev, (void *) tx_buf,
 					len, DMA_TO_DEVICE);
@@ -1046,7 +1041,7 @@ static int omap2_mcspi_transfer(struct spi_device *spi, struct spi_message *m)
 				dev_dbg(&spi->dev, "dma %cX %d bytes error\n",
 						'R', len);
 				if (tx_buf != NULL)
-					dma_unmap_single(NULL, t->tx_dma,
+					dma_unmap_single(&spi->dev, t->tx_dma,
 							len, DMA_TO_DEVICE);
 				return -EINVAL;
 			}
Acked-by
#23 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 3 lines · Tony Lindgren

Grant,

Care to queue or ack the following fix?

If you bounce the patch to me, then I'll pick it up into the spi tree and send it on to Linus right away. (It didn't get sent to either me or the spi list, so I don't have the original).

Or if you want to pick it up:

Nothing in my tree touches omap_mcspi.c for this merge window, so there won't be a merge conflict (I'm assuming you want this fix to go into 2.6.28).

g.

Quoted 126 lines · Russell King - ARM Linux
Quoted 70 lines · Santosh Shilimkar
Quoted 11 lines
Quoted 11 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 3 lines · Santosh Shilimkar

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel.

Glad to hear that.

And, with one ARM errata disabled, the kernel finally boots. So the "X-Loader hangs" message means that we did something that non-secure mode prevented us from doing.

It would be a good idea if X-loader could tell dump out the exception, register dump, and for data/prefetch aborts, the relevent FSR and FAR registers - that would make debugging this kind of failure a lot easier.

=================
Subject: Fix DMA API usage in OMAP MCSPI driver

Running the latest kernel on the 4430SDP board with DMA API debugging enabled results in this:

WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated
[device address=0x000000008129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[<c003cbe0>] (dump_backtrace+0x0/0x10c) from [<c0278da8>] (dump_stack+0x18/0x1c)
 r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:00000323
[<c0278d90>] (dump_stack+0x0/0x1c) from [<c005b158>] (warn_slowpath_common+0x58/0x70)
[<c005b100>] (warn_slowpath_common+0x0/0x70) from [<c005b214>] (warn_slowpath_fmt+0x38/0x40)
 r8:c1839e40 r7:00000000 r6:00000104 r5:00000000 r4:8129901a
[<c005b1dc>] (warn_slowpath_fmt+0x0/0x40) from [<c0198578>] (check_unmap+0x19c/0x6f0)
 r3:c03110de r2:c0304e6b
[<c01983dc>] (check_unmap+0x0/0x6f0) from [<c0198cd8>] (debug_dma_unmap_page+0x74/0x80)
[<c0198c64>] (debug_dma_unmap_page+0x0/0x80) from [<c01d5ad8>] (omap2_mcspi_work+0x514/0xbf0)
[<c01d55c4>] (omap2_mcspi_work+0x0/0xbf0) from [<c006dfb0>] (process_one_work+0x294/0x400)
[<c006dd1c>] (process_one_work+0x0/0x400) from [<c006e50c>] (worker_thread+0x220/0x3f8)
[<c006e2ec>] (worker_thread+0x0/0x3f8) from [<c00738d0>] (kthread+0x88/0x90)
[<c0073848>] (kthread+0x0/0x90) from [<c005e924>] (do_exit+0x0/0x5fc)
 r7:00000013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---

I've no idea why this driver uses NULL for dma_unmap_single instead of the &spi->dev that is laying around just waiting to be used in that function - but it's an easy fix.

Also replace this comment with a FIXME comment:
/* Do DMA mapping "early" for better error reporting and
* dcache use. Note that if dma_unmap_single() ever starts
* to do real work on ARM, we'd need to clean up mappings
* for previous transfers on *ALL* exits of this loop... */
as the comment is not true - we do work in dma_unmap() functions, particularly on ARMv6 and above. I've corrected the existing unmap functions but if any others are required they must be added ASAP.

Quoted 1 line
Quoted 49 lines

---
I'm surprised this driver got merged as it has such a comment, and is abusing the DMA API... well, at least with the DMA API debugging we can now catch this stuff.

drivers/spi/omap2_mcspi.c +3 -8
index 951a160..abb1ffb 100644
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
 
 	if (tx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_tx_completion);
-		dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
 
 		/* for TX_ONLY mode, be sure all words have shifted out */
 		if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
 
 	if (rx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_rx_completion);
-		dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->rx_dma, count, DMA_FROM_DEVICE);
 		omap2_mcspi_set_enable(spi, 0);
 
 		if (l & OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi, struct spi_message *m)
 		if (m->is_dma_mapped || len < DMA_MIN_BYTES)
 			continue;
 
-		/* Do DMA mapping "early" for better error reporting and
-		 * dcache use.  Note that if dma_unmap_single() ever starts
-		 * to do real work on ARM, we'd need to clean up mappings
-		 * for previous transfers on *ALL* exits of this loop...
-		 */
 		if (tx_buf != NULL) {
 			t->tx_dma = dma_map_single(&spi->dev, (void *) tx_buf,
 					len, DMA_TO_DEVICE);
@@ -1046,7 +1041,7 @@ static int omap2_mcspi_transfer(struct spi_device *spi, struct spi_message *m)
 				dev_dbg(&spi->dev, "dma %cX %d bytes error\n",
 						'R', len);
 				if (tx_buf != NULL)
-					dma_unmap_single(NULL, t->tx_dma,
+					dma_unmap_single(&spi->dev, t->tx_dma,
 							len, DMA_TO_DEVICE);
 				return -EINVAL;
 			}
maintainer
#24 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 8 lines · Grant Likely
Quoted 3 lines · Tony Lindgren

Grant,

Care to queue or ack the following fix?

If you bounce the patch to me, then I'll pick it up into the spi tree and send it on to Linus right away. (It didn't get sent to either me or the spi list, so I don't have the original).

Thanks, bounced it to you.

Tony

#25 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 11 lines · Tony Lindgren
Quoted 8 lines · Grant Likely
Quoted 3 lines · Tony Lindgren

Grant,

Care to queue or ack the following fix?

If you bounce the patch to me, then I'll pick it up into the spi tree and send it on to Linus right away. (It didn't get sent to either me or the spi list, so I don't have the original).

Thanks, bounced it to you.

As noted in the original patch, someone who understands this driver should fix the other exit paths so buffers aren't left mapped when they shouldn't be.

#26 lore raw

RE: 4430SDP boot failure - solved + SPI bug fix

In reply to Russell King - ARM Linux
Quoted 27 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Russell King - ARM Linux
Sent: Friday, January 07, 2011 9:19 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 8 lines · Santosh Shilimkar
Quoted 8 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar

Quoted 6 lines · wrote:
Quoted 6 lines
Quoted 4 lines

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely

on

Quoted 1 line
Quoted 1 line

the board - which should ease the debugging problem as it no

longer

Quoted 9 lines
Quoted 1 line
Quoted 1 line

requires anything but the reset button pressed to test a new

kernel.

Quoted 2 lines

Glad to hear that.

And, with one ARM errata disabled, the kernel finally boots. So the "X-Loader hangs" message means that we did something that non-secure mode prevented us from doing.

Actually it's not. The error message is quite misleading. Basically in x-loader exception handlers are setup and all these handlers report same message ("X-Loader hangs"). This should be fixed so that it can report more meaningful info like data abort, prefetch abort etc.

Till the vector relocation in the kernel exceptions are not set up so code jumps to already installed exceptions in the x-loader and hence the messege.

Quoted 7 lines

It would be a good idea if X-loader could tell dump out the exception,
register dump, and for data/prefetch aborts, the relevent FSR and FAR
registers - that would make debugging this kind of failure a lot easier.

Yes. At least it should report data/prefect aborts.

Quoted 53 lines

=================
Subject: Fix DMA API usage in OMAP MCSPI driver

Running the latest kernel on the 4430SDP board with DMA API debugging
enabled results in this:

WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has
not allocated
[device address=0x000000008129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[<c003cbe0>] (dump_backtrace+0x0/0x10c) from [<c0278da8>]
(dump_stack+0x18/0x1c)
 r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:00000323
[<c0278d90>] (dump_stack+0x0/0x1c) from [<c005b158>]
(warn_slowpath_common+0x58/0x70)
[<c005b100>] (warn_slowpath_common+0x0/0x70) from [<c005b214>]
(warn_slowpath_fmt+0x38/0x40)
 r8:c1839e40 r7:00000000 r6:00000104 r5:00000000 r4:8129901a
[<c005b1dc>] (warn_slowpath_fmt+0x0/0x40) from [<c0198578>]
(check_unmap+0x19c/0x6f0)
 r3:c03110de r2:c0304e6b
[<c01983dc>] (check_unmap+0x0/0x6f0) from [<c0198cd8>]
(debug_dma_unmap_page+0x74/0x80)
[<c0198c64>] (debug_dma_unmap_page+0x0/0x80) from [<c01d5ad8>]
(omap2_mcspi_work+0x514/0xbf0)
[<c01d55c4>] (omap2_mcspi_work+0x0/0xbf0) from [<c006dfb0>]
(process_one_work+0x294/0x400)
[<c006dd1c>] (process_one_work+0x0/0x400) from [<c006e50c>]
(worker_thread+0x220/0x3f8)
[<c006e2ec>] (worker_thread+0x0/0x3f8) from [<c00738d0>]
(kthread+0x88/0x90)
[<c0073848>] (kthread+0x0/0x90) from [<c005e924>]
(do_exit+0x0/0x5fc)
 r7:00000013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---

I've no idea why this driver uses NULL for dma_unmap_single instead of
the &spi->dev that is laying around just waiting to be used in that function - but it's an easy fix.

Also replace this comment with a FIXME comment:

                /* Do DMA mapping "early" for better error reporting

and
* dcache use. Note that if dma_unmap_single() ever
starts
* to do real work on ARM, we'd need to clean up
mappings
* for previous transfers on *ALL* exits of this
loop...

Quoted 6 lines
                 */

as the comment is not true - we do work in dma_unmap() functions, particularly on ARMv6 and above. I've corrected the existing unmap functions but if any others are required they must be added ASAP.

Thanks for fixing it

Quoted 52 lines

---
I'm surprised this driver got merged as it has such a comment, and is
abusing the DMA API... well, at least with the DMA API debugging we can now catch this stuff.

drivers/spi/omap2_mcspi.c +1 -1
index 951a160..abb1ffb 100644
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi,
 struct spi_transfer *xfer)
 
 	if (tx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_tx_completion);
-		dma_unmap_single(NULL, xfer->tx_dma, count,
 DMA_TO_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->tx_dma, count,
 DMA_TO_DEVICE);

/* for TX_ONLY mode, be sure all words have shifted out
*/

drivers/spi/omap2_mcspi.c +1 -1
 		if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi,
 struct spi_transfer *xfer)
 
 	if (rx != NULL) {
 		wait_for_completion(&mcspi_dma->dma_rx_completion);
-		dma_unmap_single(NULL, xfer->rx_dma, count,
 DMA_FROM_DEVICE);
+		dma_unmap_single(&spi->dev, xfer->rx_dma, count,
 DMA_FROM_DEVICE);
drivers/spi/omap2_mcspi.c +0 -2
 		omap2_mcspi_set_enable(spi, 0);
 
 		if (l & OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct
 spi_device *spi, struct spi_message *m)
 		if (m->is_dma_mapped || len < DMA_MIN_BYTES)
 			continue;
 
-		/* Do DMA mapping "early" for better error reporting and
-		 * dcache use.  Note that if dma_unmap_single() ever

starts

drivers/spi/omap2_mcspi.c +0 -1
-		 * to do real work on ARM, we'd need to clean up

mappings

drivers/spi/omap2_mcspi.c +0 -2
-		 * for previous transfers on *ALL* exits of this loop...
-		 */
 		if (tx_buf != NULL) {
 			t->tx_dma = dma_map_single(&spi->dev, (void *)

tx_buf,

drivers/spi/omap2_mcspi.c +0 -0
 					len, DMA_TO_DEVICE);

drivers/spi/omap2_mcspi.c static int omap2_mcspi_transfer(struct · line 1046

Quoted 7 lines
drivers/spi/omap2_mcspi.c +1 -1
@@ -1046,7 +1041,7 @@ static int omap2_mcspi_transfer(struct
 spi_device *spi, struct spi_message *m)
 				dev_dbg(&spi->dev, "dma %cX %d bytes
 error\n",
 						'R', len);
 				if (tx_buf != NULL)
-					dma_unmap_single(NULL, t->tx_dma,
+					dma_unmap_single(&spi->dev,

t->tx_dma,

drivers/spi/omap2_mcspi.c static int omap2_mcspi_transfer(struct · line 1047

Quoted 1 line
drivers/spi/omap2_mcspi.c +0 -0
 							len,

DMA_TO_DEVICE);

Quoted 8 lines
drivers/spi/omap2_mcspi.c +0 -1
 				return -EINVAL;
 			}
 
--

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

#27 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 4 lines · Santosh Shilimkar
Quoted 4 lines

And, with one ARM errata disabled, the kernel finally boots. So the "X-Loader hangs" message means that we did something that non-secure mode prevented us from doing.

Quoted 8 lines

Actually it's not. The error message is quite misleading. Basically in x-loader exception handlers are setup and all these handlers report same message ("X-Loader hangs"). This should be fixed so that it can report more meaningful info like data abort, prefetch abort etc.

Till the vector relocation in the kernel exceptions are not set up so code jumps to already installed exceptions in the x-loader and hence the messege.

I disagree with your "actually it's not". It was errata 742230, which requires access to the CP15, c15, c0, 1 register (a diagnostic register) which I bet provokes an undefined instruction trap from non-secure mode.

Hence, the reason it vectored to the X-loader was because we tried to do something in the non-secure mode which we're prevented from doing.

#28 lore raw

RE: 4430SDP boot failure - solved + SPI bug fix

Quoted 26 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Saturday, January 08, 2011 12:23 AM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 1 line · Santosh Shilimkar
Quoted 1 line

And, with one ARM errata disabled, the kernel finally boots. So

the

Quoted 1 line
Quoted 1 line

"X-Loader hangs" message means that we did something that non-

secure

Quoted 3 lines
Quoted 2 lines

mode prevented us from doing.

Actually it's not. The error message is quite misleading.

Basically in

Quoted 1 line

x-loader exception handlers are setup and all these handlers

report

Quoted 1 line

same message ("X-Loader hangs"). This should be fixed so that it

can

Quoted 5 lines

report more meaningful info like data abort, prefetch abort etc.

Till the vector relocation in the kernel exceptions are not set up so code jumps to already installed exceptions in the x-loader and hence the messege.

Quoted 7 lines

I disagree with your "actually it's not". It was errata 742230, which
requires access to the CP15, c15, c0, 1 register (a diagnostic register)
which I bet provokes an undefined instruction trap from non-secure mode.

742230 errata workaround is not implemented in the x-loader so I can surely say it's not the secure violation.

He is the x-loader source tree.
http://dev.omapzoom.org/?p=bootloader/x-loader.git;a=shortlog;h=refs/heads
/omap4_dev

Even simple things like if DDR is not configured correctly or not Stable, code/data access takes abort which lands up in the "X-loader hang messege"

Quoted 4 lines

Hence, the reason it vectored to the X-loader was because we tried to
do something in the non-secure mode which we're prevented from doing.

My suspect was clock configurations on the older boot loaders were Incomplete that might have lead to issue since now more drivers are getting enabled in newer kernels.

#29 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 33 lines · Santosh Shilimkar
Quoted 26 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Saturday, January 08, 2011 12:23 AM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 1 line · Santosh Shilimkar
Quoted 1 line

And, with one ARM errata disabled, the kernel finally boots. So

the

Quoted 1 line
Quoted 1 line

"X-Loader hangs" message means that we did something that non-

secure

Quoted 3 lines
Quoted 2 lines

mode prevented us from doing.

Actually it's not. The error message is quite misleading.

Basically in

Quoted 1 line

x-loader exception handlers are setup and all these handlers

report

Quoted 1 line

same message ("X-Loader hangs"). This should be fixed so that it

can

Quoted 5 lines

report more meaningful info like data abort, prefetch abort etc.

Till the vector relocation in the kernel exceptions are not set up so code jumps to already installed exceptions in the x-loader and hence the messege.

Quoted 7 lines

I disagree with your "actually it's not". It was errata 742230, which
requires access to the CP15, c15, c0, 1 register (a diagnostic register)
which I bet provokes an undefined instruction trap from non-secure mode.

Quoted 2 lines

742230 errata workaround is not implemented in the x-loader so I can surely say it's not the secure violation.

Precisely. So when we directly read, modify and write this diagnostic register in the non-secure world during kernel boot, we end up faulting. Comment those instructions out, we don't get a fault, and the kernel boots normally.

#30 lore raw

RE: 4430SDP boot failure - solved + SPI bug fix

Quoted 52 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Saturday, January 08, 2011 12:50 AM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure - solved + SPI bug fix

Quoted 8 lines · Santosh Shilimkar
Quoted 8 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Saturday, January 08, 2011 12:23 AM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure - solved + SPI bug fix

On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar

Quoted 1 line · wrote:
Quoted 1 line
Quoted 1 line
Quoted 1 line

And, with one ARM errata disabled, the kernel finally boots.

So

Quoted 2 lines
Quoted 2 lines

the

Quoted 1 line
Quoted 1 line

"X-Loader hangs" message means that we did something that

non-

Quoted 8 lines
Quoted 8 lines

secure

Quoted 3 lines
Quoted 2 lines

mode prevented us from doing.

Actually it's not. The error message is quite misleading.

Basically in

Quoted 1 line

x-loader exception handlers are setup and all these handlers

report

Quoted 1 line

same message ("X-Loader hangs"). This should be fixed so that

it

Quoted 2 lines
Quoted 2 lines

can

Quoted 1 line

report more meaningful info like data abort, prefetch abort

etc.

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Till the vector relocation in the kernel exceptions are not

set up

Quoted 1 line
Quoted 1 line
Quoted 1 line

so code jumps to already installed exceptions in the x-loader

and

Quoted 7 lines
Quoted 7 lines
Quoted 1 line

hence the messege.

I disagree with your "actually it's not". It was errata 742230, which
requires access to the CP15, c15, c0, 1 register (a diagnostic register)
which I bet provokes an undefined instruction trap from non-

secure

Quoted 4 lines
Quoted 2 lines

mode.

742230 errata workaround is not implemented in the x-loader so I can surely say it's not the secure violation.

Quoted 6 lines

Precisely. So when we directly read, modify and write this diagnostic
register in the non-secure world during kernel boot, we end up faulting.
Comment those instructions out, we don't get a fault, and the kernel boots normally.

I understand now. Was confused last time.

So your custom build did have this errata CONFIG_ARM_ERRATA_742230 where there is an access to diagnostic register which is not accessible on OMAP4 from non-secure side.

Thanks for clarification.

Regards,
Santosh

#31 lore raw

Re: 4430SDP boot failure - solved + SPI bug fix

In reply to Russell King - ARM Linux
Quoted 3 lines · Russell King - ARM Linux

And, with one ARM errata disabled, the kernel finally boots. So the "X-Loader hangs" message means that we did something that non-secure mode prevented us from doing.

Here's the dmesg with as many things as I could find enabled.

Linux version 2.6.37+ (rmk@rmk-PC) (gcc version 4.3.5 (GCC) ) #67 SMP PREEMPT Fri Jan 7 19:38:30 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: OMAP4430 4430SDP board
vmalloc area is too big, limiting to 864MB
Memory policy: ECC disabled, Data cache writealloc
OMAP4430 ES1.0
SRAM: Mapped pa 0x40300000 to va 0xfe400000 size: 0xe000
FIXME: omap44xx_sram_init not implemented
On node 0 totalpages: 131072
free_area_init_node: node 0, pgdat c035f540, node_mem_map c0381000
Normal zone: 64 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 8128 pages, LIFO batch:0
HighMem zone: 960 pages used for memmap
HighMem zone: 121920 pages, LIFO batch:31
PERCPU: Embedded 7 pages/cpu @c0786000 s4192 r8192 d16288 u32768
pcpu-alloc: s4192 r8192 d16288 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Kernel command line: root=/dev/mmcblk0p2 ip=dhcp rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2 PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 512MB = 512MB total
Memory: 516492k/516492k available, 7796k reserved, 491520K highmem
Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc2800000 - 0xf8000000   ( 856 MB)
    lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .init : 0xc0008000 - 0xc002f000   ( 156 kB)
      .text : 0xc002f000 - 0xc0334000   (3092 kB)
      .data : 0xc0334000 - 0xc035ff00   ( 176 kB)

SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Preemptable hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.
NR_IRQS:402
powerdomain: waited too long for powerdomain dss_pwrdm to complete transition

------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/clockdomain.c:868 omap2_clkdm_deny_idle+0x58/0xcc()
clockdomain: OMAP4 wakeup/sleep dependency support is not yet implemented
Modules linked in:
Backtrace: 
[<c003ebe0>] (dump_backtrace+0x0/0x10c) from [<c027d188>] (dump_stack+0x18/0x1c)
 r7:c0335f30 r6:c004a7f0 r5:c02f6189 r4:00000364
[<c027d170>] (dump_stack+0x0/0x1c) from [<c005d3d8>] (warn_slowpath_common+0x58/0x70)
[<c005d380>] (warn_slowpath_common+0x0/0x70) from [<c005d494>] (warn_slowpath_fmt+0x38/0x40)
 r8:c0347860 r7:c03464c4 r6:00000060 r5:c0346f4c r4:c036032c
[<c005d45c>] (warn_slowpath_fmt+0x0/0x40) from [<c004a7f0>] (omap2_clkdm_deny_idle+0x58/0xcc)
 r3:00000000 r2:c02f61c7
[<c004a798>] (omap2_clkdm_deny_idle+0x0/0xcc) from [<c004ab6c>] (clkdm_init+0x144/0x17c)
 r5:c0347860 r4:c0346f4c
[<c004aa28>] (clkdm_init+0x0/0x17c) from [<c000f170>] (omap2_init_common_hw+0x20/0xa0)
[<c000f150>] (omap2_init_common_hw+0x0/0xa0) from [<c0010aa8>] (omap_4430sdp_init_irq+0x34/0x54)
[<c0010a74>] (omap_4430sdp_init_irq+0x0/0x54) from [<c000bafc>] (init_IRQ+0x1c/0x24)
 r4:c035ff00
[<c000bae0>] (init_IRQ+0x0/0x24) from [<c0008d04>] (start_kernel+0x18c/0x2fc)
[<c0008b78>] (start_kernel+0x0/0x2fc) from [<80008038>] (0x80008038)
 r7:c0345cb4 r6:c0029120 r5:c0342bf0 r4:10c53c7d
---[ end trace 1b75b31a2719ed1c ]---

omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. GPMC revision 6.0
OMAP GPIO hardware version 0.1
OMAP clockevent source: GPTIMER1 at 32768 Hz
Console: colour dummy device 80x30
Calibrating delay loop... 2013.49 BogoMIPS (lpj=7864320)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
L310 cache controller enabled
l2x0: 16 ways, CACHE_ID 0x410000c2, AUX_CTRL 0x0e050000, Cache size: 524288 B
CPU1: Booted secondary processor
CPU1: Unknown IPI message 0x1
Brought up 2 CPUs
SMP: Total of 2 processors activated (4026.98 BogoMIPS).
regulator: core version 0.5
regulator: dummy:
NET: Registered protocol family 16
OMAP DMA hardware revision 0.0
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
bio: create slab <bio-0> at 0
i2c_omap i2c_omap.1: bus 1 rev4.0 at 400 kHz
Skipping twl internal clock init and using bootloader value (unknown osc rate)
twl6030: PIH (irq 39) chaining IRQs 368..387
regulator: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby
regulator: VPP: 1800 <--> 2500 mV at 1900 mV normal standby
regulator: VUSIM: 1200 <--> 2900 mV at 1800 mV normal standby
regulator: VANA: 2100 mV normal standby
regulator: VCXIO: 1800 mV normal standby
regulator: VDAC: 1800 mV normal standby
regulator: VUSB: 3300 mV normal standby
regulator: VAUX1_6030: 1000 <--> 3000 mV at 2800 mV normal standby
regulator: VAUX2_6030: 1200 <--> 2800 mV at 1800 mV normal standby
regulator: VAUX3_6030: 1000 <--> 3000 mV at 1200 mV normal standby i2c_omap i2c_omap.2: bus 2 rev4.0 at 400 kHz
i2c_omap i2c_omap.3: bus 3 rev4.0 at 400 kHz
i2c_omap i2c_omap.4: bus 4 rev4.0 at 400 kHz
DMA-API: preallocated 4096 debug entries
DMA-API: debugging enabled by kernel config
Switching to clocksource 32k_counter
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 1, 12288 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
UDP hash table entries: 128 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 128 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module. NetWinder Floating Point Emulator V0.97 (double precision)

------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/pm.c:64 _init_omap_device+0x8c/0xac()
_init_omap_device: could not find omap_hwmod for iva
Modules linked in:
Backtrace: 
[<c003ebe0>] (dump_backtrace+0x0/0x10c) from [<c027d188>] (dump_stack+0x18/0x1c)
 r7:c1829f38 r6:c0046d84 r5:c02f579e r4:00000040
[<c027d170>] (dump_stack+0x0/0x1c) from [<c005d3d8>] (warn_slowpath_common+0x58/0x70)
[<c005d380>] (warn_slowpath_common+0x0/0x70) from [<c005d494>] (warn_slowpath_fmt+0x38/0x40)
 r8:c000ffac r7:c0342bc0 r6:c03602f0 r5:c02f5825 r4:c0027b34
[<c005d45c>] (warn_slowpath_fmt+0x0/0x40) from [<c0046d84>] (_init_omap_device+0x8c/0xac)
 r3:c02818ff r2:c02f57d3
[<c0046cf8>] (_init_omap_device+0x0/0xac) from [<c000ffd0>] (omap2_common_pm_init+0x24/0x88)
 r6:c0345648 r5:c0027cf0 r4:c0027b34
[<c000ffac>] (omap2_common_pm_init+0x0/0x88) from [<c002f550>] (do_one_initcall+0xd0/0x19c)
[<c002f480>] (do_one_initcall+0x0/0x19c) from [<c000881c>] (kernel_init+0x15c/0x224)
[<c00086c0>] (kernel_init+0x0/0x224) from [<c0060ba4>] (do_exit+0x0/0x5fc)
 r8:00000000 r7:00000013 r6:c0060ba4 r5:c00086c0 r4:00000000
---[ end trace 1b75b31a2719ed1d ]---
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/pm.c:64 _init_omap_device+0x8c/0xac()
_init_omap_device: could not find omap_hwmod for dsp
Modules linked in:
Backtrace: 
[<c003ebe0>] (dump_backtrace+0x0/0x10c) from [<c027d188>] (dump_stack+0x18/0x1c)
 r7:c1829f38 r6:c0046d84 r5:c02f579e r4:00000040
[<c027d170>] (dump_stack+0x0/0x1c) from [<c005d3d8>] (warn_slowpath_common+0x58/0x70)
[<c005d380>] (warn_slowpath_common+0x0/0x70) from [<c005d494>] (warn_slowpath_fmt+0x38/0x40)
 r8:c000ffac r7:c0342bc0 r6:c03602f8 r5:c02f3839 r4:c0027b34
[<c005d45c>] (warn_slowpath_fmt+0x0/0x40) from [<c0046d84>] (_init_omap_device+0x8c/0xac)
 r3:c02818ff r2:c02f57d3
[<c0046cf8>] (_init_omap_device+0x0/0xac) from [<c0010004>] (omap2_common_pm_init+0x58/0x88)
 r6:c0345648 r5:c0027cf0 r4:c0027b34
[<c000ffac>] (omap2_common_pm_init+0x0/0x88) from [<c002f550>] (do_one_initcall+0xd0/0x19c)
[<c002f480>] (do_one_initcall+0x0/0x19c) from [<c000881c>] (kernel_init+0x15c/0x224)
[<c00086c0>] (kernel_init+0x0/0x224) from [<c0060ba4>] (do_exit+0x0/0x5fc)
 r8:00000000 r7:00000013 r6:c0060ba4 r5:c00086c0 r4:00000000
---[ end trace 1b75b31a2719ed1e ]---

highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) msgmni has been set to 48
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0 omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1 omap-hsuart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2 console [ttyO2] enabled
omap-hsuart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3
brd: module loaded
loop: module loaded
ks8851 spi1.0: message enable is 0
ks8851 spi1.0: eth0: revision 0, MAC ce:b7:60:a5:a7:10, IRQ 194
input: gpio-keys as /devices/platform/gpio-keys/input/input0 twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
twl_rtc twl_rtc: Power up reset detected.
twl_rtc twl_rtc: Enabling TWL-RTC.
i2c /dev entries driver
lm75 3-0048: hwmon0: sensor 'tmp105'
i2c_omap i2c_omap.1: controller timed out
i2c_omap i2c_omap.1: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.3: controller timed out
i2c_omap i2c_omap.3: controller timed out
i2c_omap i2c_omap.3: controller timed out
i2c_omap i2c_omap.4: controller timed out
i2c_omap i2c_omap.4: controller timed out
i2c_omap i2c_omap.4: controller timed out
i2c_omap i2c_omap.4: controller timed out
Registered led device: omap4:green:debug0
Registered led device: omap4:green:debug1
Registered led device: omap4:green:debug2
Registered led device: omap4:green:debug3
Registered led device: omap4:green:debug4
Registered led device: omap4:blue:user
Registered led device: omap4:red:user
Registered led device: omap4:green:user
TCP cubic registered
NET: Registered protocol family 17
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0 Power Management for TI OMAP4.
regulator_init_complete: incomplete constraints, leaving VAUX3_6030 on
regulator_init_complete: incomplete constraints, leaving VAUX2_6030 on
regulator_init_complete: incomplete constraints, leaving VUSB on
regulator_init_complete: incomplete constraints, leaving VDAC on
regulator_init_complete: incomplete constraints, leaving VCXIO on
regulator_init_complete: incomplete constraints, leaving VANA on
regulator_init_complete: incomplete constraints, leaving VUSIM on
regulator_init_complete: incomplete constraints, leaving VPP on twl_rtc twl_rtc: hctosys: invalid date/time
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SD card at address 0002
mmcblk0: mmc0:0002 00000 971 MiB
mmcblk0: p1 p2
mmc1: new high speed MMC card at address 0001
mmcblk1: mmc1:0001 MMC32G 29.8 GiB
mmcblk1: p1
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.152
IP-Config: Complete:

     device=eth0, addr=192.168.0.152, mask=255.255.255.0, gw=192.168.0.1,
     host=192.168.0.152, domain=arm.linux.org.uk, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=

Waiting 2sec before mounting root device...
EXT3-fs: barriers not enabled
kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): recovery complete
EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:2.
Freeing init memory: 156K
udevd (458): /proc/458/oom_adj is deprecated, please use /proc/458/oom_score_adj instead. udevd version 124 started
EXT3-fs (mmcblk0p2): error: unrecognized mount option "relatime" or missing value

#32 lore raw
In reply to Santosh Shilimkar
Quoted 11 lines · Santosh Shilimkar
Quoted 11 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 3 lines · Santosh Shilimkar

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel.

Glad to hear that.

Right, next couple of problems.

udev isn't creating the ttyO* nodes for whatever reason on my fs - does anyone know what device major/minor numbers these end up with? It seems they're dynamically assigned.

There's also something fishy going on with networking (if I configure PNP IP, I get an IP:

ks8851 spi1.0: message enable is 0
ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
IP-Config: Complete:

     device=eth0, addr=192.168.0.144, mask=255.255.255.0, gw=192.168.0.1,
     host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=

but the board doesn't respond to that IP address. Meanwhile the DHCP server shows:

	DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0

in its log, and the ethernet address appears to be random for each boot. Obviously, as I can't log into the board via any means, it's nigh on impossible to work out what's actually going on.

#33 lore raw

Hello!

Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Santosh Shilimkar
Quoted 16 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 4 lines · Santosh Shilimkar

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel.

Quoted 7 lines
Quoted 1 line

Glad to hear that.

Right, next couple of problems.

udev isn't creating the ttyO* nodes for whatever reason on my fs - does anyone know what device major/minor numbers these end up with?  It seems they're dynamically assigned.

This is what I have:
mazi-gentoo ~ # ls -l /dev/ttyO?

crw-rw---- 1 root  uucp 247, 0 Dec 31  1999 /dev/ttyO0
crw-rw---- 1 root  uucp 247, 1 Dec 31  1999 /dev/ttyO1

crw------- 1 ddiaz tty 247, 2 Jan 7 11:02 /dev/ttyO2 crw-rw---- 1 root uucp 247, 3 Dec 31 1999 /dev/ttyO3

Greetings!

Daniel Díaz
[email protected]

Quoted 11 lines

There's also something fishy going on with networking (if I configure PNP IP, I get an IP:

ks8851 spi1.0: message enable is 0
ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
IP-Config: Complete:
    device=eth0, addr=192.168.0.144, mask=255.255.255.0, gw=192.168.0.1, host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none), bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=

Quoted 8 lines

but the board doesn't respond to that IP address.  Meanwhile the DHCP server shows:

       DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0

in its log, and the ethernet address appears to be random for each boot. Obviously, as I can't log into the board via any means, it's nigh on impossible to work out what's actually going on.

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

#34 lore raw
In reply to Russell King - ARM Linux
Quoted 31 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 9:54 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

Quoted 8 lines · Santosh Shilimkar
Quoted 8 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:[email protected]]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: [email protected]; Tony Lindgren
Subject: Re: 4430SDP boot failure

On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar

Quoted 6 lines · wrote:
Quoted 6 lines
Quoted 4 lines

Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me.

Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely

on

Quoted 1 line
Quoted 1 line

the board - which should ease the debugging problem as it no

longer

Quoted 1 line
Quoted 1 line

requires anything but the reset button pressed to test a new

kernel.

Quoted 2 lines

Glad to hear that.

Quoted 8 lines

Right, next couple of problems.

udev isn't creating the ttyO* nodes for whatever reason on my fs - does
anyone know what device major/minor numbers these end up with? It seems
they're dynamically assigned.

Right now don't have access to my board so can't check this.

Quoted 17 lines

There's also something fishy going on with networking (if I configure
PNP IP, I get an IP:

ks8851 spi1.0: message enable is 0
ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
IP-Config: Complete:

     device=eth0, addr=192.168.0.144, mask=255.255.255.0,
gw=192.168.0.1,
     host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=

but the board doesn't respond to that IP address. Meanwhile the DHCP
server shows:

Quoted 6 lines
	DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0

in its log, and the ethernet address appears to be random for each boot.
Obviously, as I can't log into the board via any means, it's nigh on impossible to work out what's actually going on.

DHCP seems to work for me without any issues.

#35 lore raw
Quoted 13 lines · Santosh Shilimkar
Quoted 13 lines

ks8851 spi1.0: message enable is 0
ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
IP-Config: Complete:

     device=eth0, addr=192.168.0.144, mask=255.255.255.0,
gw=192.168.0.1,
     host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=

but the board doesn't respond to that IP address. Meanwhile the DHCP
server shows:

Quoted 8 lines
Quoted 6 lines
	DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0

in its log, and the ethernet address appears to be random for each boot.
Obviously, as I can't log into the board via any means, it's nigh on impossible to work out what's actually going on.

DHCP seems to work for me without any issues.

The board now has an ethernet address of 1E:89:8E:DA:80:7C - it seems to be intentionally random which isn't particularly nice. At least it's intentionally random and not some undefined region of memory being poked in there...

#36 lore raw
In reply to Russell King - ARM Linux

Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven:

Quoted 3 lines

This is the command line I've been giving it:

setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2'

Why are people still using rootdelay? 'rootwait' is vastly superior and doesn't need tweaking for every card/controller combo.

regards,

Koen

#37 lore raw
Quoted 6 lines · Koen Kooi

Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven:

Quoted 3 lines

This is the command line I've been giving it:

setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2'

Why are people still using rootdelay? 'rootwait' is vastly superior and doesn't need tweaking for every card/controller combo.

Does it matter if the effect it produces works?

#38 lore raw
In reply to Tony Lindgren
Quoted 35 lines · Tony Lindgren
Quoted 34 lines · Russell King - ARM Linux
Quoted 16 lines · Russell King - ARM Linux

This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37...

It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built.

Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment.

Quoted 2 lines

For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on.

And another thing: turning on DEBUG in the decompressor breaks the build on OMAP:

.data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o .data' referenced in section .text' of arch/arm/boot/compressed/head.o: defined in discarded section .data' of arch/arm/boot/compressed/head.o

Is there a reason why this:

.pushsection .data

omap_uart_phys: .word   0
omap_uart_virt: .word   0
omap_uart_lsr:  .word   0

.popsection

Quoted 3 lines
Quoted 1 line

can't be in the BSS section?

BSS works too, got a patch for that?

Yes.

sed -i '/\.pushsection \.data/,/\.popsection/ {
	s/\.data/.bss/;
	s/.word\t0/.space\t4/;
}' arch/arm/mach-omap2/include/mach/debug-macro.S
Quoted 11 lines
Quoted 8 lines

With that fixed, and a debug version of the decompressor built, when I load and run this I get the same results - without the debugging output. If I put additional debugging earlier in the decompressor, I don't see it decompressing the kernel at all.

Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port.

Can you please check if you have some older bootloader that passes some wrong machine ID?

If previous kernels didn't explicitly force the SDP4430 platform ID number (which they didn't for OMAP back to 2007), then it must be correct as previous kernels booted fine when only configured for the SDP4430.

It must also be correct as the decompressor can select the correct port for outputting the "Decompressing kernel..." message.

So by implication I think we can say that the ID number is correct.

I've just tried forcing it to use OMAP4 UART3, which seems to be what the decompressor is using for its output:

0000090c <puts>:

     90c:       e3a03802        mov     r3, #131072     ; 0x20000
     910:       e38314fa        orr     r1, r3, #-100663296     ; 0xfa000000
     914:       e3833312        orr     r3, r3, #1207959552     ; 0x48000000
     918:       e4d02001        ldrb    r2, [r0], #1
     91c:       e3320000        teq     r2, #0  ; 0x0
     920:       01a0f00e        moveq   pc, lr
     924:       e5c32000        strb    r2, [r3]
     928:       e3a01802        mov     r1, #131072     ; 0x20000
     92c:       e2511001        subs    r1, r1, #1      ; 0x1
     930:       1afffffd        bne     92c <puts+0x20>
     934:       e332000a        teq     r2, #10 ; 0xa
     938:       03a0200d        moveq   r2, #13 ; 0xd
     93c:       0afffff8        beq     924 <puts+0x18>
     940:       e3300000        teq     r0, #0  ; 0x0
     944:       1afffff3        bne     918 <puts+0xc>
     948:       e1a0f00e        mov     pc, lr

0x48020000 is the only UART address contained within the disassembly for the decompressor to use, so that must be the correct address.

However, even with that, it causes the 'X-Loader hangs' before producing any output. No idea what to try next - and it's soo much hastle to keep moving SD cards around - which the laptop sometimes doesn't recognise - just to try new kernels that I'm wasting quite a bit of effort on each iteration it's untrue.

As I said previously, I think someone else can look into this - someone who understands the hardware quirks of OMAP, who has a decent test setup, and has the tools necessary to do hardware debug on OMAP.

(If it could do dhcp/tftp - and be configured to do that from powerup without interruption, then I might feel differently as that would significantly reduce the hastle factor and amount of time involved with testing each iteration.)

maintainer
#39 lore raw
Quoted 4 lines · Russell King - ARM Linux
Quoted 3 lines · Tony Lindgren
Quoted 1 line · Russell King - ARM Linux

can't be in the BSS section?

Quoted 8 lines
Quoted 1 line

BSS works too, got a patch for that?

Yes.

sed -i '/\.pushsection \.data/,/\.popsection/ {
	s/\.data/.bss/;
	s/.word\t0/.space\t4/;
}' arch/arm/mach-omap2/include/mach/debug-macro.S

That does not work as BSS gets cleared in head-common.S.. See my other patch.

Quoted 8 lines
Quoted 2 lines

Can you please check if you have some older bootloader that passes some wrong machine ID?

If previous kernels didn't explicitly force the SDP4430 platform ID number (which they didn't for OMAP back to 2007), then it must be correct as previous kernels booted fine when only configured for the SDP4430.

Quoted 4 lines

It must also be correct as the decompressor can select the correct port for outputting the "Decompressing kernel..." message.

So by implication I think we can say that the ID number is correct.

OK thanks.

Quoted 30 lines

I've just tried forcing it to use OMAP4 UART3, which seems to be what the decompressor is using for its output:

0000090c <puts>:

     90c:       e3a03802        mov     r3, #131072     ; 0x20000
     910:       e38314fa        orr     r1, r3, #-100663296     ; 0xfa000000
     914:       e3833312        orr     r3, r3, #1207959552     ; 0x48000000
     918:       e4d02001        ldrb    r2, [r0], #1
     91c:       e3320000        teq     r2, #0  ; 0x0
     920:       01a0f00e        moveq   pc, lr
     924:       e5c32000        strb    r2, [r3]
     928:       e3a01802        mov     r1, #131072     ; 0x20000
     92c:       e2511001        subs    r1, r1, #1      ; 0x1
     930:       1afffffd        bne     92c <puts+0x20>
     934:       e332000a        teq     r2, #10 ; 0xa
     938:       03a0200d        moveq   r2, #13 ; 0xd
     93c:       0afffff8        beq     924 <puts+0x18>
     940:       e3300000        teq     r0, #0  ; 0x0
     944:       1afffff3        bne     918 <puts+0xc>
     948:       e1a0f00e        mov     pc, lr

0x48020000 is the only UART address contained within the disassembly for the decompressor to use, so that must be the correct address.

However, even with that, it causes the 'X-Loader hangs' before producing any output. No idea what to try next - and it's soo much hastle to keep moving SD cards around - which the laptop sometimes doesn't recognise - just to try new kernels that I'm wasting quite a bit of effort on each iteration it's untrue.

Quoted 3 lines

As I said previously, I think someone else can look into this - someone who understands the hardware quirks of OMAP, who has a decent test setup, and has the tools necessary to do hardware debug on OMAP.

I think I got it fixed, see the other patch I just posted.

Quoted 4 lines

(If it could do dhcp/tftp - and be configured to do that from powerup without interruption, then I might feel differently as that would significantly reduce the hastle factor and amount of time involved with testing each iteration.)

Yes these new boards badly need the Ethernet working in u-boot..

Anyways, I can debug the DEBUG_LL booting issue further if the patch I posted does not help.

Regards,

Tony

#40 lore raw
Quoted 2 lines · Tony Lindgren

Anyways, I can debug the DEBUG_LL booting issue further if the patch I posted does not help.

This is what I ended up with earlier today to make the debug code work both in the decompressor and in the kernel - once I had it working I haven't bothered putting any more effort into it.

arch/arm/mach-omap2/include/mach/debug-macro.S +19 -0
index 6a4d413..47df8a6 100644
@@ -13,6 +13,7 @@
 
 #include <linux/serial_reg.h>
 
+#if 0
 #include <asm/memory.h>
 
 #include <plat/serial.h>
@@ -139,6 +140,24 @@ omap_uart_lsr:	.word	0
 		teq	\rd, #(UART_LSR_TEMT | UART_LSR_THRE)
 		bne	1001b
 		.endm
+#else
+		.macro	addruart, rp, rv
+		mov	\rp, #0x00020000
+		orr	\rv, \rp, #0xfa000000
+		orr	\rp, \rp, #0x48000000
+		.endm
+
+		.macro	senduart, ch, rb
+		strb	\ch, [\rb]
+		.endm
+
+		.macro	busyuart, rb, tmp
+1001:		ldrb	\tmp, [\rb, #UART_LSR << 2]
+		and	\tmp, \tmp, #UART_LSR_TEMT | UART_LSR_THRE
+		teq	\tmp, #UART_LSR_TEMT | UART_LSR_THRE
+		bne	1001b
+		.endm
+#endif
 
 		.macro	waituart,rd,rx
 		.endm
maintainer
#41 lore raw
Quoted 7 lines · Russell King - ARM Linux
Quoted 2 lines · Tony Lindgren

Anyways, I can debug the DEBUG_LL booting issue further if the patch I posted does not help.

This is what I ended up with earlier today to make the debug code work both in the decompressor and in the kernel - once I had it working I haven't bothered putting any more effort into it.

Hmm I have DEBUG_LL working fine (execept not for the uncompress code).

Looks like the only issue I have with my 4430 es1.0 blaze board is that it won't boot reliably unless I disable l2x0_init.

Have you guys seen this issue?

Of course there are all kinds of omap4 warnings there, but after disabling l2x0_init I was able to run apt-get dist-upgrade on my board. This is with what I have queued up in omap-fixes.

Regards,

Tony

maintainer
#42 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 11 lines · Tony Lindgren
Quoted 7 lines · Russell King - ARM Linux
Quoted 2 lines · Tony Lindgren

Anyways, I can debug the DEBUG_LL booting issue further if the patch I posted does not help.

This is what I ended up with earlier today to make the debug code work both in the decompressor and in the kernel - once I had it working I haven't bothered putting any more effort into it.

Hmm I have DEBUG_LL working fine (execept not for the uncompress code).

Quoted 8 lines

Looks like the only issue I have with my 4430 es1.0 blaze board is that it won't boot reliably unless I disable l2x0_init.

Have you guys seen this issue?

Of course there are all kinds of omap4 warnings there, but after disabling l2x0_init I was able to run apt-get dist-upgrade on my board. This is with what I have queued up in omap-fixes.

Here's one more es1.0 fix after the recent USB changes.

Regards,

Tony

Author: Tony Lindgren <[email protected]>
Date:   Tue Jan 11 15:03:03 2011 -0800

omap4: Fix ULPI PHY init for ES1.0 SDP

Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
enable the ehci port on 4430SDP) added code to enable EHCI support on 4430sdp board.

Looks like the ULPI pin does not seem to be muxed properly on ES1.0 SDP and this causes the system to reboot when the ULPI PHY is enabled.

Fix this by muxing the pin, this is the same setting for both ES1.0 and ES2.0. Also add checking for gpio_request.

Cc Keshava Munegowda <keshava_mgowda at ti.com
arch/arm/mach-omap2/board-4430sdp.c +6 -4
@@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
+	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else
@@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
 	omap4_twl6030_hsmmc_init(mmc);
 
 	/* Power on the ULPI PHY */
-	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
-		/* FIXME: Assumes pad is already muxed for GPIO mode */
-		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+	if (status)
+		pr_err("%s: Could not get USBB1 PHY GPIO\n");
+	else
 		gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
-	}
+
 	usb_ehci_init(&ehci_pdata);
 	usb_musb_init(&musb_board_data);
 
#43 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 37 lines · Tony Lindgren

Here's one more es1.0 fix after the recent USB changes.

Regards,

Tony

Author: Tony Lindgren <[email protected]>
Date:   Tue Jan 11 15:03:03 2011 -0800

omap4: Fix ULPI PHY init for ES1.0 SDP

Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
enable the ehci port on 4430SDP) added code to enable EHCI support on 4430sdp board.

Looks like the ULPI pin does not seem to be muxed properly on ES1.0 SDP and this causes the system to reboot when the ULPI PHY is enabled.

Fix this by muxing the pin, this is the same setting for both ES1.0 and ES2.0. Also add checking for gpio_request.

Cc Keshava Munegowda <[email protected]
arch/arm/mach-omap2/board-4430sdp.c +1 -0
@@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
+	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_4430sdp_init(void) · line 581

Quoted 6 lines
arch/arm/mach-omap2/board-4430sdp.c +0 -3
@@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
 	omap4_twl6030_hsmmc_init(mmc);
 
 	/* Power on the ULPI PHY */
-	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
-		/* FIXME: Assumes pad is already muxed for GPIO mode */
-		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY

VMDM_3V3");

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_4430sdp_init(void) · line 580

Quoted 1 line
arch/arm/mach-omap2/board-4430sdp.c +1 -0
+	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY

VMDM_3V3");

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_4430sdp_init(void) · line 582

Quoted 2 lines
arch/arm/mach-omap2/board-4430sdp.c +2 -0
+	if (status)
+		pr_err("%s: Could not get USBB1 PHY GPIO\n");

Tony,

This throws up a build warning as there's no parameter corresponding to the %s. Showed up in linux-next as of today.

- Anand

#44 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 8 lines · Anand Gadiyar

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_4430sdp_init(void)

Quoted 4 lines · Tony Lindgren
arch/arm/mach-omap2/board-4430sdp.c +0 -3
 	/* Power on the ULPI PHY */
-	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
-		/* FIXME: Assumes pad is already muxed for GPIO mode */
-		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY

VMDM_3V3");

Review

Quoted 1 line
(quoted diff) +1 -0
+	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY

VMDM_3V3");

Quoted 7 lines

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_4430sdp_init(void) · line 582

Quoted 2 lines
arch/arm/mach-omap2/board-4430sdp.c +2 -0
+	if (status)
+		pr_err("%s: Could not get USBB1 PHY GPIO\n");

Tony,

This throws up a build warning as there's no parameter corresponding to the %s. Showed up in linux-next as of today.

It's pretty obvious that the above is wrong, and the compiler would have caught it with a warning when building it. Was the above patch not build-tested before it was committed?

Given the very sorry state of OMAP in mainline at present, I'm surprised that this kind of stuff is still going on...

maintainer
#45 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 9 lines · Russell King - ARM Linux
Quoted 8 lines · Anand Gadiyar

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_4430sdp_init(void)

Quoted 4 lines · Tony Lindgren
arch/arm/mach-omap2/board-4430sdp.c +0 -3
 	/* Power on the ULPI PHY */
-	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
-		/* FIXME: Assumes pad is already muxed for GPIO mode */
-		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY

VMDM_3V3");

Review

Quoted 1 line
(quoted diff) +1 -0
+	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY

VMDM_3V3");

Quoted 7 lines
Quoted 7 lines

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_4430sdp_init(void) · line 582

Quoted 2 lines
arch/arm/mach-omap2/board-4430sdp.c +2 -0
+	if (status)
+		pr_err("%s: Could not get USBB1 PHY GPIO\n");

Tony,

This throws up a build warning as there's no parameter corresponding to the %s. Showed up in linux-next as of today.

Oops, sorry, will fix.

Quoted 3 lines

It's pretty obvious that the above is wrong, and the compiler would have caught it with a warning when building it. Was the above patch not build-tested before it was committed?

Sure, boot tested it but missed the warning though.

Quoted 2 lines

Given the very sorry state of OMAP in mainline at present, I'm surprised that this kind of stuff is still going on...

At least I boot test the patches I send..

Regards,

Tony

#46 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 5 lines · Tony Lindgren
Quoted 2 lines · Russell King - ARM Linux

Given the very sorry state of OMAP in mainline at present, I'm surprised that this kind of stuff is still going on...

At least I boot test the patches I send..

Which is why OMAP3 and OMAP4 can't be built in mainline because they spit out lots of compile errors in the OMAP code... As they won't even compile they couldn't have been boot tested.

maintainer
#47 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 10 lines · Russell King - ARM Linux
Quoted 5 lines · Tony Lindgren
Quoted 2 lines · Russell King - ARM Linux

Given the very sorry state of OMAP in mainline at present, I'm surprised that this kind of stuff is still going on...

At least I boot test the patches I send..

Which is why OMAP3 and OMAP4 can't be built in mainline because they spit out lots of compile errors in the OMAP code... As they won't even compile they couldn't have been boot tested.

Huh? I have fixes queued up for the issues that showed up with merges with various other trees.

I certainly make sure everything I merge is compile and boot tested. Sure there are still tons of issues still remaining, but people are working on those. That's why we have the -rc releases.

Tony

#48 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

In reply to Russell King - ARM Linux
Quoted 10 lines · Russell King - ARM Linux
Quoted 5 lines · Tony Lindgren
Quoted 2 lines · Russell King - ARM Linux

Given the very sorry state of OMAP in mainline at present, I'm surprised that this kind of stuff is still going on...

At least I boot test the patches I send..

Which is why OMAP3 and OMAP4 can't be built in mainline because they spit out lots of compile errors in the OMAP code... As they won't even compile they couldn't have been boot tested.

Current mainline != the patches that Tony sent to Linus[1].

The patches that Tony sent to Linus, which Linus merged, build fine with omap2plus_defconfig[2].

- Paul

1. Lindgren, Tony. _[GIT PULL] omap changes for v2.6.38_. Posted to the linux-kernel mailing list on 6 January 2011.
http://www.gossamer-threads.com/lists/linux/kernel/1324357 (among others)

2. Compilation log of the patches that Tony submitted for the 2.6.38 merge window (included below)

---

$ git log mainline/master --pretty=oneline | fgrep omap-for-linus |head -1
01539ba2a706ab7d35fc0667dff919ade7f87d63 Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
$ git show 01539ba2a706ab7d35fc0667dff919ade7f87d63 |head -5
commit 01539ba2a706ab7d35fc0667dff919ade7f87d63
Merge: 9e9bc97 dc69d1a
Author: Linus Torvalds <[email protected]>
Date:   Thu Jan 6 19:13:58 2011 -0800
$ git checkout dc69d1a
HEAD is now at dc69d1a... omap2: Make OMAP2PLUS select OMAP_DM_TIMER
$ make mrproper
$ make omap2plus_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
$ make -j2
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK     include/linux/version.h
  UPD     include/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  HOSTCC  scripts/genksyms/genksyms.o
  Generating include/generated/mach-types.h
  CC      kernel/bounds.s
  GEN     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  SHIPPED scripts/genksyms/lex.c
  SHIPPED scripts/genksyms/parse.h
  SHIPPED scripts/genksyms/keywords.c
  SHIPPED scripts/genksyms/parse.c
  HOSTCC  scripts/genksyms/lex.o
  GEN     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  HOSTCC  scripts/genksyms/parse.o
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
  HOSTLD  scripts/genksyms/genksyms
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/pnmtologo
  HOSTCC  scripts/mod/modpost.o
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/bin2c
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  CC      init/main.o
  HOSTCC  usr/gen_init_cpio
  GEN     usr/initramfs_data.cpio
  AS      usr/initramfs_data.o
  LD      usr/built-in.o
  CC      arch/arm/nwfpe/fpa11.o
  CC      arch/arm/nwfpe/fpa11_cpdo.o
  CC      arch/arm/nwfpe/fpa11_cpdt.o
  CC      arch/arm/nwfpe/fpa11_cprt.o
  CC      arch/arm/nwfpe/fpmodule.o
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/do_mounts.o
  CC      arch/arm/nwfpe/fpopcode.o
  CC      arch/arm/nwfpe/softfloat.o
  CC      init/do_mounts_rd.o
  CC      arch/arm/nwfpe/single_cpdo.o
  CC      init/do_mounts_initrd.o
  CC      arch/arm/nwfpe/double_cpdo.o
  AS      arch/arm/nwfpe/entry.o
  LD      arch/arm/nwfpe/nwfpe.o
  LD      arch/arm/nwfpe/built-in.o
  CC      init/initramfs.o
  CC      init/calibrate.o
  CC      init/version.o
  LD      init/mounts.o
  CC      arch/arm/vfp/vfpmodule.o
  LD      init/built-in.o
  CC      arch/arm/kernel/elf.o
  AS      arch/arm/vfp/entry.o
  AS      arch/arm/vfp/vfphw.o
  CC      arch/arm/vfp/vfpsingle.o
  AS      arch/arm/kernel/entry-armv.o
  AS      arch/arm/kernel/entry-common.o
  CC      arch/arm/kernel/irq.o
  CC      arch/arm/vfp/vfpdouble.o
  CC      arch/arm/kernel/process.o
  LD      arch/arm/vfp/vfp.o
  LD      arch/arm/vfp/built-in.o
  CC      arch/arm/mm/dma-mapping.o
  CC      arch/arm/kernel/ptrace.o
  CC      arch/arm/mm/extable.o
  CC      arch/arm/mm/fault.o
  CC      arch/arm/kernel/return_address.o
arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables"
arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables"
  CC      arch/arm/kernel/setup.o
  CC      arch/arm/mm/init.o
  CC      arch/arm/mm/iomap.o
  CC      arch/arm/kernel/signal.o
  CC      arch/arm/mm/fault-armv.o
  CC      arch/arm/kernel/sys_arm.o
  CC      arch/arm/mm/flush.o
  CC      arch/arm/kernel/stacktrace.o
  CC      arch/arm/mm/ioremap.o
  CC      arch/arm/kernel/time.o
  CC      arch/arm/mm/mmap.o
  CC      arch/arm/kernel/traps.o
  CC      arch/arm/mm/pgd.o
  CC      arch/arm/mm/mmu.o
  CC      arch/arm/kernel/leds.o
  CC      arch/arm/kernel/armksyms.o
  CC      arch/arm/mm/vmregion.o
  CC      arch/arm/mm/proc-syms.o
  CC      arch/arm/kernel/module.o
  CC      arch/arm/mm/alignment.o
  CC      arch/arm/kernel/smp.o
  AS      arch/arm/mm/abort-ev6.o
  AS      arch/arm/mm/abort-ev7.o
  AS      arch/arm/mm/pabort-v6.o
  AS      arch/arm/mm/pabort-v7.o
  AS      arch/arm/mm/cache-v6.o
  AS      arch/arm/mm/cache-v7.o
  CC      arch/arm/mm/copypage-v6.o
  CC      arch/arm/mm/context.o
  CC      a2/powerdomains44xx_data.o
  CC      arch/arm/mach-omap2/clockdomain.o
  CC      arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.o
  CC      arch/arm/mach-omap2/clockdomains44xx_data.o
  CC      arch/arm/mach-omap2/clock.o
  CC      arch/arm/mach-omap2/clock_common_data.o
  CC      arch/arm/mach-omap2/clkt_dpll.o
  CC      kernel/exec_domain.o
  CC      arch/arm/mach-omap2/clkt_clksel.o
  CC      arch/arm/mach-omap2/clock2xxx.o
  CC      arch/arm/mach-omap2/clkt2xxx_sys.o
  CC      arch/arm/mach-omap2/clkt2xxx_dpllcore.o
  CC      kernel/panic.o
  CC      arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.o
  CC      arch/arm/mach-omap2/clkt2xxx_apll.o
  CC      arch/arm/mach-omap2/clkt2xxx_osc.o
  CC      kernel/printk.o
  CC      arch/arm/mach-omap2/clock2420_data.o
  CC      arch/arm/mach-omap2/clock2430.o
  CC      arch/arm/mach-omch/arm/mach-omap2/usb-musb.o
  CC      arch/arm/mach-omap2/usb-tusb6010.o
  CC      kernel/nsproxy.o
  CC      arch/arm/mach-omap2/usb-ehci.o
  CC      kernel/srcu.o
  CC      arch/arm/mach-omap2/gpmc-onenand.o
  CC      kernel/semaphore.o
  CC      arch/arm/mach-omap2/gpmc-nand.o
  CC      arch/arm/mach-omap2/gpmc-smc91x.o
  CC      kernel/notifier.o
  CC      arch/arm/mach-omap2/gpmc-smsc911x.o
  CC      kernel/ksysfs.o
  LD      arch/arm/mach-omap2/built-in.o
  CC      kernel/pm_qos_params.o
  CC      mm/bootmem.o
  CC      kernel/sched_clock.o
  CC      mm/filemap.o
  CC      kernel/cred.o
  CC      kernel/async.o
  CC      kernel/range.o
  CC      kernel/jump_label.o
  CC      mm/mempool.o
  CC      kernel/groups.o
  CC      mm/oom_kill.o
  CC      kernel/freezer.o
  CC      kernel/profile.o
  CC      mm/fadvise.o
  CC      mm/maccess.o
  CC      kernel/stacktrace.o
  CC      mm/page_alloc.o
  CC      kernel/irq/irqdesc.o
  CC      kernel/irq/handle.o
  CC      kernel/irq/manage.o
  CC      kernel/irq/spurious.o
  CC      kernel/irq/resend.o
  CC      mm/page-writeback.o
  CC      kernel/irq/chip.o
  CC      kernel/irq/dummychip.o
  CC      kernel/irq/devres.o
  CC      kernel/irq/autoprobe.o
  CC      mm/readahead.o
  CC      kernel/irq/proc.o
  CC      kernel/irq/pm.o
  LD      kernel/irq/built-in.o
  CC      kernel/power/main.o
  CC      mm/swap.o
  CC      kernel/power/console.o
  CC      kernel/power/process.o
  CC      mm/truncate.o
  CC      kernel/power/suspend.o
  CC      mm/vmscan.o
  CC      kernel/power/nvs.o
  CC      kernel/power/poweroff.o
  LD      kernel/power/built-in.o
  CC      kernel/time/timekeeping.o
  CC      kernel/time/ntp.o
  CC      kernel/time/clocksource.o
  CC      mm/shmem.o
  CC      kernel/time/jiffies.o
  CC      kernel/time/timer_list.o
  CC      kernel/time/timecompare.o
  CC      kernel/time/timeconv.o
  CC      kernel/time/clockevents.o
  CC      mm/prio_tree.o
  CC      mm/util.o
  CC      kernel/time/tick-common.o
  CC      kernel/time/tick-broadcast.o
  CC      mm/mmzone.o
  CC      kernel/time/tick-oneshot.o
  CC      mm/vmstat.o
  CC      kernel/time/tick-sched.o
  CC      kernel/time/timer_stats.o
  CC      mm/backing-dev.o
  LD      kernel/time/built-in.o
  CC      kernel/trace/trace_clock.o
  CC      kernel/trace/ring_buffer.o
  CC      mm/page_isolation.o
  CC      mm/mm_init.o
  CC      mm/mmu_context.o
  CC      mm/percpu.o
  CC      kernel/trace/trace.o
  CC      mm/fremap.o
  CC      mm/highmem.o
  CC      mm/madvise.o
  CC      mm/memory.o
  CC      kernel/trace/trace_output.o
  CC      kernel/trace/trace_stat.o
  CC      mm/mincore.o
  CC      kernel/trace/trace_printk.o
  CC      mm/mlock.o
  CC      kernel/trace/trace_sched_switch.o
  CC      mm/mmap.o
  CC      kernel/trace/trace_nop.o
  CC      kernel/trace/blktrace.o
  CC      mm/mprotect.o
  CC      kernel/trace/trace_events.o
  CC      mm/mremap.o
  CC      mm/msync.o
  CC      kernel/trace/trace_export.o
  CC      mm/rmap.o
  CC      kernel/trace/trace_event_perf.o
  CC      kernel/trace/trace_events_filter.o
  CC      mm/vmalloc.o
  CC      kernel/trace/trace_kprobe.o
  CC      mm/pagewalk.o
  CC      mm/init-mm.o
  CC      mm/memblock.o
  CC      kernel/trace/power-traces.o
  CC      mm/page_io.o
  CC      mm/swap_state.o
  LD      kernel/trace/built-in.o
  CC      kernel/mutex-debug.o
  CC      mm/swapfile.o
  CC      kernel/lockdep.o
  CC      mm/thrash.o
  CC      mm/dmapool.o
  CC      mm/slab.o
  CC      kernel/lockdep_proc.o
  CC      kernel/futex.o
  CC      kernel/rtmutex.o
  LD      mm/built-in.o
  CC      fs/open.o
  CC      kernel/smp.o
  CC      kernel/spinlock.o
  CC      kernel/uid16.o
  CC      fs/read_write.o
  CC      kernel/module.o
  CC      fs/file_table.o
  CC      fs/super.o
  CC      kernel/kallsyms.o
  CC      fs/char_dev.o
  CC      kernel/acct.o
  CC      fs/stat.o
  CC      kernel/kexec.o
  CC      fs/exec.o
  GZIP    kernel/config_data.gz
  CC      kernel/stop_machine.o
  CC      kernel/kprobes.o
  CC      fs/pipe.o
  CC      kernel/rcutree.o
  CC      fs/namei.o
  CC      kernel/utsname_sysctl.o
  CC      kernel/tracepoint.o
  CC      kernel/elfcore.o
  CC      kernel/sched_cpupri.o
  CC      kernel/irq_work.o
  CC      fs/fcntl.o
  CC      kernel/perf_event.o
  CC      fs/ioctl.o
  CC      fs/readdir.o
  CC      fs/select.o
  CC      fs/fifo.o
  CC      kernel/hw_breakpoint.o
  CC      fs/dcache.o
  CC      kernel/time.o
  IKCFG   kernel/config_data.h
  CC      kernel/configs.o
  CC      fs/inode.o
  LD      kernel/built-in.o
  CC      ipc/util.o
  CC      ipc/msgutil.o
  CC      fs/attr.o
  CC      ipc/msg.o
  CC      fs/bad_inode.o
  CC      ipc/sem.o
  CC      fs/file.o
  CC      fs/filesystems.o
  CC      ipc/shm.o
  CC      fs/namespace.o
  CC      ipc/ipcns_notifier.o
  CC      ipc/syscall.o
  CC      ipc/ipc_sysctl.o
  CC      ipc/mqueue.o
  CC      fs/seq_file.o
  CC      ipc/mq_sysctl.o
  CC      fs/xattr.o
  LD      ipc/built-in.o
  CC      fs/libfs.o
  CC      fs/fs-writeback.o
  CC      security/keys/gc.o
  CC      security/keys/key.o
  CC      security/keys/keyring.o
  CC      fs/pnode.o
  CC      fs/drop_caches.o
  CC      fs/splice.o
  CC      security/keys/keyctl.o
  CC      security/keys/permission.o
  CC      fs/sync.o
  CC      security/keys/process_keys.o
  CC      fs/utimes.o
  CC      security/keys/request_key.o
  CC      fs/stack.o
  CC      security/keys/request_key_auth.o
  CC      fs/fs_struct.o
  CC      security/keys/user_defined.o
  CC      fs/statfs.o
  rs/mtd/onenand/built-in.o
  LD      drivers/mtd/tests/built-in.o
  CC      drivers/mtd/ubi/vtbl.o
  CC      drivers/mtd/ubi/vmt.o
  CC      fs/ubifs/sb.o
  CC      drivers/mtd/ubi/upd.o
  CC      drivers/mtd/ubi/build.o
  CC      fs/ubifs/io.o
  CC      drivers/mtd/ubi/cdev.o
  CC      fs/ubifs/tnc.o
  CC      drivers/mtd/ubi/kapi.o
  CC      drivers/mtd/ubi/eba.o
  CC      fs/ubifs/master.o
  CC      fs/ubifs/scan.o
  CC      drivers/mtd/ubi/io.o
  CC      fs/ubifs/replay.o
  CC      drivers/mtd/ubi/wl.o
  CC      fs/ubifs/log.o
  CC      drivers/mtd/ubi/scan.o
  CC      fs/ubifs/commit.o
  CC      fs/ubifs/gc.o
  CC      drivers/mtd/ubi/misc.o
  LD      drivers/mtd/ubi/ubi.o
  LD      drivers/mtd/ubi/built-in.o
  LD      drivers/mtd/mtd.o
  LD      drivers/mtd/built-in.o
  CC      drivers/net/mii.o
  CC      fs/ubifs/orphan.o
  CC      fs/ubifs/budget.o
  LD      drivers/net/arm/built-in.o
  CC      drivers/net/phy/phy.o
  CC      fs/ubifs/find.o
  CC      drivers/net/phy/phy_device.o
  CC      fs/ubifs/tnc_commit.o
  CC      fs/ubifs/compress.o
  CC      drivers/net/phy/mdio_bus.o
  CC      fs/ubifs/lpt.o
  CC      drivers/net/phy/smsc.o
  LD      drivers/net/phy/libphy.o
  LD      drivers/net/phy/built-in.o
  CC      drivers/net/usb/asix.o
  CC      fs/ubifs/lprops.o
  CC      fs/ubifs/recovery.o
  CC      drivers/net/usb/cdc_ether.o
  CC      drivers/net/usb/net1080.o
  CC      fs/ubifs/ioctl.o
  CC      fs/ubifs/lpt_commit.o
  CC      drivers/net/usb/cdc_subset.o
  CC      drivers/net/usb/zaurus.o
  CC      fs/ubifs/tnc_misc.o
  CC      drivers/net/usb/usbnet.o
  LD      fs/ubifs/ubifs.o
  LD      fs/ubifs/built-in.o
  CC      fs/eventpoll.o
  CC      fs/anon_inodes.o
  LD      drivers/net/usb/built-in.o
  CC      fs/signalfd.o
  LD      drivers/net/wireless/built-in.o
  LD      drivers/net/wireless/libertas/built-in.o
  CC [M]  drivers/net/wireless/libertas/cfg.o
  CC      fs/timerfd.o
  CC      fs/eventfd.o
  CC [M]  drivers/net/wireless/libertas/cmd.o
  CC      fs/aio.o
  CC      fs/locks.o
  CC [M]  drivers/net/wireless/libertas/cmdresp.o
  CC [M]  drivers/net/wireless/libertas/debugfs.o
  CC      fs/binfmt_misc.o
  CC [M]  drivers/net/wireless/libertas/ethtool.o
  CC      fs/binfmt_script.o
  CC      fs/binfmt_elf.o
  CC [M]  drivers/net/wireless/libertas/main.o
  CC      fs/posix_acl.o
  CC [M]  drivers/net/wireless/libertas/rx.o
  CC      fs/xattr_acl.o
  CC      fs/dcookies.o
  CC [M]  drivers/net/wireless/libertas/tx.o
  LD      fs/built-in.o
  CC [M]  drivers/net/wireless/libertas/if_sdio.o
  LD      drivers/platform/built-in.o
  CC      drivers/power/power_supply_core.o
  CC      drivers/power/power_supply_sysfs.o
  LD      drivers/power/power_supply.o
  LD      drivers/power/built-in.o
  CC [M]  drivers/net/wireless/libertas/if_usb.o
  LD      sound/built-in.o
  CC [M]  sound/sound_core.o
  LD      sound/arm/built-in.o
  LD      sound/atmel/built-in.o
  LD      sound/core/oss/built-in.o
  CC [M]  sound/core/oss/mixer_oss.o
  LD [M]  drivers/net/wireless/libertas/libertas.o
  LD [M]  drivers/net/wireless/libertas/usb8xxx.o
  LD [M]  drivers/net/wireless/libertas/libertas_sdio.o
  CC      drivers/net/ks8851.o
  CC [M]  sound/core/oss/pcm_oss.o
  CC      drivers/net/ks8851_mll.o
  CC      drivers/net/Space.o
  CC      drivers/net/loopback.o
  CC [M]  sound/core/oss/pcm_plugin.o
  CC      drivers/net/smc91x.o
  CC [M]  sound/core/oss/io.o
  CC [M]  sound/core/oss/copy.o
  CC [M]  sound/core/oss/linear.o
  CC      drivers/net/smsc911x.o
  CC [M]  sound/core/oss/mulaw.o
  CC [M]  sound/core/oss/route.o
  CC [M]  sound/core/oss/rate.o
  LD [M]  sound/core/oss/snd-mixer-oss.o
  LD [M]  sound/core/oss/snd-pcm-oss.o
  CC [M]  sound/core/hwdep.o
  LD      drivers/net/built-in.o
  CC      drivers/regulator/core.o
  CC [M]  sound/core/memalloc.o
  CC [M]  sound/core/pcm.o
  CC      drivers/regulator/dummy.o
  CC      drivers/regulator/fixed.o
  CC [M]  sound/core/pcm_native.o
  CC      drivers/regulator/twl-regulator.o
  CC      drivers/regulator/tps65023-regulator.o
  CC      drivers/regulator/tps6507x-regulator.ooc/blackfin/built-in.o
  LD      sound/soc/codecs/built-in.o
  CC [M]  sound/soc/codecs/twl4030.o
  LD [M]  sound/soc/codecs/snd-soc-twl4030.o
  LD      sound/soc/davinci/built-in.o
  LD      sound/soc/ep93xx/built-in.o
  LD      sound/soc/fsl/built-in.o
  LD      sound/soc/imx/built-in.o
  LD      sound/soc/jz4740/built-in.o
  LD      sound/soc/kirkwood/built-in.o
  LD      sound/soc/nuc900/built-in.o
  LD      sound/soc/omap/built-in.o
  CC [M]  sound/soc/omap/omap-mcbsp.o
  CC      drivers/serial/8250_early.o
  CC      drivers/serial/omap-serial.o
  CC [M]  sound/soc/omap/omap-pcm.o
  CC [M]  sound/soc/omap/omap3pandora.o
  LD      drivers/serial/built-in.o
  CC      drivers/spi/spi.o
  CC      drivers/spi/omap2_mcspi.o
  LD [M]  sound/soc/omap/snd-soc-omap.o
  LD [M]  sound/soc/omap/snd-soc-omap-mcbsp.o
  LD [M]  sound/soc/omap/snd-soc-omap3pandora.o
  LD      sound/soc/pxa/built-in.o
  LD      sound/soc/s3c24xx/built-in.o
  LD      sound/soc/s6000/built-in.o
  LD      sound/soc/sh/built-in.o
  LD      sound/soc/txx9/built-in.o
  LD [M]  sound/soc/snd-soc-core.o
  LD      sound/sparc/built-in.o
  LD      sound/spi/built-in.o
  LD      sound/synth/built-in.o
  LD      sound/usb/built-in.o
  CC [M]  sound/usb/card.o
  LD    drivers/video/logo/logo_superh_vga16.c
  LOGO    drivers/video/logo/logo_blackfin_clut224.c
  LOGO    drivers/video/logo/logo_dec_clut224.c
  LOGO    drivers/video/logo/logo_m32r_clut224.c
  LOGO    drivers/video/logo/logo_mac_clut224.c
  LOGO    drivers/video/logo/logo_parisc_clut224.c
  LOGO    drivers/video/logo/logo_sgi_clut224.c
  LOGO    drivers/video/logo/logo_spe_clut224.c
  LOGO    drivers/video/logo/logo_sun_clut224.c
  LOGO    drivers/video/logo/logo_superh_clut224.c
  CC      drivers/video/logo/logo_linux_mono.o
  CC      drivers/video/logo/logo_linux_vga16.o
  CC      drivers/video/logo/logo_linux_cock.o
  CC      net/ipv4/ip_input.o
  CC      lib/bitrev.o
  CC      lib/crc-ccitt.o
  CC      net/ipv4/ip_fragment.o
  CC      lib/crc16.o
  CC      lib/crc-t10dif.o
  CC      lib/crc-itu-t.o
  HOSTCC  lib/gen_crc32table
  CC      lib/crc7.o
  CC      net/ipv4/ip_forward.o
  CC      lib/libcrc32c.o
  CC      lib/lzo/lzo1x_compress.o
  CC      lib/lzo/lzo1x_decompress.o
  CC      net/ipv4/ip_options.o
  LD      lib/lzo/lzo_compress.o
  LD      lib/lzo/lzo_decompress.o
  LD      lib/lzo/built-in.o
  CC      lib/zlib_deflate/deflate.o
  CC      lib/zlib_deflate/deftree.o
  CC      net/ipv4/ip_output.o
  CC      lib/zlib_deflate/deflate_syms.o
  LD      lib/zlib_deflate/zlib_deflate.o
  LD      lib/zlib_deflate/built-in.o
  CC      lib/zlib_inflate/inffast.o
  CC      lib/zlib_inflate/inflate.o
  CC      lib/zlib_inflate/infutil.o
  CC      lib/zlib_inflate/inftrees.o
  CC      lib/zlib_inflate/inflate_syms.o
  LD      lib/zlib_inflate/zlib_inflate.o
  LD      lib/zlib_inflate/built-in.o
  CC      lib/percpu_counter.o
  CC      net/ipv4/ip_sockglue.o
  CC      lib/nlattr.o
  CC      lib/atomic64.o
  CC      lib/argv_split.o
  CC      net/ipv4/inet_hashtables.o
  CC      lib/cmdline.o
  CC      lib/cpumask.o
  CC      lib/ctype.o
  CC      lib/dec_and_lock.o
  CC      lib/decompress.o
  CC      lib/decompress_inflate.o
  CC      net/ipv4/inet_timewait_sock.o
  CC      lib/dump_stack.o
  CC      lib/extable.o
  CC      lib/flex_array.o
  CC      lib/idr.o
  CC      net/ipv4/inet_connection_sock.o
  CC      lib/int_sqrt.o
  CC      lib/ioremap.o
  CC      lib/irq_regs.o
  CC      lib/is_single_threaded.o
  CC      net/ipv4/tcp.o
  CC      lib/klist.o
  CC      lib/kobject.o
  CC      lib/kobject_uevent.o
  CC      lib/kref.o
  CC      net/ipv4/tcp_input.o
  CC      lib/plist.o
  CC      lib/prio_heap.o
  CC      lib/prio_tree.o
  CC      lib/proportions.o
  CC      lib/radix-tree.o
  CC      lib/ratelimit.o
  CC      lib/rbtree.o
  CC      lib/reciprocal_div.o
  CC      lib/rwsem-spinlock.o
  CC      lib/sha1.o
  CC      lib/show_mem.o
  CC      lib/string.o
  CC      net/ipv4/tcp_output.o
  CC      lib/vsprintf.o
  GEN     lib/crc32table.h
  AR      lib/lib.a
  CC      lib/crc32.o
  CC      net/ipv4/tcp_timer.o
  LD      lib/built-in.o
  CC      net/ipv4/tcp_ipv4.o
  CC      net/ipv4/tcp_minisocks.o
  CC      net/ipv4/tcp_cong.o
  CC      net/ipv4/datagram.o
  CC      net/key/af_key.o
  CC      net/ipv4/raw.o
  CC      net/ipv4/udp.o
  LD      net/key/built-in.o
  CC      net/ipv4/udplite.o
  CC      net/ipv4/arp.o
  CC      net/ipv4/icmp.o
  CC      net/ipv4/devinet.o
  CC      net/ipv4/af_inet.o
  LD      net/mac80211/built-in.o
  CC [M]  net/mac80211/main.o
  CC      net/ipv4/igmp.o
  CC [M]  net/mac80211/status.o
  CC [M]  net/mac80211/sta_info.o
  CC [M]  net/mac80211/wep.o
  CC      net/ipv4/fib_frontend.o
  CC [M]  net/mac80211/wpa.o
  CC [M]  net/mac80211/scan.o
  CC      net/ipv4/fib_semantics.o
  CC      net/ipv4/inet_fragment.o
  CC [M]  net/mac80211/offchannel.o
  CC      net/ipv4/sysctl_net_ipv4.o
  CC [M]  net/mac80211/ht.o
  CC      net/ipv4/fib_hash.o
  CC [M]  net/mac80211/agg-tx.o
  CC      net/ipv4/proc.o
  CC      net/ipv4/xfrm4_mode_beet.o
  CC [M]  net/mac80211/agg-rx.o
  CC      net/ipv4/xfrm4_mode_transport.o
  CC [M]  net/mac80211/ibss.o
  CC      net/ipv4/xfrm4_mode_tunnel.o
  CC [M]  net/mac80211/mlme.o
  CC      net/ipv4/ipconfig.o
  CC [M]  net/mac80211/work.o
  CC      net/ipv4/netfilter.o
  CC [M]  net/mac80211/iface.o
  LD      net/ipv4/netfilter/built-in.o
  CC      net/ipv4/inet_diag.o
  CC [M]  net/mac80211/rate.o
  CC      net/ipv4/tcp_diag.o
  CC      net/ipv4/tcp_cubic.o
  CC [M]  net/mac80211/michael.o
  CC [M]  net/mac80211/tkip.o
  CC      net/ipv4/xfrm4_policy.o
  CC [M]  net/mac80211/aes_ccm.o
  CC      net/ipv4/xfrm4_state.o
  CC [M]  net/mac80211/aes_cmac.o
  CC      net/ipv4/xfrm4_input.o
  CC [M]  net/mac80211/cfg.o
  CC      net/ipv4/xfrm4_output.o
  CC [M]  net/mac80211/rx.o
  LD      net/ipv4/built-in.o
  CC [M]  net/mac80211/spectmgmt.o
  CC [M]  net/mac80211/tx.o
  CC      net/netfilter/core.o
  CC      net/netfilter/nf_log.o
  CC [M]  net/mac80211/key.o
  CC      net/netfilter/nf_queue.o
  CC [M]  net/mac80211/util.o
  CC      net/netfilter/nf_sockopt.o
  CC [M]  net/mac80211/wme.o
  LD      net/netfilter/netfilter.o
  LD      net/netfilter/built-in.o
  CC [M]  net/mac80211/event.o
  CC [M]  net/mac80211/chan.o
  CC [M]  net/mac80211/pm.o
  CC [M]  net/mac80211/rc80211_pid_algo.o
  CC [M]  net/mac80211/rc80211_minstrel.o
  CC [M]  net/mac80211/rc80211_minstrel_ht.o
  CC      net/netlink/af_netlink.o
  LD [M]  net/mac80211/mac80211.o
  CC      net/packet/af_packet.o
  CC      net/netlink/genetlink.o
  LD      net/packet/built-in.o
  CC      net/sched/sch_generic.o
  CC      net/sched/sch_mq.o
  LD      net/netlink/built-in.o
  CC      net/sunrpc/clnt.o
  LD      net/sched/built-in.o
  CC      net/unix/af_unix.o
  CC      net/sunrpc/xprt.o
  CC      net/unix/garbage.o
  CC      net/unix/sysctl_net_unix.o
  CC      net/sunrpc/socklib.o
  LD      net/unix/unix.o
  LD      net/unix/built-in.o
  CC      net/sunrpc/xprtsock.o
  CC      net/sunrpc/sched.o
  CC      net/sunrpc/auth.o
  CC      net/sunrpc/auth_null.o
  CC      net/sunrpc/auth_unix.o
  CC      net/wireless/wext-core.o
  CC      net/sunrpc/auth_generic.o
  CC      net/wireless/wext-proc.o
  CC      net/sunrpc/svc.o
  CC      net/wireless/wext-spy.o
  CC [M]  net/wireless/core.o
  CC      net/sunrpc/svcsock.o
  CC [M]  net/wireless/sysfs.o
  CC [M]  net/wireless/radiotap.o
  CC      net/sunrpc/svcauth.o
  CC [M]  net/wireless/util.o
  CC      net/sunrpc/svcauth_unix.o
  CC [M]  net/wireless/reg.o
  CC      net/sunrpc/addr.o
  CC      net/sunrpc/rpcb_clnt.o
  CC [M]  net/wireless/scan.o
  CC      net/sunrpc/timer.o
  CC [M]  net/wireless/nl80211.o
  CC      net/sunrpc/xdr.o
  CC      net/sunrpc/sunrpc_syms.o
  CC      net/sunrpc/cache.o
  CC      net/sunrpc/rpc_pipe.o
  CC [M]  net/wireless/mlme.o
  CC      net/sunrpc/svc_xprt.o
  CC [M]  net/wireless/ibss.o
  CC [M]  net/wireless/sme.o
  CC      net/sunrpc/stats.o
  CC [M]  net/wireless/chan.o
  CC      net/sunrpc/sysctl.o
  CC [M]  net/wireless/ethtool.o
  CC      net/sunrpc/auth_gss/auth_gss.o
  CC [M]  net/wireless/wext-compat.o
  CC      net/sunrpc/auth_gss/gss_generic_token.o
  CC [M]  net/wireless/wext-sme.o
  CC      net/sunrpc/auth_gss/gss_mech_switch.o
  CC [M]  net/wireless/lib80211.o
  CC      net/sunrpc/auth_gss/svcauth_gss.o
  LD      net/wireless/built-in.o
  LD [M]  net/wireless/cfg80211.o
  CC      net/xfrm/xfrm_policy.o
  CC      net/sunrpc/auth_gss/gss_krb5_mech.o
  CC      net/sunrpc/auth_gss/gss_krb5_seal.o
  CC      net/sunrpc/auth_gss/gss_krb5_unseal.o
  CC      net/sunrpc/auth_gss/gss_krb5_seqnum.o
  CC      net/xfrm/xfrm_state.o
  CC      net/sunrpc/auth_gss/gss_krb5_wrap.o
  CC      net/sunrpc/auth_gss/gss_krb5_crypto.o
  CC      net/sunrpc/auth_gss/gss_krb5_keys.o
  CC      net/xfrm/xfrm_hash.o
  LD      net/sunrpc/auth_gss/auth_rpcgss.o
  LD      net/sunrpc/auth_gss/rpcsec_gss_krb5.o
  LD      net/sunrpc/auth_gss/built-in.o
  LD      net/sunrpc/sunrpc.o
  LD      net/sunrpc/built-in.o
  CC      net/sysctl_net.o
  CC      net/xfrm/xfrm_input.o
  CC      net/xfrm/xfrm_output.o
  CC      net/xfrm/xfrm_algo.o
  CC      net/xfrm/xfrm_sysctl.o
  CC      net/xfrm/xfrm_user.o
  LD      net/xfrm/built-in.o
  LD      net/built-in.o
  LD      vmlinux.o
  MODPOST vmlinux.o
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
  KSYM    .tmp_kallsyms1.S
  AS      .tmp_kallsyms1.o
  LD      .tmp_vmlinux2
  KSYM    .tmp_kallsyms2.S
  AS      .tmp_kallsyms2.o
  LD      .tmp_vmlinux3
  KSYM    .tmp_kallsyms3.S
  AS      .tmp_kallsyms3.o
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready
  AS      arch/arm/boot/compressed/head.o
  Building modules, stage 2.
  GZIP    arch/arm/boot/compressed/piggy.gzip
  MODPOST 36 modules
  CC      crypto/aes_generic.mod.o
  CC      crypto/arc4.mod.o
  CC      crypto/ecb.mod.o
  CC      drivers/bluetooth/bcm203x.mod.o
  CC      drivers/bluetooth/bpa10x.mod.o
  CC      drivers/bluetooth/hci_uart.mod.o
  CC      drivers/net/wireless/libertas/libertas.mod.o
  CC      drivers/net/wireless/libertas/libertas_sdio.mod.o
  CC      drivers/net/wireless/libertas/usb8xxx.mod.o
  CC      drivers/scsi/scsi_wait_scan.mod.o
  CC      drivers/usb/gadget/g_zero.mod.o
  CC      net/bluetooth/bluetooth.mod.o
  CC      net/bluetooth/bnep/bnep.mod.o
  CC      net/bluetooth/hidp/hidp.mod.o
  CC      arch/arm/boot/compressed/misc.o
  CC      net/bluetooth/l2cap.mod.o
  CC      net/bluetooth/rfcomm/rfcomm.mod.o
  CC      net/bluetooth/sco.mod.o
  CC      arch/arm/boot/compressed/decompress.o
  CC      net/mac80211/mac80211.mod.o
  CC      net/wireless/cfg80211.mod.o
  CC      net/wireless/lib80211.mod.o
  CC      sound/core/oss/snd-mixer-oss.mod.o
  CC      sound/core/oss/snd-pcm-oss.mod.o
  CC      sound/core/snd-hwdep.mod.o
  SHIPPED arch/arm/boot/compressed/lib1funcs.S
  AS      arch/arm/boot/compressed/piggy.gzip.o
  AS      arch/arm/boot/compressed/lib1funcs.o
  LD      arch/arm/boot/compressed/vmlinux
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
  CC      sound/core/snd-page-alloc.mod.o
  CC      sound/core/snd-pcm.mod.o
  CC      sound/core/snd-rawmidi.mod.o
  CC      sound/core/snd-timer.mod.o
  CC      sound/core/snd.mod.o
  CC      sound/soc/codecs/snd-soc-twl4030.mod.o
  CC      sound/soc/omap/snd-soc-omap-mcbsp.mod.o
  CC      sound/soc/omap/snd-soc-omap.mod.o
  CC      sound/soc/omap/snd-soc-omap3pandora.mod.o
  CC      sound/soc/snd-soc-core.mod.o
  CC      sound/soundcore.mod.o
  CC      sound/usb/snd-usb-audio.mod.o
  CC      sound/usb/snd-usbmidi-lib.mod.o
  LD [M]  crypto/aes_generic.ko
  LD [M]  crypto/arc4.ko
  LD [M]  crypto/ecb.ko
  LD [M]  drivers/bluetooth/bcm203x.ko
  LD [M]  drivers/bluetooth/bpa10x.ko
  LD [M]  drivers/bluetooth/hci_uart.ko
  LD [M]  drivers/net/wireless/libertas/libertas.ko
  LD [M]  drivers/net/wireless/libertas/libertas_sdio.ko
  LD [M]  drivers/net/wireless/libertas/usb8xxx.ko
  LD [M]  drivers/scsi/scsi_wait_scan.ko
  LD [M]  drivers/usb/gadget/g_zero.ko
  LD [M]  net/bluetooth/bluetooth.ko
  LD [M]  net/bluetooth/bnep/bnep.ko
  LD [M]  net/bluetooth/hidp/hidp.ko
  LD [M]  net/bluetooth/l2cap.ko
  LD [M]  net/bluetooth/rfcomm/rfcomm.ko
  LD [M]  net/bluetooth/sco.ko
  LD [M]  net/mac80211/mac80211.ko
  LD [M]  net/wireless/cfg80211.ko
  LD [M]  net/wireless/lib80211.ko
  LD [M]  sound/core/oss/snd-mixer-oss.ko
  LD [M]  sound/core/oss/snd-pcm-oss.ko
  LD [M]  sound/core/snd-hwdep.ko
  LD [M]  sound/core/snd-page-alloc.ko
  LD [M]  sound/core/snd-pcm.ko
  LD [M]  sound/core/snd-rawmidi.ko
  LD [M]  sound/core/snd-timer.ko
  LD [M]  sound/core/snd.ko
  LD [M]  sound/soc/codecs/snd-soc-twl4030.ko
  LD [M]  sound/soc/omap/snd-soc-omap-mcbsp.ko
  LD [M]  sound/soc/omap/snd-soc-omap.ko
  LD [M]  sound/soc/omap/snd-soc-omap3pandora.ko
  LD [M]  sound/soc/snd-soc-core.ko
  LD [M]  sound/soundcore.ko
  LD [M]  sound/usb/snd-usb-audio.ko
  LD [M]  sound/usb/snd-usbmidi-lib.ko
$ 
#49 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 8 lines · Paul Walmsley
Quoted 7 lines · Russell King - ARM Linux
Quoted 5 lines · Tony Lindgren
Quoted 2 lines · Russell King - ARM Linux

Given the very sorry state of OMAP in mainline at present, I'm surprised that this kind of stuff is still going on...

At least I boot test the patches I send..

Quoted 8 lines
Quoted 3 lines

Which is why OMAP3 and OMAP4 can't be built in mainline because they spit out lots of compile errors in the OMAP code... As they won't even compile they couldn't have been boot tested.

Current mainline != the patches that Tony sent to Linus[1].

The patches that Tony sent to Linus, which Linus merged, build fine with omap2plus_defconfig[2].

Right, but is that sufficient testing?

Can I read into your statement that the only testing which was done was a build of the omap2plus defconfig? Weren't builds specific to OMAP2, OMAP3, and OMAP4 tried?

As there is stuff like:

struct clockdomain {
        const char *name;
        union {
                const char *name;
                struct powerdomain *ptr;
        } pwrdm;
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
        const u16 clktrctrl_mask;

#endif

would you consider it's a good idea to at least run a build test with an OMAP4-only configuration?

If it helps, here's what I do - not only do I run a few of the standard defconfigs in the tree, but I also run a number of platform specific builds, both covering platforms I do and do not have. I'll pick a random selection of existing build trees to rebuild and see what the results are. This shows the spread of trees which I've built over the last year - and note that many of these I don't even have:

drwxrwxr-x. 20 rmk rmk   4096 Jan 14 20:30 omap4
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:45 versatile
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:14 iop13xx
drwxrwxr-x. 20 rmk rmk   4096 Jan 13 23:10 vexpress
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:48 integrator
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:44 realview
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:10 assabet
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:07 rpc
drwxrwxr-x. 21 rmk rmk   4096 Jan  7 17:34 omap3
drwxrwxr-x. 20 rmk rmk   4096 Jan  6 14:24 nommu
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:44 omap2
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:27 omap
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:24 u300
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 19:14 pxa
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 10:30 msm
drwxrwxr-x. 21 rmk rmk   4096 Jan  4 17:25 orion-kirkwood
drwxrwxr-x. 21 rmk rmk   4096 Dec 24 11:06 ks8695
drwxrwxr-x. 21 rmk rmk   4096 Dec 16 16:12 s3c2410
drwxrwxr-x. 21 rmk rmk   4096 Dec 11 17:17 ixp4xx
drwxrwxr-x. 20 rmk rmk   4096 Oct  9 22:59 netwinder2
drwxrwxr-x. 21 rmk rmk   4096 Sep  5 23:54 ebsa285
drwxrwxr-x. 21 rmk rmk   4096 Aug  4  2010 zylonite
drwxrwxr-x. 21 rmk rmk   4096 Jul  8  2010 ep93xx
drwxrwxr-x. 21 rmk rmk   4096 Jun 29  2010 corgi
drwxrwxr-x. 21 rmk rmk   4096 Apr 25  2010 ebsa110
drwxrwxr-x. 21 rmk rmk   4096 Mar 25  2010 clps711x
drwxrwxr-x. 21 rmk rmk   4096 Mar 24  2010 ixp23xx
drwxrwxr-x. 21 rmk rmk   4096 Mar 20  2010 n2100
drwxrwxr-x. 21 rmk rmk   4096 Feb 19  2010 iop32x
drwxrwxr-x. 21 rmk rmk   4096 Jan 20  2010 mx1
drwxrwxr-x. 21 rmk rmk   4096 Jan 10  2010 w90p910evb

omap4 = 4430SDP only (I have).
omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
omap2 = H2 (whose config can be traced to 2005 from when I once had one.) omap = some random omap1 config
realview = realview eb/smp only
assabet = assabet+neponset daugter board

All those are build trees, built from my git tree with:
make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>

You can see from the above that I built a kernel for at least orion-kirkwood, msm, u300, omap, nommu trees before sending my pull to Linus on the 6th, none of which I have (ever) had hardware for. I also built omap3, omap4, and a bunch of the ARM evaluation platforms as well as older platforms like RiscPC, but those are hidden by later re-builds for work I've been doing since (which is all based upon commit 9e9bc97.)

I'm not saying that's perfect - it isn't. It's better than just testing the defconfigs - and with regular checking of kautobuild/linux-next, it seems to catch quite a bit of really silly stuff.

Please test a (small) selection of configurations to improve build coverage. Try to develop a set of configurations which trip up common issues which won't be found with the omap2plus defconfig. Don't assume that just because the omap2plus defconfig builds that it's ready.

#50 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 15 lines · Russell King - ARM Linux
Quoted 14 lines · Paul Walmsley
Quoted 10 lines · Russell King - ARM Linux
Quoted 5 lines · Tony Lindgren
Quoted 2 lines · Russell King - ARM Linux

Given the very sorry state of OMAP in mainline at present, I'm surprised that this kind of stuff is still going on...

At least I boot test the patches I send..

Which is why OMAP3 and OMAP4 can't be built in mainline because they spit out lots of compile errors in the OMAP code... As they won't even compile they couldn't have been boot tested.

Current mainline != the patches that Tony sent to Linus[1].

Quoted 7 lines
Quoted 2 lines

The patches that Tony sent to Linus, which Linus merged, build fine with omap2plus_defconfig[2].

Right, but is that sufficient testing?

Can I read into your statement that the only testing which was done was a build of the omap2plus defconfig?

No. The patches that Tony merged from me were built with omap1_defconfig and boot-tested on OMAP5912 OSK; they were built with an N8x0-specific configuration and boot-tested on N800; and they were built with omap2plus_defconfig and boot-tested on 2430SDP, OMAP3530 Beagle, DM37xx Beagle XM, and OMAP4430 ES2 Panda. A brief summary of that testing was part of the pull request that was sent to Tony[1].

The problem in this case was that I did not compile-test them with an OMAP4-only configuration - hence the clockdomain and PRM breakage.

Quoted 12 lines

Weren't builds specific to OMAP2, OMAP3, and OMAP4 tried?

As there is stuff like:

struct clockdomain {
        const char *name;
        union {
                const char *name;
                struct powerdomain *ptr;
        } pwrdm;
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
        const u16 clktrctrl_mask;
Quoted 4 lines

#endif

would you consider it's a good idea to at least run a build test with an OMAP4-only configuration?

Yes. Given the clockdomain and PRM breakage from this merge window, I plan to compile-test future branches that I send to Tony with quite a few non-multi-OMAP configs. I consider it my responsibility to catch breakage from my branches before it makes it to Tony.

Quoted 56 lines

If it helps, here's what I do - not only do I run a few of the standard defconfigs in the tree, but I also run a number of platform specific builds, both covering platforms I do and do not have. I'll pick a random selection of existing build trees to rebuild and see what the results are. This shows the spread of trees which I've built over the last year - and note that many of these I don't even have:

drwxrwxr-x. 20 rmk rmk   4096 Jan 14 20:30 omap4
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:45 versatile
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:14 iop13xx
drwxrwxr-x. 20 rmk rmk   4096 Jan 13 23:10 vexpress
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:48 integrator
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:44 realview
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:10 assabet
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:07 rpc
drwxrwxr-x. 21 rmk rmk   4096 Jan  7 17:34 omap3
drwxrwxr-x. 20 rmk rmk   4096 Jan  6 14:24 nommu
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:44 omap2
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:27 omap
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:24 u300
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 19:14 pxa
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 10:30 msm
drwxrwxr-x. 21 rmk rmk   4096 Jan  4 17:25 orion-kirkwood
drwxrwxr-x. 21 rmk rmk   4096 Dec 24 11:06 ks8695
drwxrwxr-x. 21 rmk rmk   4096 Dec 16 16:12 s3c2410
drwxrwxr-x. 21 rmk rmk   4096 Dec 11 17:17 ixp4xx
drwxrwxr-x. 20 rmk rmk   4096 Oct  9 22:59 netwinder2
drwxrwxr-x. 21 rmk rmk   4096 Sep  5 23:54 ebsa285
drwxrwxr-x. 21 rmk rmk   4096 Aug  4  2010 zylonite
drwxrwxr-x. 21 rmk rmk   4096 Jul  8  2010 ep93xx
drwxrwxr-x. 21 rmk rmk   4096 Jun 29  2010 corgi
drwxrwxr-x. 21 rmk rmk   4096 Apr 25  2010 ebsa110
drwxrwxr-x. 21 rmk rmk   4096 Mar 25  2010 clps711x
drwxrwxr-x. 21 rmk rmk   4096 Mar 24  2010 ixp23xx
drwxrwxr-x. 21 rmk rmk   4096 Mar 20  2010 n2100
drwxrwxr-x. 21 rmk rmk   4096 Feb 19  2010 iop32x
drwxrwxr-x. 21 rmk rmk   4096 Jan 20  2010 mx1
drwxrwxr-x. 21 rmk rmk   4096 Jan 10  2010 w90p910evb

omap4 = 4430SDP only (I have).
omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
omap2 = H2 (whose config can be traced to 2005 from when I once had one.) omap = some random omap1 config
realview = realview eb/smp only
assabet = assabet+neponset daugter board

All those are build trees, built from my git tree with:
make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>

You can see from the above that I built a kernel for at least orion-kirkwood, msm, u300, omap, nommu trees before sending my pull to Linus on the 6th, none of which I have (ever) had hardware for. I also built omap3, omap4, and a bunch of the ARM evaluation platforms as well as older platforms like RiscPC, but those are hidden by later re-builds for work I've been doing since (which is all based upon commit 9e9bc97.)

Quoted 3 lines

I'm not saying that's perfect - it isn't. It's better than just testing the defconfigs - and with regular checking of kautobuild/linux-next, it seems to catch quite a bit of really silly stuff.

I agree with you. I do think it's a good idea, and it's something that I plan to do for future branches that I send to Tony.

regards

- Paul

1. Walmsley, Paul. _[GIT PULL v3] OMAP: core/PM architecture: pull request for 2.6.38_. Posted to linux-omap at vger.kernel.org mailing list on 22 December 2010. Available from
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41289.html (among others).

#51 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

In reply to Russell King - ARM Linux
Quoted 56 lines · Russell King - ARM Linux

If it helps, here's what I do - not only do I run a few of the standard defconfigs in the tree, but I also run a number of platform specific builds, both covering platforms I do and do not have. I'll pick a random selection of existing build trees to rebuild and see what the results are. This shows the spread of trees which I've built over the last year - and note that many of these I don't even have:

drwxrwxr-x. 20 rmk rmk   4096 Jan 14 20:30 omap4
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:45 versatile
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:14 iop13xx
drwxrwxr-x. 20 rmk rmk   4096 Jan 13 23:10 vexpress
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:48 integrator
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:44 realview
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:10 assabet
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:07 rpc
drwxrwxr-x. 21 rmk rmk   4096 Jan  7 17:34 omap3
drwxrwxr-x. 20 rmk rmk   4096 Jan  6 14:24 nommu
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:44 omap2
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:27 omap
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:24 u300
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 19:14 pxa
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 10:30 msm
drwxrwxr-x. 21 rmk rmk   4096 Jan  4 17:25 orion-kirkwood
drwxrwxr-x. 21 rmk rmk   4096 Dec 24 11:06 ks8695
drwxrwxr-x. 21 rmk rmk   4096 Dec 16 16:12 s3c2410
drwxrwxr-x. 21 rmk rmk   4096 Dec 11 17:17 ixp4xx
drwxrwxr-x. 20 rmk rmk   4096 Oct  9 22:59 netwinder2
drwxrwxr-x. 21 rmk rmk   4096 Sep  5 23:54 ebsa285
drwxrwxr-x. 21 rmk rmk   4096 Aug  4  2010 zylonite
drwxrwxr-x. 21 rmk rmk   4096 Jul  8  2010 ep93xx
drwxrwxr-x. 21 rmk rmk   4096 Jun 29  2010 corgi
drwxrwxr-x. 21 rmk rmk   4096 Apr 25  2010 ebsa110
drwxrwxr-x. 21 rmk rmk   4096 Mar 25  2010 clps711x
drwxrwxr-x. 21 rmk rmk   4096 Mar 24  2010 ixp23xx
drwxrwxr-x. 21 rmk rmk   4096 Mar 20  2010 n2100
drwxrwxr-x. 21 rmk rmk   4096 Feb 19  2010 iop32x
drwxrwxr-x. 21 rmk rmk   4096 Jan 20  2010 mx1
drwxrwxr-x. 21 rmk rmk   4096 Jan 10  2010 w90p910evb

omap4 = 4430SDP only (I have).
omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
omap2 = H2 (whose config can be traced to 2005 from when I once had one.) omap = some random omap1 config
realview = realview eb/smp only
assabet = assabet+neponset daugter board

All those are build trees, built from my git tree with:
make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>

You can see from the above that I built a kernel for at least orion-kirkwood, msm, u300, omap, nommu trees before sending my pull to Linus on the 6th, none of which I have (ever) had hardware for. I also built omap3, omap4, and a bunch of the ARM evaluation platforms as well as older platforms like RiscPC, but those are hidden by later re-builds for work I've been doing since (which is all based upon commit 9e9bc97.)

Quoted 3 lines

I'm not saying that's perfect - it isn't. It's better than just testing the defconfigs - and with regular checking of kautobuild/linux-next, it seems to catch quite a bit of really silly stuff.

I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6 plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your compile-testing regimen, if one is not already present?

That would help catch compile problems like the recent CONFIG_SWP_EMULATE one[1].

- Paul

1. _linux-next: omap2plus_defconfig not building_. linux-arm-kernel mailing list thread, started 19 October 2010 by Anand Gadiyar.
http://comments.gmane.org/gmane.linux.ports.arm.kernel/93694

#52 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 6 lines · Paul Walmsley

I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6 plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your compile-testing regimen, if one is not already present?

That would help catch compile problems like the recent CONFIG_SWP_EMULATE one[1].

Such as these?

../build/msm/.config:CONFIG_CPU_V6=y ../build/omap2/.config:CONFIG_CPU_V6=y ../build/omap3/.config:CONFIG_CPU_V7=y ../build/omap3/.config:# CONFIG_SWP_EMULATE is not set ../build/omap4/.config:CONFIG_CPU_V7=y ../build/omap4/.config:# CONFIG_SWP_EMULATE is not set ../build/realview/.config:CONFIG_CPU_V6=y ../build/realview/.config:CONFIG_CPU_V7=y ../build/realview/.config:CONFIG_SWP_EMULATE=y ../build/vexpress/.config:CONFIG_CPU_V7=y ../build/vexpress/.config:CONFIG_SWP_EMULATE=y

So, I already have configs for V7 only+SWP_EMULATE=y, V7 only+SWP_EMULATE=n, V6 only, V6+V7+SWP_EMULATE=y but not V6+V7+SWP_EMULATE=n

It doesn't appear for me because my toolchain new enough to be broken.

What has been merged into the toolchain (gcc emitting a .armv7 at the beginning of its assembler output) was a pretty stupid idea as it's going to break _everything_ out there which has been carefully crafted to compile for ARMv6 but selectively use ARMv7 instructions.

I am very much of the opinion that this new "feature" needs to be removed from the toolchain, and it should do as previous versions of the toolchain does - where the gcc frontend passes the correct architecture flags to the assembler.

This "feature" will have broken a lot more than just the SWP emulate code in the kernel - anything which tries to build a kernel crossing several CPU architectures will hit this failure.

This is what I get from building the realview configuration listed above:

$ emake O=../build/realview/ arch/arm/kernel/
  Using /home/rmk/git/linux-2.6-rmk as source for kernel
  GEN     /home/rmk/git/build/realview/Makefile
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
  CALL    /home/rmk/git/linux-2.6-rmk/scripts/checksyscalls.sh
  CC      arch/arm/kernel/elf.o
  AS      arch/arm/kernel/entry-armv.o
  AS      arch/arm/kernel/entry-common.o
  CC      arch/arm/kernel/irq.o
  CC      arch/arm/kernel/process.o
  CC      arch/arm/kernel/ptrace.o
  CC      arch/arm/kernel/return_address.o
  CC      arch/arm/kernel/setup.o
  CC      arch/arm/kernel/signal.o
  CC      arch/arm/kernel/sys_arm.o
  CC      arch/arm/kernel/stacktrace.o
  CC      arch/arm/kernel/time.o
  CC      arch/arm/kernel/traps.o
  CC      arch/arm/kernel/compat.o
  CC      arch/arm/kernel/leds.o
  CC      arch/arm/kernel/armksyms.o
  CC      arch/arm/kernel/module.o
  CC      arch/arm/kernel/sched_clock.o
  CC      arch/arm/kernel/smp.o
  CC      arch/arm/kernel/smp_tlb.o
  CC      arch/arm/kernel/smp_scu.o
  CC      arch/arm/kernel/smp_twd.o
  CC      arch/arm/kernel/sys_oabi-compat.o
  CC      arch/arm/kernel/swp_emulate.o
  CC      arch/arm/kernel/hw_breakpoint.o
  CC      arch/arm/kernel/pmu.o
  CC      arch/arm/kernel/perf_event.o
  CC      arch/arm/kernel/io.o
  AS      arch/arm/kernel/debug.o
  LD      arch/arm/kernel/built-in.o
  AS      arch/arm/kernel/head.o
  CC      arch/arm/kernel/init_task.o
  LDS     arch/arm/kernel/vmlinux.lds

So, as you can see, it builds perfectly fine for me. GCC 4.3.5, binutils 2.19.1. The command used to build swp_emulate.o was:

arm-linux-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d -nostdinc
-isystem /usr/local/aeabi/lib/gcc/arm-linux/4.3.5/include -I/home/rmk/git/linux-2.6-rmk/arch/arm/include -Iinclude -I/home/rmk/git/linux-2.6-rmk/include -include include/generated/autoconf.h -I/home/rmk/git/linux-2.6-rmk/arch/arm/kernel -Iarch/arm/kernel -D__KERNEL__ -mlittle-endian -I/home/rmk/git/linux-2.6-rmk/arch/arm/mach-realview/include -I/home/rmk/git/linux-2.6-rmk/arch/arm/plat-versatile/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -marm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s -msoft-float -Uarm -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -Wa,-march=armv7-a
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(swp_emulate)" -D"KBUILD_MODNAME=KBUILD_STR(swp_emulate)"
-c -o arch/arm/kernel/swp_emulate.o /home/rmk/git/linux-2.6-rmk/arch/arm/kernel/swp_emulate.c

So, the reason I don't see it is because I don't build the omap2plus_defconfig build, as:

# ARMv6k
config CPU_32v6K

        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

OMAP2 prevents the selection of armv6k support. This is probably a very bad idea if you want to run the resulting kernel on SMP hardware as it removes a barrier in the spinlock code and disables the SMP-safe bitops.

The original patch which started turning this off was from the MX3 stuff, but without explaination.

However, OMAP extended this to disabling the select statement for CPU_32v6K even if CPU_V7 is set:

config CPU_V7

        bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K

+ select CPU_32v6K if !ARCH_OMAP2

Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this patch should not have been merged.

maintainer
#53 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 10 lines · Russell King - ARM Linux

# ARMv6k
config CPU_32v6K

        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

OMAP2 prevents the selection of armv6k support. This is probably a very bad idea if you want to run the resulting kernel on SMP hardware as it removes a barrier in the spinlock code and disables the SMP-safe bitops.

I have some ideas to fix this. Unfortunately it will be inefficient as spinlock.h can be included from modules too :( I was thinking we can implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm builds.

Quoted 6 lines

The original patch which started turning this off was from the MX3 stuff, but without explaination.

However, OMAP extended this to disabling the select statement for CPU_32v6K even if CPU_V7 is set:

Quoted 6 lines

config CPU_V7

        bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K

+ select CPU_32v6K if !ARCH_OMAP2

Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this patch should not have been merged.

The only way we can fix that is do smp_on_up style rewriting of the assembly during init between CPUv6 and v6K. Want me to do a patch for that?

For the defconfigs, I have a branch where I occasionally compile all the old removed defconfigs too. And I believe Kevin test compiles various PM options.

Tony

#54 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 8 lines · Tony Lindgren
Quoted 7 lines · Russell King - ARM Linux

# ARMv6k
config CPU_32v6K

        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
Quoted 8 lines
Quoted 3 lines

OMAP2 prevents the selection of armv6k support. This is probably a very bad idea if you want to run the resulting kernel on SMP hardware as it removes a barrier in the spinlock code and disables the SMP-safe bitops.

I have some ideas to fix this. Unfortunately it will be inefficient as spinlock.h can be included from modules too :( I was thinking we can implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm builds.

For spinlocks, the important thing is the barrier. The wfe/sev are an optimization. The barrier contained with the ifdef is a valid V6 instruction.

Quoted 10 lines
Quoted 10 lines

The original patch which started turning this off was from the MX3 stuff, but without explaination.

However, OMAP extended this to disabling the select statement for CPU_32v6K even if CPU_V7 is set:

config CPU_V7

        bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K

+ select CPU_32v6K if !ARCH_OMAP2

Quoted 5 lines
Quoted 2 lines

Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this patch should not have been merged.

The only way we can fix that is do smp_on_up style rewriting of the assembly during init between CPUv6 and v6K. Want me to do a patch for that?

The bitops code is quite different between the two versions, and I doubt the smp_on_up rewriting will look at all pretty. I think it needs an alternative idea - like not using the 'byte' operations at all.

Whether we have any code which passes non-word aligned pointers to bitops isn't particularly known - in theory they should all be unsigned long *'s, so should be word-aligned. Who knows what filesystems do though... and such a change could be disasterous to peoples data if the block/inode bitmaps get corrupted.

IOW, such a change needs testing on a box where a range of filesystems are used, and the filesystems can be thrown away if corrupted.

maintainer
#55 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 13 lines · Russell King - ARM Linux
Quoted 12 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux

# ARMv6k
config CPU_32v6K

        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

OMAP2 prevents the selection of armv6k support. This is probably a very bad idea if you want to run the resulting kernel on SMP hardware as it removes a barrier in the spinlock code and disables the SMP-safe bitops.

Quoted 8 lines
Quoted 4 lines

I have some ideas to fix this. Unfortunately it will be inefficient as spinlock.h can be included from modules too :( I was thinking we can implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm builds.

For spinlocks, the important thing is the barrier. The wfe/sev are an optimization. The barrier contained with the ifdef is a valid V6 instruction.

OK, great it's just drain WB. Then we can do the ussual iffdeffery on it for multi-arm builds as it does not depend on the 6K extensions. I can do a patch for this on Monday, gotta run now.

Quoted 20 lines
Quoted 10 lines
Quoted 10 lines

The original patch which started turning this off was from the MX3 stuff, but without explaination.

However, OMAP extended this to disabling the select statement for CPU_32v6K even if CPU_V7 is set:

config CPU_V7

        bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K

+ select CPU_32v6K if !ARCH_OMAP2

Quoted 5 lines
Quoted 2 lines

Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this patch should not have been merged.

The only way we can fix that is do smp_on_up style rewriting of the assembly during init between CPUv6 and v6K. Want me to do a patch for that?

The bitops code is quite different between the two versions, and I doubt the smp_on_up rewriting will look at all pretty. I think it needs an alternative idea - like not using the 'byte' operations at all.

Quoted 5 lines

Whether we have any code which passes non-word aligned pointers to bitops isn't particularly known - in theory they should all be unsigned long *'s, so should be word-aligned. Who knows what filesystems do though... and such a change could be disasterous to peoples data if the block/inode bitmaps get corrupted.

Hmm, how about emulation of those instructions for non-v6K ARMv6 processors? I guess we could do some address checking in the bitops functions too for multi-arm builds..

Quoted 2 lines

IOW, such a change needs testing on a box where a range of filesystems are used, and the filesystems can be thrown away if corrupted.

Or we could patch in the address checking first and only disable it later if now warnings.

Tony

#56 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 57 lines · Tony Lindgren
Quoted 13 lines · Russell King - ARM Linux
Quoted 12 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux

# ARMv6k
config CPU_32v6K

        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

OMAP2 prevents the selection of armv6k support. This is probably a very bad idea if you want to run the resulting kernel on SMP hardware as it removes a barrier in the spinlock code and disables the SMP-safe bitops.

Quoted 8 lines
Quoted 4 lines

I have some ideas to fix this. Unfortunately it will be inefficient as spinlock.h can be included from modules too :( I was thinking we can implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm builds.

For spinlocks, the important thing is the barrier. The wfe/sev are an optimization. The barrier contained with the ifdef is a valid V6 instruction.

OK, great it's just drain WB. Then we can do the ussual iffdeffery on it for multi-arm builds as it does not depend on the 6K extensions. I can do a patch for this on Monday, gotta run now.

Quoted 20 lines
Quoted 10 lines
Quoted 10 lines

The original patch which started turning this off was from the MX3 stuff, but without explaination.

However, OMAP extended this to disabling the select statement for CPU_32v6K even if CPU_V7 is set:

config CPU_V7

        bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K

+ select CPU_32v6K if !ARCH_OMAP2

Quoted 5 lines
Quoted 2 lines

Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this patch should not have been merged.

The only way we can fix that is do smp_on_up style rewriting of the assembly during init between CPUv6 and v6K. Want me to do a patch for that?

The bitops code is quite different between the two versions, and I doubt the smp_on_up rewriting will look at all pretty. I think it needs an alternative idea - like not using the 'byte' operations at all.

Quoted 5 lines

Whether we have any code which passes non-word aligned pointers to bitops isn't particularly known - in theory they should all be unsigned long *'s, so should be word-aligned. Who knows what filesystems do though... and such a change could be disasterous to peoples data if the block/inode bitmaps get corrupted.

Hmm, how about emulation of those instructions for non-v6K ARMv6 processors? I guess we could do some address checking in the bitops functions too for multi-arm builds..

Quoted 5 lines
Quoted 2 lines

IOW, such a change needs testing on a box where a range of filesystems are used, and the filesystems can be thrown away if corrupted.

Or we could patch in the address checking first and only disable it later if now warnings.

Right, this is what I'm going to do - and it's going to *intentionally* break omap2plus_defconfig. Please see the commit comments for the reason why. We need to address the V6 issue properly without risking users data.

To Sascha: this replaces the previous patch which I asked for your ack.

8<-----------
Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection

CPU_32v6K controls whether we use the ARMv6K extension instructions in the kernel, and in some places whether we use SMP-safe code sequences (eg, bitops.)

Having this configuration option disabled on a SMP supporting kernel results in a problem: the SMP-unsafe code sequences will be used, and as such the resulting kernel is not SMP safe.

As the atomic bitops are used by filesystems (eg, ext2 - to manipulate the inode and block bitmaps) not having the SMP safe code sequences is fatal for filesystem data integrity. So running an SMP kernel without CPU_32v6K set is dangerous.

MX3 prevents the selection of this option to ensure that it is not enabled for their CPU, which is ARMv6 only. MX3 folk need to ensure that their kernel is properly configured.

OMAP prevents the selection of this option in an attempt to produce a kernel which runs on architectures from ARMv6 to ARMv7 MPCore.

Balancing between oopsing on boot and filesystem corruption, it is far more preferable to oops on boot until the code sequences are sorted out properly.

---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mm/Kconfig +1 -1
index 49db8b3..d61af9c 100644
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
 	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	default y if SMP
 	help
 	  Say Y here if your ARMv6 processor supports the 'K' extension.
 	  This enables the kernel to use some instructions not present
Signature · 1 line
1.6.2.5
#57 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 64 lines · Russell King - ARM Linux
Quoted 57 lines · Tony Lindgren
Quoted 13 lines · Russell King - ARM Linux
Quoted 12 lines · Tony Lindgren
Quoted 10 lines · Russell King - ARM Linux

# ARMv6k
config CPU_32v6K

        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

OMAP2 prevents the selection of armv6k support. This is probably a very bad idea if you want to run the resulting kernel on SMP hardware as it removes a barrier in the spinlock code and disables the SMP-safe bitops.

Quoted 8 lines
Quoted 4 lines

I have some ideas to fix this. Unfortunately it will be inefficient as spinlock.h can be included from modules too :( I was thinking we can implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm builds.

For spinlocks, the important thing is the barrier. The wfe/sev are an optimization. The barrier contained with the ifdef is a valid V6 instruction.

OK, great it's just drain WB. Then we can do the ussual iffdeffery on it for multi-arm builds as it does not depend on the 6K extensions. I can do a patch for this on Monday, gotta run now.

Quoted 20 lines
Quoted 10 lines
Quoted 10 lines

The original patch which started turning this off was from the MX3 stuff, but without explaination.

However, OMAP extended this to disabling the select statement for CPU_32v6K even if CPU_V7 is set:

config CPU_V7

        bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K

+ select CPU_32v6K if !ARCH_OMAP2

Quoted 5 lines
Quoted 2 lines

Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this patch should not have been merged.

The only way we can fix that is do smp_on_up style rewriting of the assembly during init between CPUv6 and v6K. Want me to do a patch for that?

The bitops code is quite different between the two versions, and I doubt the smp_on_up rewriting will look at all pretty. I think it needs an alternative idea - like not using the 'byte' operations at all.

Quoted 5 lines

Whether we have any code which passes non-word aligned pointers to bitops isn't particularly known - in theory they should all be unsigned long *'s, so should be word-aligned. Who knows what filesystems do though... and such a change could be disasterous to peoples data if the block/inode bitmaps get corrupted.

Hmm, how about emulation of those instructions for non-v6K ARMv6 processors? I guess we could do some address checking in the bitops functions too for multi-arm builds..

Quoted 5 lines
Quoted 2 lines

IOW, such a change needs testing on a box where a range of filesystems are used, and the filesystems can be thrown away if corrupted.

Or we could patch in the address checking first and only disable it later if now warnings.

Quoted 6 lines

Right, this is what I'm going to do - and it's going to *intentionally* break omap2plus_defconfig. Please see the commit comments for the reason why. We need to address the V6 issue properly without risking users data.

To Sascha: this replaces the previous patch which I asked for your ack.

Ack for this one aswell:

Quoted 55 lines

8<-----------
Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection

CPU_32v6K controls whether we use the ARMv6K extension instructions in the kernel, and in some places whether we use SMP-safe code sequences (eg, bitops.)

Having this configuration option disabled on a SMP supporting kernel results in a problem: the SMP-unsafe code sequences will be used, and as such the resulting kernel is not SMP safe.

As the atomic bitops are used by filesystems (eg, ext2 - to manipulate the inode and block bitmaps) not having the SMP safe code sequences is fatal for filesystem data integrity. So running an SMP kernel without CPU_32v6K set is dangerous.

MX3 prevents the selection of this option to ensure that it is not enabled for their CPU, which is ARMv6 only. MX3 folk need to ensure that their kernel is properly configured.

OMAP prevents the selection of this option in an attempt to produce a kernel which runs on architectures from ARMv6 to ARMv7 MPCore.

Balancing between oopsing on boot and filesystem corruption, it is far more preferable to oops on boot until the code sequences are sorted out properly.

---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mm/Kconfig +1 -1
index 49db8b3..d61af9c 100644
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
 	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	default y if SMP
 	help
 	  Say Y here if your ARMv6 processor supports the 'K' extension.
 	  This enables the kernel to use some instructions not present
Signature · 7 lines
1.6.2.5


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 4 lines
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 |
#58 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

In reply to Tony Lindgren
Quoted 29 lines · Tony Lindgren

Here's one more es1.0 fix after the recent USB changes.

Regards,

Tony

Author: Tony Lindgren <[email protected]>
Date:   Tue Jan 11 15:03:03 2011 -0800

omap4: Fix ULPI PHY init for ES1.0 SDP

Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
enable the ehci port on 4430SDP) added code to enable EHCI support on 4430sdp board.

Looks like the ULPI pin does not seem to be muxed properly on ES1.0 SDP and this causes the system to reboot when the ULPI PHY is enabled.

Fix this by muxing the pin, this is the same setting for both ES1.0 and ES2.0. Also add checking for gpio_request.

Cc Keshava Munegowda <[email protected]

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_sfh7741prox_init(void) · line 560

Quoted 7 lines
arch/arm/mach-omap2/board-4430sdp.c +1 -0
@@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
+	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else

Tony,

I believe this fix is fixing your reboot issue, but it's breaking EHCI support on the SDP.

The MODE4 above should really be MODE3 - all GPIOs are on MODE3. By changing

The patch snippet below fixes EHCI on the SDP, but I believe that making this change will reintroduce the "board reboots" issue you originally reported. Could you check and tell me if this is the case?

Just curious - is your board a Blaze, or an SDP?

(quoted diff) +0 -0

b/arch/arm/mach-omap2/board-4430sdp.c
index 07d1b20..ab9fb4d 100644

arch/arm/mach-omap2/board-4430sdp.c +1 -1
@@ -554,7 +554,7 @@ static void __init omap_sfh7741prox_init(void)
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
-	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else
maintainer
#59 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 11 lines · Anand Gadiyar

I believe this fix is fixing your reboot issue, but it's breaking EHCI support on the SDP.

The MODE4 above should really be MODE3 - all GPIOs are on MODE3. By changing

The patch snippet below fixes EHCI on the SDP, but I believe that making this change will reintroduce the "board reboots" issue you originally reported. Could you check and tell me if this is the case?

Hmm sorry looks like I made a typo there. That should be fixed.

Quoted 1 line

Just curious - is your board a Blaze, or an SDP?

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

Quoted 6 lines
arch/arm/mach-omap2/board-4430sdp.c +0 -0
index 07d1b20..ab9fb4d 100644

arch/arm/mach-omap2/board-4430sdp.c static void __init omap_sfh7741prox_init(void) · line 560

Quoted 8 lines
arch/arm/mach-omap2/board-4430sdp.c +1 -1
@@ -554,7 +554,7 @@ static void __init omap_sfh7741prox_init(void)
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
-	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else

Maybe there should be a check for ES1.0 for the USB also?

Tony

#60 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 23 lines

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Wednesday, February 02, 2011 6:40 AM
To: Anand Gadiyar
Cc: Russell King - ARM Linux; linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Santosh Shilimkar; Felipe Balbi
Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 11 lines · Anand Gadiyar

I believe this fix is fixing your reboot issue, but it's breaking EHCI support on the SDP.

The MODE4 above should really be MODE3 - all GPIOs are on MODE3. By changing

The patch snippet below fixes EHCI on the SDP, but I believe that making this change will reintroduce the "board reboots" issue you originally reported. Could you check and tell me if this is the case?

Quoted 8 lines

Hmm sorry looks like I made a typo there. That should be fixed.

Quoted 1 line

Just curious - is your board a Blaze, or an SDP?

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP.

maintainer
#61 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 8 lines · Santosh Shilimkar
Quoted 5 lines

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP.

Yeah I do, it rarely makes it to the userspace. Works reliably if I disable omap_l2_cache_init.

Tony

#62 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 16 lines

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Thursday, February 03, 2011 1:19 AM
To: Santosh Shilimkar
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Felipe Balbi
Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 5 lines · Santosh Shilimkar
Quoted 5 lines

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

Quoted 7 lines
Quoted 3 lines

Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP.

Yeah I do, it rarely makes it to the userspace. Works reliably if I disable omap_l2_cache_init.

Ok. I shall try few experiments and try to reproduce it

#63 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Tony,

Quoted 26 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Thursday, February 03, 2011 2:13 PM
To: Tony Lindgren
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Felipe Balbi
Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 16 lines

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Thursday, February 03, 2011 1:19 AM
To: Santosh Shilimkar
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Felipe Balbi
Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 5 lines · Santosh Shilimkar
Quoted 5 lines

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP.

Yeah I do, it rarely makes it to the userspace. Works reliably if I disable omap_l2_cache_init.

Ok. I shall try few experiments and try to reproduce it

Not sure if it's the same issue but I managed to reproduce the issue on ES2.0 itself. And after some experiments, it boiled down to the V6 and V7 issue. By disabling OMAP2 from the build, everything was fine again.

Regards,
Santosh

maintainer
#64 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 34 lines · Santosh Shilimkar

Tony,

Quoted 33 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Thursday, February 03, 2011 2:13 PM
To: Tony Lindgren
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Felipe Balbi
Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 23 lines

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Thursday, February 03, 2011 1:19 AM
To: Santosh Shilimkar
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Felipe Balbi
Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 8 lines · Santosh Shilimkar
Quoted 5 lines

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP.

Yeah I do, it rarely makes it to the userspace. Works reliably if I disable omap_l2_cache_init.

Quoted 6 lines
Quoted 1 line

Ok. I shall try few experiments and try to reproduce it

Not sure if it's the same issue but I managed to reproduce the issue on ES2.0 itself. And after some experiments, it boiled down to the V6 and V7 issue. By disabling OMAP2 from the build, everything was fine again.

Was this with linux-omap master branch or mainline?

The V6 vs V7 issues should be sorted out with Russell's patches that we also have now in linux-omap master branch.

Regards,

Tony

#65 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 55 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: Thursday, February 24, 2011 11:09 PM
To: Santosh Shilimkar
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Felipe Balbi
Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 17 lines · Santosh Shilimkar

Tony,

Quoted 16 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Thursday, February 03, 2011 2:13 PM
To: Tony Lindgren
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava Munegowda; Felipe Balbi
Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
4430SDP boot failure)

Quoted 6 lines

-----Original Message-----
From: Tony Lindgren [mailto:tony at atomide.com]
Sent: Thursday, February 03, 2011 1:19 AM
To: Santosh Shilimkar
Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- kernel at lists.infradead.org; linux-omap at vger.kernel.org;

Keshava

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Munegowda; Felipe Balbi
Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP

(Re:

Quoted 15 lines
Quoted 15 lines
Quoted 15 lines

4430SDP boot failure)

Quoted 8 lines · Santosh Shilimkar
Quoted 5 lines

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP.

Yeah I do, it rarely makes it to the userspace. Works reliably if I disable omap_l2_cache_init.

Quoted 6 lines
Quoted 1 line

Ok. I shall try few experiments and try to reproduce it

Not sure if it's the same issue but I managed to reproduce the issue on ES2.0 itself. And after some experiments, it boiled down to the V6 and V7 issue. By disabling OMAP2 from the build, everything was fine again.

Quoted 5 lines

Was this with linux-omap master branch or mainline?

The V6 vs V7 issues should be sorted out with Russell's patches that we also have now in linux-omap master branch.

This was with mainline.
Then I applied RMK's series and things were OK.

maintainer
#66 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 8 lines · Santosh Shilimkar
Quoted 6 lines

Was this with linux-omap master branch or mainline?

The V6 vs V7 issues should be sorted out with Russell's patches that we also have now in linux-omap master branch.

This was with mainline.
Then I applied RMK's series and things were OK.

OK good to hear & thanks for checking that.

Tony

#67 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

In reply to Tony Lindgren
Quoted 21 lines · Tony Lindgren
Quoted 11 lines · Anand Gadiyar

I believe this fix is fixing your reboot issue, but it's breaking EHCI support on the SDP.

The MODE4 above should really be MODE3 - all GPIOs are on MODE3. By changing

The patch snippet below fixes EHCI on the SDP, but I believe that making this change will reintroduce the "board reboots" issue you originally reported. Could you check and tell me if this is the case?

Hmm sorry looks like I made a typo there. That should be fixed.

Quoted 1 line

Just curious - is your board a Blaze, or an SDP?

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

...

Quoted 1 line

Maybe there should be a check for ES1.0 for the USB also?

Looks like a bug on the Blaze boards. There's a large capacitor on the rails that starts charging when we try to power the USB PHY. The inrush current is quite high and this causes the reboot.

The capacitor is on the big motherboard called the application board, so it's independent of the silicon rev. I'm not sure which revs are affected - I'll try and find out more about the issue to see if I can come up with a better fix.

- Anand

maintainer
#68 lore raw

PATCH 1/1 omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

Quoted 27 lines · Anand Gadiyar
Quoted 21 lines · Tony Lindgren
Quoted 11 lines · Anand Gadiyar

I believe this fix is fixing your reboot issue, but it's breaking EHCI support on the SDP.

The MODE4 above should really be MODE3 - all GPIOs are on MODE3. By changing

The patch snippet below fixes EHCI on the SDP, but I believe that making this change will reintroduce the "board reboots" issue you originally reported. Could you check and tell me if this is the case?

Hmm sorry looks like I made a typo there. That should be fixed.

Quoted 1 line

Just curious - is your board a Blaze, or an SDP?

It's a ES1.0 blaze, with the patch below it reboots early during the boot. I also have to disable omap_l2_cache_init on this board to get it to boot.

...

Quoted 1 line

Maybe there should be a check for ES1.0 for the USB also?

Quoted 8 lines

Looks like a bug on the Blaze boards. There's a large capacitor on the rails that starts charging when we try to power the USB PHY. The inrush current is quite high and this causes the reboot.

The capacitor is on the big motherboard called the application board, so it's independent of the silicon rev. I'm not sure which revs are affected - I'll try and find out more about the issue to see if I can come up with a better fix.

OK thanks.

Tony