Hi Kevin and Paul,
Would either of you mind looking at this bug report? On the IGEP, when booting with DT is used, something appears to get messed up with initializing the clocks. In this case, the device tree isn't actually doing anything other than replacing ATAGs for passing memory size, command line and initrd address. There /shouldn't/ be any difference between ATAG and DT booting, but obviously something has gone wrong. I've attached to the bug a diff between the log output of a working boot (ATAGs) and a non working boot (DT).
https://bugs.launchpad.net/linux-linaro/+bug/768680
Thanks, g.
On Thu, 19 May 2011, Grant Likely wrote:
Would either of you mind looking at this bug report? On the IGEP, when booting with DT is used, something appears to get messed up with initializing the clocks. In this case, the device tree isn't actually doing anything other than replacing ATAGs for passing memory size, command line and initrd address. There /shouldn't/ be any difference between ATAG and DT booting, but obviously something has gone wrong. I've attached to the bug a diff between the log output of a working boot (ATAGs) and a non working boot (DT).
Mainline kernels don't change anything with the clock configuration before the "Clocking rate (Crystal/Core/MPU):" is printed. No idea about Linaro kernels; one would hope they don't act any differently in this regard. So given that the submitter is using different X-Loader and U-Boot versions:
-Texas Instruments X-Loader 1.4.2-1 (Mar 22 2010 - 08:57:12) +Texas Instruments X-Loader 1.5.0 (Apr 11 2011 - 09:47:30)
-U-Boot 2009.11-1 (Mar 22 2010 - 10:41:15) +U-Boot 2011.03 (Apr 20 2011 - 07:02:48)
the problem is unlikely to be in the kernel.
I'd suggest booting a kernel with ATAGs with the same X-Loader/U-boot versions and making sure that works.
- Paul
On Thu, May 19, 2011 at 11:55 AM, Paul Walmsley paul@pwsan.com wrote:
On Thu, 19 May 2011, Grant Likely wrote:
Would either of you mind looking at this bug report? On the IGEP, when booting with DT is used, something appears to get messed up with initializing the clocks. In this case, the device tree isn't actually doing anything other than replacing ATAGs for passing memory size, command line and initrd address. There /shouldn't/ be any difference between ATAG and DT booting, but obviously something has gone wrong. I've attached to the bug a diff between the log output of a working boot (ATAGs) and a non working boot (DT).
Mainline kernels don't change anything with the clock configuration before the "Clocking rate (Crystal/Core/MPU):" is printed. No idea about Linaro kernels; one would hope they don't act any differently in this regard. So given that the submitter is using different X-Loader and U-Boot versions:
-Texas Instruments X-Loader 1.4.2-1 (Mar 22 2010 - 08:57:12) +Texas Instruments X-Loader 1.5.0 (Apr 11 2011 - 09:47:30)
-U-Boot 2009.11-1 (Mar 22 2010 - 10:41:15) +U-Boot 2011.03 (Apr 20 2011 - 07:02:48)
the problem is unlikely to be in the kernel.
I'd suggest booting a kernel with ATAGs with the same X-Loader/U-boot versions and making sure that works.
kiko [cc'd] was planning to do exactly that when we talked yesterday.
g.
On Thu, May 19, 2011 at 12:01:50PM -0600, Grant Likely wrote:
Mainline kernels don't change anything with the clock configuration before the "Clocking rate (Crystal/Core/MPU):" is printed. No idea about Linaro kernels; one would hope they don't act any differently in this regard.
Yeah, I don't think they do.
So given that the submitter is using different X-Loader and U-Boot versions:
-Texas Instruments X-Loader 1.4.2-1 (Mar 22 2010 - 08:57:12) +Texas Instruments X-Loader 1.5.0 (Apr 11 2011 - 09:47:30)
-U-Boot 2009.11-1 (Mar 22 2010 - 10:41:15) +U-Boot 2011.03 (Apr 20 2011 - 07:02:48)
the problem is unlikely to be in the kernel.
I'd suggest booting a kernel with ATAGs with the same X-Loader/U-boot versions and making sure that works.
kiko [cc'd] was planning to do exactly that when we talked yesterday.
I did that today, and I have concluded the same as Paul: the uboot is hosed. I am hoping John can help me figure out why we're shipping a busted uboot image in our rootfs ;-)
I've added copious comments and a few logs to the bug.
On Fri, May 20, 2011 at 10:37:08AM -0300, Christian Robottom Reis wrote:
On Thu, May 19, 2011 at 12:01:50PM -0600, Grant Likely wrote:
Mainline kernels don't change anything with the clock configuration before the "Clocking rate (Crystal/Core/MPU):" is printed. No idea about Linaro kernels; one would hope they don't act any differently in this regard.
Yeah, I don't think they do.
So given that the submitter is using different X-Loader and U-Boot versions:
-Texas Instruments X-Loader 1.4.2-1 (Mar 22 2010 - 08:57:12) +Texas Instruments X-Loader 1.5.0 (Apr 11 2011 - 09:47:30)
-U-Boot 2009.11-1 (Mar 22 2010 - 10:41:15) +U-Boot 2011.03 (Apr 20 2011 - 07:02:48)
the problem is unlikely to be in the kernel.
I'd suggest booting a kernel with ATAGs with the same X-Loader/U-boot versions and making sure that works.
kiko [cc'd] was planning to do exactly that when we talked yesterday.
I did that today, and I have concluded the same as Paul: the uboot is hosed. I am hoping John can help me figure out why we're shipping a busted uboot image in our rootfs ;-)
I've added copious comments and a few logs to the bug.
Thanks kiko.
g.
-
Christian Robottom Reis -
Grant Likely -
Paul Walmsley