4430SDP boot failure

4430SDP boot failure

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

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

Re: 4430SDP boot failure

[Nishanth Menon]

Russell King - ARM Linux had written, on 01/06/2011 11:08 AM, the following:
[..]
> 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.
[..]
> 
> 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
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.

-- 
Regards,
Nishanth Menon

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 05:08:05PM +0000, Russell King - ARM Linux wrote:
> 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.

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.

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 06:00:30PM +0000, Russell King - ARM Linux wrote:
> 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.

Re: 4430SDP boot failure

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 10:17]:
> On Thu, Jan 06, 2011 at 06:00:30PM +0000, Russell King - ARM Linux wrote:
> > 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.

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

Re: 4430SDP boot failure

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 10:00]:
> On Thu, Jan 06, 2011 at 05:08:05PM +0000, Russell King - ARM Linux wrote:
> > 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.
> 
> 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?

BSS works too, got a patch for that?
 
> 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

Re: 4430SDP boot failure

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110106 10:20]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 10:00]:
> > 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
> > 
> > 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 <tony@atomide.com>
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.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -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

Re: 4430SDP boot failure

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110106 11:52]:
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -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 <tony@atomide.com>
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.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -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

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 12:34:32PM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [110106 11:52]:
> > --- a/arch/arm/boot/compressed/head.S
> > +++ b/arch/arm/boot/compressed/head.S
> > @@ -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.

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.

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 08:51:07PM +0000, Russell King - ARM Linux wrote:
> 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.

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 08:51:07PM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 06, 2011 at 12:34:32PM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [110106 11:52]:
> > > --- a/arch/arm/boot/compressed/head.S
> > > +++ b/arch/arm/boot/compressed/head.S
> > > @@ -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.
> 
> 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.

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.

Re: 4430SDP boot failure

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 15:51]:
> On Thu, Jan 06, 2011 at 08:51:07PM +0000, Russell King - ARM Linux wrote:
> > 
> > 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.

Sorry no idea about this problem, have not seen it myself.
 
> > 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

RE: 4430SDP boot failure

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 5:22 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure

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

[..]

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

[..]

> 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

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 02:09:17PM +0530, Santosh Shilimkar wrote:
> > 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.

RE: 4430SDP boot failure

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 2:58 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure
>
> On Fri, Jan 07, 2011 at 02:09:17PM +0530, Santosh Shilimkar wrote:
> > > 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.
>
Ok. Will try 2.6.37 major version.

> 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

RE: 4430SDP boot failure

[Santosh Shilimkar]

> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Friday, January 07, 2011 3:23 PM
Ruessell,


> To: Russell King - ARM Linux
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: RE: 4430SDP boot failure
>

[....]

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

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.

RE: 4430SDP boot failure

[Santosh Shilimkar]

Sorry,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Friday, January 07, 2011 5:49 PM
> To: Russell King - ARM Linux
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: RE: 4430SDP boot failure
>
> > -----Original Message-----
> > From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> > Sent: Friday, January 07, 2011 3:23 PM
> Ruessell,
>
>
> > To: Russell King - ARM Linux
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: RE: 4430SDP boot failure
> >
>
> [....]
>
> > > 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
>
> 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.

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> > Sent: Friday, January 07, 2011 3:23 PM
> Ruessell,
> 
> 
> > To: Russell King - ARM Linux
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: RE: 4430SDP boot failure
> >
> 
> [....]
> 
> > > 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
> 
> 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.

Re: 4430SDP boot failure

[Koen Kooi]

Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven:
> 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

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 02:07:53PM +0100, Koen Kooi wrote:
> Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven:
> > 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?

RE: 4430SDP boot failure

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 6:22 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure
>
> On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> > > Sent: Friday, January 07, 2011 3:23 PM
> > Ruessell,
> >
> >
> > > To: Russell King - ARM Linux
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: RE: 4430SDP boot failure
> > >
> >
> > [....]
> >
> > > > 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
> >
> > 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
>
Yep. Noticed that after the post.

> 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

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> 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.

RE: 4430SDP boot failure

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 7:55 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure
>
> On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > 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

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

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > Sent: Friday, January 07, 2011 7:55 PM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure
> >
> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > 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.

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.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
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.

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 951a160..abb1ffb 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -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;
 			}

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

[Tony Lindgren]

Grant,

Care to queue or ack the following fix?

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110107 07:48]:
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > > 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.
> 
> 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.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>


> ---
> 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.
> 
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 951a160..abb1ffb 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -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;
>  			}
> 

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

[Grant Likely]

