Hi Ben,
On Wed, Dec 01, 2010 at 01:20:36, Ben Gardiner wrote:
On Tue, Nov 30, 2010 at 10:00 AM, Wolfgang Denk wd@denx.de wrote:
Hello everybody.
I apologise for being a bit late with this announcement:
U-Boot v2010.12-rc2 was released on Sunday, November 28.
Release "v2010.12" is (still) scheduled in 13 days:
on December 13, 2010.
Please help testing, and check if all your relevant patches have been included.
da850evm was broken by
commit 4f6fc15b42776b12244af8aa28da42c8e6497742 Author: Sekhar Nori nsekhar@ti.com Date: Fri Nov 19 11:39:48 2010 -0500
DA850 EVM: passing maximum clock rate information to kernel The TI DA850/OMAP-L138/AM18x EVM can be populated with devices having different maximum allowed CPU clock rating. The maximum clock the chip can support can only be determined from the label on the package (not software readable). Introduce a method to pass the maximum allowed clock rate information to kernel using ATAG_REVISION. The kernel uses this information to determine the maximum cpu clock rate reachable using cpufreq. Note that U-Boot itself does not set the CPU clock rate. The CPU clock is setup by a primary bootloader ("UBL"). The rate setup by UBL could be different from the maximum clock rate supported by the device. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>With the introduction of this patch the board freezes after UBL jumps to 0xC1080000; however, I don't think it was the implementation in this patch that caused the breakage.
Hmm, I had tested DA850 EVM yesterday with U-Boot 2010.12-rc2, and was able to successfully boot (at least most of the times).
---logs---- Booting with TI UBL Device OPP (300MHz, 1.2V)
U-Boot 2010.12-rc2 (Nov 30 2010 - 11:55:35)
I2C: ready DRAM: 128 MiB Using default environment
In: serial Out: serial Err: serial Net: Ethernet PHY: GENERIC @ 0x00
DA850-evm > --------
Some of the times, the boot hung after printing DRAM: 128 MiB, but never did it hang without printing anything.
Removing the added "#define CONFIG_REVISION_TAG" does not fix the freeze. Furthermore, reverting the patch on top of 2010.12-rc2 does not fix the freeze either. Finally to add to the (/my) confusion,
Ah, that is a sure indication that the issue is elsewhere.
adding OPTFLAGS="-O0 -g" to 4f6fc15b42776b12244af8aa28da42c8e6497742^ (the commit parent) results in a boot freeze, where there was none before the addition of the compiler flags.
I suppose we should be suspecting the timers? I think I recall hearing that the time code can mix poorly with relocation.
I am not sure about that (haven't been following all the relocation related changes lately). Since it is booting for me, may be it is related to the build environment? I am using CodeSourcery 2009q1-203 for building the U-Boot.
Thanks, Sekhar