[U-Boot] [STATUS] v2010.12-rc2 released

[U-Boot] [STATUS] v2010.12-rc2 released

[Carlo Caione]

> Some of the times, the boot hung after printing DRAM: 128 MiB,
> but never did it hang without printing anything.

The same here.
Beagleboard xM rev.A hangs after DRAM: 256 MiB

Regards,

--
Carlo Caione

[U-Boot] [STATUS] v2010.12-rc2 released

[Prafulla Wadaskar]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of Carlo Caione
> Sent: Friday, December 03, 2010 3:11 AM
> To: U-Boot at lists.denx.de
> Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released
> 
> > Some of the times, the boot hung after printing DRAM: 128 MiB,
> > but never did it hang without printing anything.
> 
> The same here.
> Beagleboard xM rev.A hangs after DRAM: 256 MiB

For fix this, needs to change global variables in timer.c
REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html

Regards..
Prafulla .. 

[U-Boot] [STATUS] v2010.12-rc2 released

[Carlo Caione]

On Thu, 2010-12-02 at 20:40 -0800, Prafulla Wadaskar wrote:
> 
> > -----Original Message-----
> > From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> > On Behalf Of Carlo Caione
> > Sent: Friday, December 03, 2010 3:11 AM
> > To: U-Boot at lists.denx.de
> > Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released
> > 
> > > Some of the times, the boot hung after printing DRAM: 128 MiB,
> > > but never did it hang without printing anything.
> > 
> > The same here.
> > Beagleboard xM rev.A hangs after DRAM: 256 MiB
> 
> For fix this, needs to change global variables in timer.c
> REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html

Applied but nothing is changed:

Texas Instruments X-Loader 1.4.4ss (Dec  2 2010 - 21:40:58)
Beagle xM Rev A
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2010.12-rc2-00029-g49733aa-dirty (Dec 03 2010 - 22:05:44)

OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MiB

Regards,

--
Carlo Caione

[U-Boot] OMAP: Hang after memory init, was: [STATUS] v2010.12-rc2 released

[Dirk Behme]

On 03.12.2010 22:11, Carlo Caione wrote:
> On Thu, 2010-12-02 at 20:40 -0800, Prafulla Wadaskar wrote:
>>
>>> -----Original Message-----
>>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
>>> On Behalf Of Carlo Caione
>>> Sent: Friday, December 03, 2010 3:11 AM
>>> To: U-Boot at lists.denx.de
>>> Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released
>>>
>>>> Some of the times, the boot hung after printing DRAM: 128 MiB,
>>>> but never did it hang without printing anything.
>>>
>>> The same here.
>>> Beagleboard xM rev.A hangs after DRAM: 256 MiB
>>
>> For fix this, needs to change global variables in timer.c
>> REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html
>
> Applied but nothing is changed:
>
> Texas Instruments X-Loader 1.4.4ss (Dec  2 2010 - 21:40:58)
> Beagle xM Rev A
> Reading boot sector
> Loading u-boot.bin from mmc
>
>
> U-Boot 2010.12-rc2-00029-g49733aa-dirty (Dec 03 2010 - 22:05:44)
>
> OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
> OMAP3 Beagle board + LPDDR/NAND
> I2C:   ready
> DRAM:  512 MiB

I'm not totally sure, so sorry if I'm wrong. But:

I understood the link given by Prafulla above only as a reference what 
has to be done to fix the OMAP hang. I don't think the given patch 
fixes the issue itself. Most probably we additionally need something like

http://lists.denx.de/pipermail/u-boot/2010-December/082965.html

for OMAP, too?

Best regards

Dirk

[U-Boot] OMAP: Hang after memory init, was: [STATUS] v2010.12-rc2 released

[Albert ARIBAUD]