On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote:
> 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:

Acked-by: Grant Likely <grant.likely@secretlab.ca>

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.

> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110107 07:48]:
> > On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > > -----Original Message-----
> > > > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > > > Sent: Friday, January 07, 2011 7:55 PM
> > > > To: Santosh Shilimkar
> > > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > > Subject: Re: 4430SDP boot failure
> > > >
> > > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > > > 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.
> > 
> > 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.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Acked-by: Tony Lindgren <tony@atomide.com>
> 
> 
> > ---
> > 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.
> > 
> > diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> > index 951a160..abb1ffb 100644
> > --- a/drivers/spi/omap2_mcspi.c
> > +++ b/drivers/spi/omap2_mcspi.c
> > @@ -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;
> >  			}
> > 

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

[Tony Lindgren]

* Grant Likely <grant.likely@secretlab.ca> [110107 09:18]:
> On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote:
> > 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

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

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 09:25:11AM -0800, Tony Lindgren wrote:
> * Grant Likely <grant.likely@secretlab.ca> [110107 09:18]:
> > On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote:
> > > 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.

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

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Friday, January 07, 2011 9:19 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar
> wrote:
> > > > 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.
>
> 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.

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

> =================
> 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.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Thanks for fixing it
> ---
> 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.
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 951a160..abb1ffb 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -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;
>  			}
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > 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.

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.

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

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:23 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > 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.
>
> 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"

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

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

[Russell King - ARM Linux]

On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > Sent: Saturday, January 08, 2011 12:23 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> >
> > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > > 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.
> >
> > 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.

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.

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

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:50 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > > Sent: Saturday, January 08, 2011 12:23 AM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> > >
> > > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar
> wrote:
> > > > > 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.
> > >
> > > 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.
>
> 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

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

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 03:49:20PM +0000, Russell King - ARM Linux wrote:
> 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

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > Sent: Friday, January 07, 2011 7:55 PM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure
> >
> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > 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.

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.

Re: 4430SDP boot failure

[Daniel Díaz]

Hello!


On Fri, Jan 7, 2011 at 10:24 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
>> > -----Original Message-----
>> > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
>> > Sent: Friday, January 07, 2011 7:55 PM
>> > To: Santosh Shilimkar
>> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
>> > Subject: Re: 4430SDP boot failure
>> >
>> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
>> > > 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.
>
> 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
yosoy@danieldiaz.org



> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: 4430SDP boot failure

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 9:54 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure
>
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar
> wrote:
> > > > 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.
>
> 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.

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

DHCP seems to work for me without any issues.

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 11:59:07PM +0530, Santosh Shilimkar wrote:
> > 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.
> 
> 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...

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 10:00]:
> > On Thu, Jan 06, 2011 at 05:08:05PM +0000, Russell King - ARM Linux wrote:
> > > 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.
> > 
> > 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?
> 
> 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

> > 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.)

Re: 4430SDP boot failure

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 12:32]:
> On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 10:00]:
> > > 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

That does not work as BSS gets cleared in head-common.S.. See my other patch.
 
> > 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.

OK thanks.
 
> 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.

I think I got it fixed, see the other patch I just posted.
 
> (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

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
> 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.

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 6a4d413..47df8a6 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -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

Re: 4430SDP boot failure

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110107 08:12]:
> On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
> > 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

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

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110110 10:51]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110107 08:12]:
> > On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
> > > 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.

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

Regards,

Tony


Author: Tony Lindgren <tony@atomide.com>
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@ti.com
    Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -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);
 

RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Anand Gadiyar]

Tony Lindgren wrote:
> Here's one more es1.0 fix after the recent USB changes.
>
> Regards,
>
> Tony
>
>
> Author: Tony Lindgren <tony@atomide.com>
> 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@ti.com
>     Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -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");

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

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

[Russell King - ARM Linux]

