linux-next - multi-omap image fails to boot on omap3/4

DISCUSSION Anand Gadiyar 2 participants 12 messages Oct 19, 2010 – Oct 22, 2010

Share & tools

Anand Gadiyar

author

2010-10-19 14:49 UTC #0 lore raw

Hi all,

linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.

earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."

Any ideas where to look?

- Anand

Tony Lindgren

2010-10-19 18:21 UTC #1 lore raw

Quoted 8 lines · Anand Gadiyar

Hi all,
linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.

Quoted 4 lines

earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?

Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine.

So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason.

Regards,

Tony

Gadiyar, Anand

author

2010-10-19 18:35 UTC #2 lore raw

Quoted 14 lines · Tony Lindgren

Quoted 8 lines · Anand Gadiyar
Hi all,
linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
Quoted 4 lines
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?

Quoted 7 lines

Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine.
So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason.

I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while.

- Anand

Tony Lindgren

2010-10-19 22:57 UTC #3 lore raw

Quoted 18 lines · Gadiyar, Anand

Quoted 17 lines · Tony Lindgren
Quoted 8 lines · Anand Gadiyar
Hi all,
linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
Quoted 4 lines
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?
Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine.

Quoted 8 lines

Quoted 4 lines
So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason.
I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while.

Looks like current next at 80f8f1f8b33750d954beb386c0c8142d0c01c25c boots again except on 2430sdp it produces a NULL pointer at ubi_io_write.

Tony

Tony Lindgren

2010-10-19 23:32 UTC #4 lore raw

Quoted 24 lines · Tony Lindgren

Quoted 23 lines · Gadiyar, Anand
Quoted 21 lines · Tony Lindgren
Quoted 8 lines · Anand Gadiyar
Hi all,
linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
Quoted 4 lines
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?
Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine.
So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason.

Quoted 6 lines

Quoted 3 lines
I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while.
Looks like current next at 80f8f1f8b33750d954beb386c0c8142d0c01c25c boots again except on 2430sdp it produces a NULL pointer at ubi_io_write.

Oops, sorry it's still broken, wrong tree.

Tony

Gadiyar, Anand

author

2010-10-19 23:47 UTC #5 lore raw

Quoted 25 lines · Tony Lindgren

Quoted 24 lines · Tony Lindgren
Quoted 23 lines · Gadiyar, Anand
Quoted 21 lines · Tony Lindgren
Quoted 8 lines · Anand Gadiyar
Hi all,
linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
Quoted 4 lines
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?
Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine.
So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason.

Quoted 9 lines

Quoted 6 lines
Quoted 3 lines
I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while.
Looks like current next at 80f8f1f8b33750d954beb386c0c8142d0c01c25c boots again except on 2430sdp it produces a NULL pointer at ubi_io_write.
Oops, sorry it's still broken, wrong tree.

I've started bisecting again - I needed to pick commit 5bac0926121e (driver core: platform_bus: allow runtime override of dev_pm_ops) to solve the build break.

Will report back if I find something.

- Anand

Gadiyar, Anand

author

2010-10-20 06:30 UTC #6 lore raw

Quoted 33 lines · Anand

Quoted 32 lines · Tony Lindgren
Quoted 30 lines · Tony Lindgren
Quoted 18 lines · Gadiyar, Anand
Quoted 17 lines · Tony Lindgren
Quoted 8 lines · Anand Gadiyar
Hi all,
linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
Quoted 4 lines
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?
Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine.
Quoted 8 lines
Quoted 4 lines
So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason.
I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while.
Looks like current next at 80f8f1f8b33750d954beb386c0c8142d0c01c25c boots again except on 2430sdp it produces a NULL pointer at ubi_io_write.

Quoted 9 lines

Quoted 2 lines
Oops, sorry it's still broken, wrong tree.
I've started bisecting again - I needed to pick commit 5bac0926121e (driver core: platform_bus: allow runtime override of dev_pm_ops) to solve the build break.
Will report back if I find something.

I tried disabling CONFIG_SMP and CONFIG_SMP_ON_UP, and the resulting image booted up just fine.

- Anand

Tony Lindgren

2010-10-21 16:15 UTC #7 lore raw

Quoted 41 lines · Gadiyar, Anand

Quoted 40 lines · Anand
Quoted 25 lines · Tony Lindgren
Quoted 24 lines · Tony Lindgren
Quoted 23 lines · Gadiyar, Anand
Quoted 21 lines · Tony Lindgren
Quoted 8 lines · Anand Gadiyar
Hi all,
linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
Quoted 4 lines
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?
Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine.
So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while.
Looks like current next at 80f8f1f8b33750d954beb386c0c8142d0c01c25c boots again except on 2430sdp it produces a NULL pointer at ubi_io_write.
Oops, sorry it's still broken, wrong tree.
I've started bisecting again - I needed to pick commit 5bac0926121e (driver core: platform_bus: allow runtime override of dev_pm_ops) to solve the build break.

Quoted 5 lines

Quoted 2 lines
Will report back if I find something.
I tried disabling CONFIG_SMP and CONFIG_SMP_ON_UP, and the resulting image booted up just fine.