Le 04/12/2010 07:51, Dirk Behme a ?crit :
> On 03.12.2010 22:11, Carlo Caione wrote:
>> On Thu, 2010-12-02 at 20:40 -0800, Prafulla Wadaskar wrote:
>>>
>>>> -----Original Message-----
>>>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
>>>> On Behalf Of Carlo Caione
>>>> Sent: Friday, December 03, 2010 3:11 AM
>>>> To: U-Boot at lists.denx.de
>>>> Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released
>>>>
>>>>> Some of the times, the boot hung after printing DRAM: 128 MiB,
>>>>> but never did it hang without printing anything.
>>>>
>>>> The same here.
>>>> Beagleboard xM rev.A hangs after DRAM: 256 MiB
>>>
>>> For fix this, needs to change global variables in timer.c
>>> REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html
>>
>> Applied but nothing is changed:
>>
>> Texas Instruments X-Loader 1.4.4ss (Dec  2 2010 - 21:40:58)
>> Beagle xM Rev A
>> Reading boot sector
>> Loading u-boot.bin from mmc
>>
>>
>> U-Boot 2010.12-rc2-00029-g49733aa-dirty (Dec 03 2010 - 22:05:44)
>>
>> OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
>> OMAP3 Beagle board + LPDDR/NAND
>> I2C:   ready
>> DRAM:  512 MiB
>
> I'm not totally sure, so sorry if I'm wrong. But:
>
> I understood the link given by Prafulla above only as a reference what
> has to be done to fix the OMAP hang. I don't think the given patch
> fixes the issue itself. Most probably we additionally need something like
>
> http://lists.denx.de/pipermail/u-boot/2010-December/082965.html
>
> for OMAP, too?

Also make sure that the r8 register is not trashed by the relocation 
code in the start.S used for this board. See Andreas' patch for that.

> Best regards
>
> Dirk

Amicalement,
-- 
Albert.

[U-Boot] OMAP: Hang after memory init

[Dirk Behme]

On 04.12.2010 09:07, Albert ARIBAUD wrote:
> Le 04/12/2010 07:51, Dirk Behme a ?crit :
>> On 03.12.2010 22:11, Carlo Caione wrote:
>>> On Thu, 2010-12-02 at 20:40 -0800, Prafulla Wadaskar wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
>>>>> On Behalf Of Carlo Caione
>>>>> Sent: Friday, December 03, 2010 3:11 AM
>>>>> To: U-Boot at lists.denx.de
>>>>> Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released
>>>>>
>>>>>> Some of the times, the boot hung after printing DRAM: 128 MiB,
>>>>>> but never did it hang without printing anything.
>>>>>
>>>>> The same here.
>>>>> Beagleboard xM rev.A hangs after DRAM: 256 MiB
>>>>
>>>> For fix this, needs to change global variables in timer.c
>>>> REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html
>>>
>>> Applied but nothing is changed:
>>>
>>> Texas Instruments X-Loader 1.4.4ss (Dec  2 2010 - 21:40:58)
>>> Beagle xM Rev A
>>> Reading boot sector
>>> Loading u-boot.bin from mmc
>>>
>>>
>>> U-Boot 2010.12-rc2-00029-g49733aa-dirty (Dec 03 2010 - 22:05:44)
>>>
>>> OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
>>> OMAP3 Beagle board + LPDDR/NAND
>>> I2C:   ready
>>> DRAM:  512 MiB
>>
>> I'm not totally sure, so sorry if I'm wrong. But:
>>
>> I understood the link given by Prafulla above only as a reference what
>> has to be done to fix the OMAP hang. I don't think the given patch
>> fixes the issue itself. Most probably we additionally need something like
>>
>> http://lists.denx.de/pipermail/u-boot/2010-December/082965.html
>>
>> for OMAP, too?
>
> Also make sure that the r8 register is not trashed by the relocation
> code in the start.S used for this board. See Andreas' patch for that.

Thanks for the hint! Most probably you mean

http://lists.denx.de/pipermail/u-boot/2010-December/082807.html

?

This does mean that for Beagle we need at least

http://lists.denx.de/pipermail/u-boot/2010-December/082806.html
http://lists.denx.de/pipermail/u-boot/2010-December/082805.html
http://lists.denx.de/pipermail/u-boot/2010-December/082807.html
http://lists.denx.de/pipermail/u-boot/2010-December/082808.html
http://lists.denx.de/pipermail/u-boot/2010-December/082834.html