On Thu, Jan 13, 2011 at 02:22:06PM +0530, Anand Gadiyar wrote:
> Tony Lindgren wrote:
> >  	/* 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");
> 
> 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...

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

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> On Thu, Jan 13, 2011 at 02:22:06PM +0530, Anand Gadiyar wrote:
> > Tony Lindgren wrote:
> > >  	/* 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");
> > 
> > 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.
 
> 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.
 
> 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

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

[Russell King - ARM Linux]

On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > 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.

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

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 08:49]:
> On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > 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

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

[Paul Walmsley]

On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:

> On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > 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 <torvalds@linux-foundation.org>
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
$ 

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

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > > 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].

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.

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

[Paul Walmsley]

On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:

> On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> > On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > > > 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].
> 
> 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.

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

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.

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

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@vger.kernel.org mailing list on 22 
   December 2010. Available from 
   http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41289.html
   (among others).

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

[Paul Walmsley]

On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:

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

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

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

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 04:10:29PM -0700, Paul Walmsley wrote:
> 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.

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

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> 
> # 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.
 
> 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.

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

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

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > 
> > # 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.

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.

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

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

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > > 
> > > # 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.
> 
> 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.
 
> > > 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.
> > 
> > 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.

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

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

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > > > 
> > > > # 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.
> > 
> > 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.
>  
> > > > 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.
> > > 
> > > 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.
> 
> 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..
>  
> > 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.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 49db8b3..d61af9c 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -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
-- 
1.6.2.5

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

[Sascha Hauer]

On Sat, Jan 15, 2011 at 05:04:55PM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> > > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > > > > 
> > > > > # 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.
> > > 
> > > 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.
> >  
> > > > > 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.
> > > > 
> > > > 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.
> > 
> > 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..
> >  
> > > 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.

Ack for this one aswell:

Acked-by: Sascha Hauer <s.hauer@pengutronix.de>

> 
> 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.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/mm/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 49db8b3..d61af9c 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -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
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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

RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Anand Gadiyar]

Tony Lindgren wrote:

> Here's one more es1.0 fix after the recent USB changes.
>
> Regards,
>
> Tony
>
>
> Author: Tony Lindgren <tony@atomide.com>
> 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@ti.com
>     Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -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?

diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 07d1b20..ab9fb4d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -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

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

[Tony Lindgren]

* Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> 
> 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.
 
> 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.
 
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 07d1b20..ab9fb4d 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -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

RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Wednesday, February 02, 2011 6:40 AM
> To: Anand Gadiyar
> Cc: Russell King - ARM Linux; linux-arm-kernel@lists.infradead.org;
> linux-omap@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)
>
> * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> >
> > 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.
>
> > 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.

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

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> >
> > 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

RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Thursday, February 03, 2011 1:19 AM
> To: Santosh Shilimkar
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > >
> > > 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.
>
Ok. I shall try few experiments and try to reproduce it

RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

Tony,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Thursday, February 03, 2011 2:13 PM
> To: Tony Lindgren
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Thursday, February 03, 2011 1:19 AM
> > To: Santosh Shilimkar
> > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> > Munegowda; Felipe Balbi
> > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > 4430SDP boot failure)
> >
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > >
> > > > 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.
> >
> 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

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

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110212 00:45]:
> Tony,
> > -----Original Message-----
> > From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> > Sent: Thursday, February 03, 2011 2:13 PM
> > To: Tony Lindgren
> > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> > Munegowda; Felipe Balbi
> > Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > 4430SDP boot failure)
> >
> > > -----Original Message-----
> > > From: Tony Lindgren [mailto:tony@atomide.com]
> > > Sent: Thursday, February 03, 2011 1:19 AM
> > > To: Santosh Shilimkar
> > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> > > Munegowda; Felipe Balbi
> > > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > > 4430SDP boot failure)
> > >
> > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > > >
> > > > > 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.
> > >
> > 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

RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@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@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110212 00:45]:
> > Tony,
> > > -----Original Message-----
> > > From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> > > Sent: Thursday, February 03, 2011 2:13 PM
> > > To: Tony Lindgren
> > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> > > Munegowda; Felipe Balbi
> > > Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > > 4430SDP boot failure)
> > >
> > > > -----Original Message-----
> > > > From: Tony Lindgren [mailto:tony@atomide.com]
> > > > Sent: Thursday, February 03, 2011 1:19 AM
> > > > To: Santosh Shilimkar
> > > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > > > kernel@lists.infradead.org; linux-omap@vger.kernel.org;
> Keshava
> > > > Munegowda; Felipe Balbi
> > > > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP
> (Re:
> > > > 4430SDP boot failure)
> > > >
> > > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > > > >
> > > > > > 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.
> > > >
> > > 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.
>
This was with mainline.
Then I applied RMK's series and things were OK.

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

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110224 21:31]:
> >
> > 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

RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Anand Gadiyar]

Tony Lindgren wrote:
> * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> >
> > 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.
>
> > 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.
>

...

> 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

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

[Tony Lindgren]

* Anand Gadiyar <gadiyar@ti.com> [110202 10:51]:
> Tony Lindgren wrote:
> > * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> > >
> > > 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.
> >
> > > 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.
> >
> 
> ...
> 
> > 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.

OK thanks.

Tony