Looks like it's caused by this patch:

"ARM: hotplug cpu: Keep processor information, startup code & __lookup_processor_type"

It's probably trashing registers it shouldn't. Will take a look and post something to linux-arm-kernel.

Tony

Anand Gadiyar

author

2010-10-22 14:08 UTC #8 lore raw

Quoted 1 line · Tony Lindgren

* Gadiyar, Anand <[email protected]> [101019 23:21]:

...

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
linux-next, as of 20101019, built with the

omap2plus_defconfig fails

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
CONFIG_SWP_EMULATE to get the image to build). Building with

only

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
ARCH_OMAP3 allows the resultant image to boot up on OMAP3.

Likewise,

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?

...

Quoted 4 lines

Quoted 3 lines
I tried disabling CONFIG_SMP and CONFIG_SMP_ON_UP, and the resulting image booted up just fine.

Quoted 8 lines

Looks like it's caused by this patch:
"ARM: hotplug cpu: Keep processor information, startup code & __lookup_processor_type"
It's probably trashing registers it shouldn't. Will take a look and post something to linux-arm-kernel.

I'm not sure what's going on, but looks like linux-next as of 20101022 boots up fine on panda. I can't explain it, as I couldn't find anything related to the patch you mentioned.

- Anand

Tony Lindgren

2010-10-22 18:52 UTC #9 lore raw

Quoted 32 lines · Anand Gadiyar

Quoted 1 line · Tony Lindgren
* Gadiyar, Anand <[email protected]> [101019 23:21]:
...
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
linux-next, as of 20101019, built with the
omap2plus_defconfig fails
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2
or
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
CONFIG_SWP_EMULATE to get the image to build). Building with
only
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
ARCH_OMAP3 allows the resultant image to boot up on OMAP3.
Likewise,
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?
...
Quoted 9 lines
Quoted 3 lines
I tried disabling CONFIG_SMP and CONFIG_SMP_ON_UP, and the resulting image booted up just fine.
Looks like it's caused by this patch:
"ARM: hotplug cpu: Keep processor information, startup code & __lookup_processor_type"

Quoted 7 lines

Quoted 3 lines
It's probably trashing registers it shouldn't. Will take a look and post something to linux-arm-kernel.
I'm not sure what's going on, but looks like linux-next as of 20101022 boots up fine on panda. I can't explain it, as I couldn't find anything related to the patch you mentioned.

Yeah, it's an alignment issue that's why it sometimes works depending on the Kconfig options selected..

For rererence, posted a fix for that at:

https://patchwork.kernel.org/patch/276161/

Tony

Anand Gadiyar

author

2010-10-22 20:16 UTC #10 lore raw

Quoted 41 lines · Tony Lindgren

Quoted 32 lines · Anand Gadiyar
Quoted 1 line · Tony Lindgren
* Gadiyar, Anand<[email protected]> [101019 23:21]:
...
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
linux-next, as of 20101019, built with the
omap2plus_defconfig fails
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2
or
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
CONFIG_SWP_EMULATE to get the image to build). Building with
only
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
ARCH_OMAP3 allows the resultant image to boot up on OMAP3.
Likewise,
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
an image built with only ARCH_OMAP4 boots up on OMAP4 boards.
earlyprintk does not provide any additional prints after "Uncompressing Linux... done, booting the kernel."
Any ideas where to look?
...
Quoted 9 lines
Quoted 3 lines
I tried disabling CONFIG_SMP and CONFIG_SMP_ON_UP, and the resulting image booted up just fine.
Looks like it's caused by this patch:
"ARM: hotplug cpu: Keep processor information, startup code& __lookup_processor_type"
Quoted 7 lines
Quoted 3 lines
It's probably trashing registers it shouldn't. Will take a look and post something to linux-arm-kernel.
I'm not sure what's going on, but looks like linux-next as of 20101022 boots up fine on panda. I can't explain it, as I couldn't find anything related to the patch you mentioned.

Quoted 8 lines

Yeah, it's an alignment issue that's why it sometimes works depending on the Kconfig options selected..
For rererence, posted a fix for that at:
https://patchwork.kernel.org/patch/276161/
Tony

The patch seems to work - thanks! Just curious, how do you go about debugging an issue like this?

- Anand

Tony Lindgren

2010-10-22 21:38 UTC #11 lore raw

Quoted 11 lines · Anand Gadiyar

Quoted 7 lines · Tony Lindgren
Yeah, it's an alignment issue that's why it sometimes works depending on the Kconfig options selected..
For rererence, posted a fix for that at:
https://patchwork.kernel.org/patch/276161/
The patch seems to work - thanks! Just curious, how do you go about debugging an issue like this?

Well it was a bit tricky to find out as random changes to .config would make it work. Found the breaking patch with git bisect, but could not see anything wrong with it. Then thought it somehow misbehaves with CONFIG_SMP_ON_UP, but some printhex8 debugging showed that it happens even earlier. Then went back few lines in the boot to narrow it down, but finally had to step through it with jtag to see that the address loaded into r5 was not aligned.

Tony