plus something like

http://lists.denx.de/pipermail/u-boot/2010-December/082965.html

for OMAP (still to be written)?

Thanks

Dirk

[U-Boot] OMAP: Hang after memory init

[Albert ARIBAUD]

Le 04/12/2010 10:33, Dirk Behme a ?crit :

>> Also make sure that the r8 register is not trashed by the relocation
>> code in the start.S used for this board. See Andreas' patch for that.
>
> Thanks for the hint! Most probably you mean
>
> http://lists.denx.de/pipermail/u-boot/2010-December/082807.html
>
> ?

Yes.

> This does mean that for Beagle we need at least
>
> http://lists.denx.de/pipermail/u-boot/2010-December/082806.html
> http://lists.denx.de/pipermail/u-boot/2010-December/082805.html
> http://lists.denx.de/pipermail/u-boot/2010-December/082807.html
> http://lists.denx.de/pipermail/u-boot/2010-December/082808.html
> http://lists.denx.de/pipermail/u-boot/2010-December/082834.html

Yes - note that ...806 and ...805 are useful but not required to get the 
board working, IIUC.

> plus something like
>
> http://lists.denx.de/pipermail/u-boot/2010-December/082965.html
>
> for OMAP (still to be written)?

Yes.

> Thanks
>
> Dirk

Amicalement,
-- 
Albert.

[U-Boot] OMAP: Hang after memory init

[Dirk Behme]

On 04.12.2010 11:48, Albert ARIBAUD wrote:
> Le 04/12/2010 10:33, Dirk Behme a ?crit :
>
>>> Also make sure that the r8 register is not trashed by the relocation
>>> code in the start.S used for this board. See Andreas' patch for that.
>>
>> Thanks for the hint! Most probably you mean
>>
>> http://lists.denx.de/pipermail/u-boot/2010-December/082807.html
>>
>> ?
>
> Yes.
>
>> This does mean that for Beagle we need at least
>>
>> http://lists.denx.de/pipermail/u-boot/2010-December/082806.html
>> http://lists.denx.de/pipermail/u-boot/2010-December/082805.html
>> http://lists.denx.de/pipermail/u-boot/2010-December/082807.html
>> http://lists.denx.de/pipermail/u-boot/2010-December/082808.html
>> http://lists.denx.de/pipermail/u-boot/2010-December/082834.html
>
> Yes - note that ...806 and ...805 are useful but not required to get
> the board working, IIUC.

After all above patches are in mainline now ...

>> plus something like
>>
>> http://lists.denx.de/pipermail/u-boot/2010-December/082965.html
>>
>> for OMAP (still to be written)?

... does anybody like to test

http://lists.denx.de/pipermail/u-boot/2010-December/083449.html

on top of recent U-Boot master? Does this fix the OMAP hang?

Thanks

Dirk

[U-Boot] [STATUS] v2010.12-rc2 released

[Matt Waddel]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [STATUS] v2010.12-rc2 released

[John Rigby]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Detlev Zundel]

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

-- 
Perfection (in design) is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
                                        -- Antoine de Saint-Exupery
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [STATUS] v2010.12-rc2 released

[Ben Gardiner]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Prafulla Wadaskar]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of Wolfgang Denk
> Sent: Tuesday, November 30, 2010 8:30 PM
> To: u-boot at 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 . .

[U-Boot] [STATUS] v2010.12-rc2 released

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101201/880bd9b0/attachment.pgp 

[U-Boot] [STATUS] v2010.12-rc2 released

[Nori, Sekhar]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"What if" is a trademark of Hewlett Packard, so stop using it in your
sentences without permission, or risk being sued.

[U-Boot] [STATUS] v2010.12-rc2 released

[Albert ARIBAUD]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Ben Gardiner]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Kumar Gala]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Joakim Tjernlund]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Haiying Wang]

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

[U-Boot] [STATUS] v2010.12-rc2 released

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
      Bugs are by far the largest and  most successful class of
      entity, with nearly a million known species. In this res-
      pect they outnumber all the other  known  creatures about
      four to one.  -- Professor Snope's Encyclopedia of Animal