[U-Boot] [STATUS] v2010.12-rc2 released
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.
Current status is still a bit wobbly. Power Architecture appears to look reasonably well again. ARM has still a lot of broken boards (which is not unexpected), but a number of fixes have been sent recently, so I guess we will see some improvment in the next few days. I didn't test much for other architectures. Comments and especially patches welcome.
If posssible I'l like to have a -rc3 next weekend, after which I will really accept clear bug fixes only.
Note that we have a "next" branch again, so custodians can send out pull requests of new stuff for "next".
Thanks, and best regards,
Wolfgang Denk
On Tue, 2010-11-30 at 08:00 -0700, Wolfgang Denk 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.
Is it possible to pull Kumar's patch: http://lists.denx.de/pipermail/u-boot/2010-November/082099.html
Since 8xxx ddr spd code calls hwconfig before relocating code, the most 85xx/86xx boards which use 8xxx ddr spd can not bring up without this patch.
Haiying
On Tue, 2010-11-30 at 08:00 -0700, Wolfgang Denk 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.
Is it possible to pull Kumar's patch: http://lists.denx.de/pipermail/u-boot/2010-November/082099.html
Since 8xxx ddr spd code calls hwconfig before relocating code, the most 85xx/86xx boards which use 8xxx ddr spd can not bring up without this patch.
Does const char *cpu_hwconfig __attribute__((weak)) = ""; const char *board_hwconfig __attribute__((weak)) = ""; need to ptrs instead of an array? const char cpu_hwconfig[] __attribute__((weak)) = ""; const char board_hwconfig[] __attribute__((weak)) = "";
All these static string pointers costs extra space, in this case 2x4 bytes for the ptr and 2 fixup entries = 16 bytes
Jocke
On Nov 30, 2010, at 9:23 AM, Joakim Tjernlund wrote:
On Tue, 2010-11-30 at 08:00 -0700, Wolfgang Denk 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.
Is it possible to pull Kumar's patch: http://lists.denx.de/pipermail/u-boot/2010-November/082099.html
Since 8xxx ddr spd code calls hwconfig before relocating code, the most 85xx/86xx boards which use 8xxx ddr spd can not bring up without this patch.
Does const char *cpu_hwconfig __attribute__((weak)) = ""; const char *board_hwconfig __attribute__((weak)) = ""; need to ptrs instead of an array? const char cpu_hwconfig[] __attribute__((weak)) = ""; const char board_hwconfig[] __attribute__((weak)) = "";
All these static string pointers costs extra space, in this case 2x4 bytes for the ptr and 2 fixup entries = 16 bytes
Jocke
We can make them arrays instead. I don't see any reason they need to be pointers.
- k
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.
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, 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.
Best Regards, Ben Gardiner
--- Nanometrics Inc. http://www.nanometrics.ca
Le 30/11/2010 20:50, Ben Gardiner a écrit :
I suppose we should be suspecting the timers? I think I recall hearing that the time code can mix poorly with relocation.
There is no issue with relocation and timers per se, but with the use of BSS variables before relocation. Any code run in the course of executing board_init_f() and which accesses globals can cause problems.
Best Regards, Ben Gardiner
Amicalement,
Dear Albert ARIBAUD,
In message 4CF55ADE.4010003@free.fr you wrote:
I suppose we should be suspecting the timers? I think I recall hearing that the time code can mix poorly with relocation.
There is no issue with relocation and timers per se, but with the use of BSS variables before relocation. Any code run in the course of executing board_init_f() and which accesses globals can cause problems.
Correct. And I would also like to pont out that the problem existed before, it just was not as clearly visible.
Best regards,
Wolfgang Denk
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
On Tue, Nov 30, 2010 at 3:54 PM, Wolfgang Denk wd@denx.de wrote:
Dear Albert ARIBAUD,
In message 4CF55ADE.4010003@free.fr you wrote:
I suppose we should be suspecting the timers? I think I recall hearing that the time code can mix poorly with relocation.
There is no issue with relocation and timers per se, but with the use of BSS variables before relocation. Any code run in the course of executing board_init_f() and which accesses globals can cause problems.
Correct. And I would also like to pont out that the problem existed before, it just was not as clearly visible. [...]
Wolfgang you are correct in pointing that out; I agree that is an important distinction: the failure was not _caused_ by anything that Sekhar did in that patch.
Thanks for the clarification, Albert. I guess that leaves a lot of territory open for possible culprits though.
Sudhakar, this is not a problem that I am prepared to fix; I hope that as the da850evm maintainer you will be able to.
On Wed, Dec 1, 2010 at 4:46 AM, Nori, Sekhar nsekhar@ti.com wrote:
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.
Yes, absolutely. I'm sorry to make it sound like it was your change that caused the failure.
In retrospect, the upside is that you have replied and also CC'd Sudhakar, so maybe he will come back and fix the problem.
[...] 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.
I am using the exact same toolchain, sadly. $arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I built from the v2010.12-rc2 tag (with zero changes to the config), git checkout v2010.12-rc2; make mrproper ;make da850evm_config; make -j9 all
Then I flashed it to SPI using the mono-based sfh_OMAP-L138.exe provided by TI, booted and observed:
OMAP-L138 initialization passed! Booting TI User Boot Loader UBL Version: 1.65 UBL Flashtype: SPI Starting SPI Memory Copy... Valid magicnum, 0x55424CBB, found at offset 0x00010000. DONE Jumping to entry point at 0xC1080000.
Nothing is printed after 'Jumping to entry point.' It looks like I have a different UBL than you, perhaps that is the culprit?
Best Regards, Ben Gardiner
--- Nanometrics Inc. http://www.nanometrics.ca
Hi Sekhar,
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.
And what is the reason why it hung after printing the DRAM message? In effect you say that you also see a bug, so is it correct to assume that you're looking into it?
Thanks Detlev
On Tuesday, November 30, 2010 10:00:20 Wolfgang Denk wrote:
Current status is still a bit wobbly. Power Architecture appears to look reasonably well again. ARM has still a lot of broken boards (which is not unexpected), but a number of fixes have been sent recently, so I guess we will see some improvment in the next few days. I didn't test much for other architectures. Comments and especially patches welcome.
Blackfin seems to be ok now that your env patches have been merged -mike
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Tuesday, November 30, 2010 8:30 PM To: u-boot@lists.denx.de Subject: [U-Boot] [STATUS] v2010.12-rc2 released
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.
Tested for Kirkwood boards, build and execution is sucessfull.
Regards.. Prafulla . .
On Tue, Nov 30, 2010 at 8: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.
I have verified ca9x4_ct_vxp builds cleanly if the following patches are applied:
ARMV7: Vexpress build errors http://lists.denx.de/pipermail/u-boot/2010-November/081033.html ARMV7: Vexpress compile warnings http://lists.denx.de/pipermail/u-boot/2010-November/081034.html ARMV7:ca9x4_ct_vxp: udelay reference fix http://patchwork.ozlabs.org/patch/73478/
John
Hi Wolfgang,
On 12/02/2010 11:13 AM, John Rigby wrote:
On Tue, Nov 30, 2010 at 8: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.
I have verified ca9x4_ct_vxp builds cleanly if the following patches are applied:
ARMV7: Vexpress build errors http://lists.denx.de/pipermail/u-boot/2010-November/081033.html
I found that you had NAKed a patch similar to this one a few weeks ago. So I redid this patch and submitted a new one this morning:
http://lists.denx.de/pipermail/u-boot/2010-December/082984.html
This one removes the #include sys_proto.h. The other 2 patches John listed below should still be valid for this platform.
Thanks, Matt
ARMV7: Vexpress compile warnings http://lists.denx.de/pipermail/u-boot/2010-November/081034.html ARMV7:ca9x4_ct_vxp: udelay reference fix http://patchwork.ozlabs.org/patch/73478/
John _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (12)
-
Albert ARIBAUD -
Ben Gardiner -
Detlev Zundel -
Haiying Wang -
Joakim Tjernlund -
John Rigby -
Kumar Gala -
Matt Waddel -
Mike Frysinger -
Nori, Sekhar -
Prafulla Wadaskar -
Wolfgang Denk