[U-Boot] [STATUS] ARM

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Hi all,

This week-end I intend to go through the board removal patch set and 
apply those patches in it that still fail to compile with the current 
u-boot-arm/master tree. So:

1) if there are any pull requests to u-voot-arm/master in the works, 
please try to submit them soon or at lease let me know, and

2) if there are any board fix patches posted after merge window closure 
and still pending, please also let me know (those before the merge 
window closure should all be in u-boot-arm by now).

ATM, a './MAKEALL arm' on u-boot-arm/master using ELDK 4.2 on a 64-bit 
Natty Ubuntu yields 200 boards built, with 71 boards having warnings or 
errors.

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[Aneesh V]

Hi Albert,

On Friday 19 August 2011 03:39 AM, Albert ARIBAUD wrote:
> Hi all,
> 
> This week-end I intend to go through the board removal patch set and 
> apply those patches in it that still fail to compile with the current 
> u-boot-arm/master tree. So:
> 
> 1) if there are any pull requests to u-voot-arm/master in the works, 
> please try to submit them soon or at lease let me know, and
> 
> 2) if there are any board fix patches posted after merge window closure 
> and still pending, please also let me know (those before the merge 
> window closure should all be in u-boot-arm by now).

I have these patches that fix couple of build issues with OMAP
platforms. I am hoping that Sandeep will pull these soon.

1. http://patchwork.ozlabs.org/patch/107678/
2. http://patchwork.ozlabs.org/patch/108865/

best regards,
Aneesh

[U-Boot] [STATUS] ARM

[Dirk Behme]

On 19.08.2011 11:38, Aneesh V wrote:
> Hi Albert,
>
> On Friday 19 August 2011 03:39 AM, Albert ARIBAUD wrote:
>> Hi all,
>>
>> This week-end I intend to go through the board removal patch set and
>> apply those patches in it that still fail to compile with the current
>> u-boot-arm/master tree. So:
>>
>> 1) if there are any pull requests to u-voot-arm/master in the works,
>> please try to submit them soon or at lease let me know, and

Please don't miss

http://lists.denx.de/pipermail/u-boot/2011-August/098795.html

>> 2) if there are any board fix patches posted after merge window closure
>> and still pending, please also let me know (those before the merge
>> window closure should all be in u-boot-arm by now).
>
> I have these patches that fix couple of build issues with OMAP
> platforms. I am hoping that Sandeep will pull these soon.
>
> 1. http://patchwork.ozlabs.org/patch/107678/
> 2. http://patchwork.ozlabs.org/patch/108865/

Yes, please don't miss these two patches.

Additionally,

http://patchwork.ozlabs.org/patch/109264/

is needed to fix an issue introduced with the patch "mkimage: Add OMAP 
boot image support".

IMHO with these patches all boards in ./MAKEALL ARMV7 should build 
fine, without any warnings. At least the last time I tried it some 
days ago ;) So, if you find additional (new?) issues or if you are 
about removing any _ARMv7_ board, please let us know before that we 
could check.

Many thanks and best regards

Dirk

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Aneesh, Dirk,

Le 19/08/2011 20:19, Dirk Behme a ?crit :
> On 19.08.2011 11:38, Aneesh V wrote:
>> Hi Albert,
>>
>> On Friday 19 August 2011 03:39 AM, Albert ARIBAUD wrote:
>>> Hi all,
>>>
>>> This week-end I intend to go through the board removal patch set and
>>> apply those patches in it that still fail to compile with the current
>>> u-boot-arm/master tree. So:
>>>
>>> 1) if there are any pull requests to u-voot-arm/master in the works,
>>> please try to submit them soon or at lease let me know, and
>
> Please don't miss
>
> http://lists.denx.de/pipermail/u-boot/2011-August/098795.html
>
>>> 2) if there are any board fix patches posted after merge window closure
>>> and still pending, please also let me know (those before the merge
>>> window closure should all be in u-boot-arm by now).
>>
>> I have these patches that fix couple of build issues with OMAP
>> platforms. I am hoping that Sandeep will pull these soon.
>>
>> 1. http://patchwork.ozlabs.org/patch/107678/
>> 2. http://patchwork.ozlabs.org/patch/108865/

Sandeep has requested  that I pick these two in u-boot-arm.

> Yes, please don't miss these two patches.
>
> Additionally,
>
> http://patchwork.ozlabs.org/patch/109264/
>
> is needed to fix an issue introduced with the patch "mkimage: Add OMAP
> boot image support".

I'll extend Sandeep's agreement to this one too.

> IMHO with these patches all boards in ./MAKEALL ARMV7 should build fine,
> without any warnings. At least the last time I tried it some days ago ;)
> So, if you find additional (new?) issues or if you are about removing
> any _ARMv7_ board, please let us know before that we could check.

  I'll apply the three patches above in the coming hours.

> Many thanks and best regards
>
> Dirk

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Hi all,

Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :

>>> 1. http://patchwork.ozlabs.org/patch/107678/

This one lowers bad board builds from 69 to 62, and has been applied.

>>> 2. http://patchwork.ozlabs.org/patch/108865/

This one kind of half-fixes the two boards it touches: they now build 
but with warnings, all the same, of which here is one:

clocks.c:274: warning: comparison is always true due to limited range of 
data type

I'll put this one on hold unless somebody can tell me what's going on.

>> http://patchwork.ozlabs.org/patch/109264/

This one lowers bad board builds from 62 to 58, and has been applied.

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[Dirk Behme]

On 20.08.2011 17:32, Albert ARIBAUD wrote:
> Hi all,
>
> Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
>
>>>> 1. http://patchwork.ozlabs.org/patch/107678/
>
> This one lowers bad board builds from 69 to 62, and has been applied.
>
>>>> 2. http://patchwork.ozlabs.org/patch/108865/
>
> This one kind of half-fixes the two boards it touches: they now build
> but with warnings, all the same, of which here is one:
>
> clocks.c:274: warning: comparison is always true due to limited range of
> data type
>
> I'll put this one on hold unless somebody can tell me what's going on.

Hmm, I haven't seen this yet. But would like to have a look to it.

But, hmm,

http://git.denx.de/?p=u-boot/u-boot-arm.git;a=summary

doesn't show the applied patches yet? Did I miss something?

Best regards

Dirk

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Hi Dirk,

Le 21/08/2011 09:11, Dirk Behme a ?crit :

> But, hmm,
>
> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=summary
>
> doesn't show the applied patches yet? Did I miss something?

You did not; I did -- forgot to push master. Fixed now, thanks for 
pointing this out.

> Best regards
>
> Dirk

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[V, Aneesh]

Hi Albert,

On Sun, Aug 21, 2011 at 12:52 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hi Dirk,
>
> Le 21/08/2011 09:11, Dirk Behme a ?crit :
>
>> But, hmm,
>>
>> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=summary
>>
>> doesn't show the applied patches yet? Did I miss something?
>
> You did not; I did -- forgot to push master. Fixed now, thanks for
> pointing this out.

How about this series:
http://patchwork.ozlabs.org/bundle/aneeshv/armv7-cache-fixes/

If you pull this, I would prefer that you take all the patches
so that there is no regression for OMAP.

best regards,
Aneesh

[U-Boot] [STATUS] ARM

[Dirk Behme]

On 20.08.2011 17:32, Albert ARIBAUD wrote:
> Hi all,
>
> Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
...
>>>> 2. http://patchwork.ozlabs.org/patch/108865/
>
> This one kind of half-fixes the two boards it touches: they now build
> but with warnings, all the same, of which here is one:
>
> clocks.c:274: warning: comparison is always true due to limited range of
> data type
>
> I'll put this one on hold unless somebody can tell me what's going on.

First, the patch 108865 above fixes a linking issue with the SPL for 
these boards. So I think that this is independent of the clocks.c 
warning you report above. That would mean it would be worth to apply 
108865 to fix at least the linking issue.

Second, applying 108865 to the recent u-boot-arm.git doesn't show any 
clocks.c warning for me [1]. Could this be tool chain dependent? I 
tried it with [2] and [3], without any warning.

Btw, about which clocks.c (directory) do we talk?

Best regards

Dirk

[1]

 > cat include/configs/omap4_sdp4430.h | grep CONFIG_SPL_MAX_SIZE
#define CONFIG_SPL_MAX_SIZE             (38 * 1024)

 > ./MAKEALL omap4_sdp4430
Configuring for omap4_sdp4430 board...
    text    data     bss     dec     hex filename
  191043    4468  202816  398327   613f7 ./u-boot

--------------------- SUMMARY ----------------------------
Boards compiled: 1
----------------------------------------------------------

 > cat include/configs/omap4_panda.h | grep CONFIG_SPL_MAX_SIZE
#define CONFIG_SPL_MAX_SIZE             (38 * 1024)

 > ./MAKEALL omap4_panda
Configuring for omap4_panda board...
    text    data     bss     dec     hex filename
  189478    4380  202820  396678   60d86 ./u-boot

--------------------- SUMMARY ----------------------------
Boards compiled: 1
----------------------------------------------------------


[2] gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)

[3] gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)

[U-Boot] [STATUS] ARM

[V, Aneesh]

Hi Dirk,

On Sun, Aug 21, 2011 at 1:16 PM, Dirk Behme <dirk.behme@googlemail.com> wrote:
> On 20.08.2011 17:32, Albert ARIBAUD wrote:
>> Hi all,
>>
>> Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
> ...
>>>>> 2. http://patchwork.ozlabs.org/patch/108865/
>>
>> This one kind of half-fixes the two boards it touches: they now build
>> but with warnings, all the same, of which here is one:
>>
>> clocks.c:274: warning: comparison is always true due to limited range of
>> data type
>>
>> I'll put this one on hold unless somebody can tell me what's going on.
>
> First, the patch 108865 above fixes a linking issue with the SPL for
> these boards. So I think that this is independent of the clocks.c
> warning you report above. That would mean it would be worth to apply
> 108865 to fix at least the linking issue.
>
> Second, applying 108865 to the recent u-boot-arm.git doesn't show any
> clocks.c warning for me [1]. Could this be tool chain dependent? I
> tried it with [2] and [3], without any warning.
>
> Btw, about which clocks.c (directory) do we talk?

I too didn't get this warning. But I see a problem with omap4/clocks.c.

I have submitted a patch just now.
http://patchwork.ozlabs.org/patch/110811/

BTW, thanks for looking into this.

br,
Aneesh

[U-Boot] [STATUS] ARM

[V, Aneesh]

Hi Albert,

On Sat, Aug 20, 2011 at 9:02 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hi all,
>
> Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
>
>>>> 1. http://patchwork.ozlabs.org/patch/107678/
>
> This one lowers bad board builds from 69 to 62, and has been applied.
>
>>>> 2. http://patchwork.ozlabs.org/patch/108865/
>
> This one kind of half-fixes the two boards it touches: they now build
> but with warnings, all the same, of which here is one:
>
> clocks.c:274: warning: comparison is always true due to limited range of
> data type

My tool-chain (Sourcery G++ Lite 2010q1 - GCC 4.4.1) never reported this issue.
But looks like there is indeed a problem. Hopefully the following patch should
solve it:

http://patchwork.ozlabs.org/patch/110811/

best regards,
Aneesh

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Hi Aneesh,

Le 21/08/2011 09:51, V, Aneesh a ?crit :
> Hi Albert,
>
> On Sat, Aug 20, 2011 at 9:02 PM, Albert ARIBAUD
> <albert.u.boot@aribaud.net>  wrote:
>> Hi all,
>>
>> Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
>>
>>>>> 1. http://patchwork.ozlabs.org/patch/107678/
>>
>> This one lowers bad board builds from 69 to 62, and has been applied.
>>
>>>>> 2. http://patchwork.ozlabs.org/patch/108865/
>>
>> This one kind of half-fixes the two boards it touches: they now build
>> but with warnings, all the same, of which here is one:
>>
>> clocks.c:274: warning: comparison is always true due to limited range of
>> data type
>
> My tool-chain (Sourcery G++ Lite 2010q1 - GCC 4.4.1) never reported this issue.
> But looks like there is indeed a problem. Hopefully the following patch should
> solve it:
>
> http://patchwork.ozlabs.org/patch/110811/

This indeed fixes it. Strange that the warning is not emitted by your 
toolchain.

> best regards,
> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[V, Aneesh]

Hi Albert,

On Sun, Aug 21, 2011 at 1:44 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hi Aneesh,
>
> Le 21/08/2011 09:51, V, Aneesh a ?crit :
>>
>> Hi Albert,
>>
>> On Sat, Aug 20, 2011 at 9:02 PM, Albert ARIBAUD
>> <albert.u.boot@aribaud.net> ?wrote:
>>>
>>> Hi all,
>>>
>>> Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
>>>
>>>>>> 1. http://patchwork.ozlabs.org/patch/107678/
>>>
>>> This one lowers bad board builds from 69 to 62, and has been applied.
>>>
>>>>>> 2. http://patchwork.ozlabs.org/patch/108865/
>>>
>>> This one kind of half-fixes the two boards it touches: they now build
>>> but with warnings, all the same, of which here is one:
>>>
>>> clocks.c:274: warning: comparison is always true due to limited range of
>>> data type
>>
>> My tool-chain (Sourcery G++ Lite 2010q1 - GCC 4.4.1) never reported this
>> issue.
>> But looks like there is indeed a problem. Hopefully the following patch
>> should
>> solve it:
>>
>> http://patchwork.ozlabs.org/patch/110811/
>
> This indeed fixes it. Strange that the warning is not emitted by your
> toolchain.

Yes, that's indeed strange. Even with your tool-chain it should've emitted
more warnings. Many of those unsigned variables were assigned -1 in
elsewhere. That was also never reported.

br,
Aneesh

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Hi Aneesh,

Le 21/08/2011 10:56, V, Aneesh a ?crit :

>> This indeed fixes it. Strange that the warning is not emitted by your
>> toolchain.
>
> Yes, that's indeed strange. Even with your tool-chain it should've emitted
> more warnings. Many of those unsigned variables were assigned -1 in
> elsewhere. That was also never reported.

Actually I only gave one of those warnings. For a single build of 
omap4_panda, there was the following:

clocks.c:274: warning: comparison is always true due to limited range of 
data type
clocks.c:276: warning: comparison is always true due to limited range of 
data type
clocks.c:278: warning: comparison is always true due to limited range of 
data type
clocks.c:280: warning: comparison is always true due to limited range of 
data type
clocks.c:282: warning: comparison is always true due to limited range of 
data type
clocks.c:284: warning: comparison is always true due to limited range of 
data type

But note that these are comparisons, not assignments. The semantics of 
ether operation might explain why one causes a warning and not the other.

> br,
> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[Simon Schwarz]

Hi Albert,

On 08/20/2011 01:12 PM, Albert ARIBAUD wrote:
>snip>
>
> Sandeep has requested  that I pick these two in u-boot-arm.
>
<snip>

So is right that everything else in the responsibility of Sandeep won't 
make it into the next release?

How about the next tree?

Regards
Simon

[U-Boot] [STATUS] ARM

[Michael Jones]

Hi Albert,

On 08/22/2011 10:15 AM, Simon Schwarz wrote:
> 
> Hi Albert,
> 
> On 08/20/2011 01:12 PM, Albert ARIBAUD wrote:
>> snip>
>>
>> Sandeep has requested  that I pick these two in u-boot-arm.
>>
> <snip>
> 
> So is right that everything else in the responsibility of Sandeep won't 
> make it into the next release?
> 
> How about the next tree?

I'm also curious about the fate of OMAP patches for the next release. It
seems to me there hasn't been much feedback for OMAP patches this cycle.
The most recent commit at u-boot-ti is a month old now.

For example, I got an ack from Heiko on an OMAP I2C patch [1], and he
asked Sandeep to either ACK/NACK it or pick it up himself, but nothing
has happened with it. The cosmetic patch Heiko refers to there also
hasn't been touched. These were at least reviewed because they
overlapped with I2C, but my OMAP-specific patches [2,3] have gotten
virtually no feedback. I presume, then, that they will not make it in to
v2011.09?

[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/104811
[2] http://patchwork.ozlabs.org/patch/105288/
[3] http://patchwork.ozlabs.org/patch/110298/

> 
> Regards
> Simon

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier

[U-Boot] [STATUS] ARM

[Marek Vasut]

On Friday, August 19, 2011 12:09:56 AM Albert ARIBAUD wrote:
> Hi all,
> 
> This week-end I intend to go through the board removal patch set and
> apply those patches in it that still fail to compile with the current
> u-boot-arm/master tree. So:
> 
> 1) if there are any pull requests to u-voot-arm/master in the works,
> please try to submit them soon or at lease let me know, and
> 
> 2) if there are any board fix patches posted after merge window closure
> and still pending, please also let me know (those before the merge
> window closure should all be in u-boot-arm by now).
> 
> ATM, a './MAKEALL arm' on u-boot-arm/master using ELDK 4.2 on a 64-bit
> Natty Ubuntu yields 200 boards built, with 71 boards having warnings or
> errors.
> 
> Amicalement,

Hi Albert,

where can I find the board removal patchset?

Cheers

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Hi Marek,

Le 20/08/2011 13:16, Marek Vasut a ?crit :
> On Friday, August 19, 2011 12:09:56 AM Albert ARIBAUD wrote:
>> Hi all,
>>
>> This week-end I intend to go through the board removal patch set and
>> apply those patches in it that still fail to compile with the current
>> u-boot-arm/master tree. So:
>>
>> 1) if there are any pull requests to u-voot-arm/master in the works,
>> please try to submit them soon or at lease let me know, and
>>
>> 2) if there are any board fix patches posted after merge window closure
>> and still pending, please also let me know (those before the merge
>> window closure should all be in u-boot-arm by now).
>>
>> ATM, a './MAKEALL arm' on u-boot-arm/master using ELDK 4.2 on a 64-bit
>> Natty Ubuntu yields 200 boards built, with 71 boards having warnings or
>> errors.
>>
>> Amicalement,
>
> Hi Albert,
>
> where can I find the board removal patchset?

Look in patchwork (http://patchwork.ozlabs.org/project/uboot/list/), 
filter with "ARM: remove broken". You many need to remove the "action 
needed" filter to see them all, as some boards are already marked 'Not 
Applicable' or 'Rejected' because they are now building fine.

> Cheers

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[Marek Vasut]

On Saturday, August 20, 2011 01:44:23 PM Albert ARIBAUD wrote:
> Hi Marek,
> 
> Le 20/08/2011 13:16, Marek Vasut a ?crit :
> > On Friday, August 19, 2011 12:09:56 AM Albert ARIBAUD wrote:
> >> Hi all,
> >> 
> >> This week-end I intend to go through the board removal patch set and
> >> apply those patches in it that still fail to compile with the current
> >> u-boot-arm/master tree. So:
> >> 
> >> 1) if there are any pull requests to u-voot-arm/master in the works,
> >> please try to submit them soon or at lease let me know, and
> >> 
> >> 2) if there are any board fix patches posted after merge window closure
> >> and still pending, please also let me know (those before the merge
> >> window closure should all be in u-boot-arm by now).
> >> 
> >> ATM, a './MAKEALL arm' on u-boot-arm/master using ELDK 4.2 on a 64-bit
> >> Natty Ubuntu yields 200 boards built, with 71 boards having warnings or
> >> errors.
> >> 
> >> Amicalement,
> > 
> > Hi Albert,
> > 
> > where can I find the board removal patchset?
> 
> Look in patchwork (http://patchwork.ozlabs.org/project/uboot/list/),
> filter with "ARM: remove broken". You many need to remove the "action
> needed" filter to see them all, as some boards are already marked 'Not
> Applicable' or 'Rejected' because they are now building fine.
> 
> > Cheers
> 
> Amicalement,

Let me send you a few fixes for xscale crap. Do you prefer pull request or just a 
bunch of emails ?

Cheers

[U-Boot] [STATUS] ARM

[Albert ARIBAUD]

Hi Marek,

Le 20/08/2011 14:24, Marek Vasut a ?crit :
> On Saturday, August 20, 2011 01:44:23 PM Albert ARIBAUD wrote:
>> Hi Marek,
>>
>> Le 20/08/2011 13:16, Marek Vasut a ?crit :
>>> On Friday, August 19, 2011 12:09:56 AM Albert ARIBAUD wrote:
>>>> Hi all,
>>>>
>>>> This week-end I intend to go through the board removal patch set and
>>>> apply those patches in it that still fail to compile with the current
>>>> u-boot-arm/master tree. So:
>>>>
>>>> 1) if there are any pull requests to u-voot-arm/master in the works,
>>>> please try to submit them soon or at lease let me know, and
>>>>
>>>> 2) if there are any board fix patches posted after merge window closure
>>>> and still pending, please also let me know (those before the merge
>>>> window closure should all be in u-boot-arm by now).
>>>>
>>>> ATM, a './MAKEALL arm' on u-boot-arm/master using ELDK 4.2 on a 64-bit
>>>> Natty Ubuntu yields 200 boards built, with 71 boards having warnings or
>>>> errors.
>>>>
>>>> Amicalement,
>>>
>>> Hi Albert,
>>>
>>> where can I find the board removal patchset?
>>
>> Look in patchwork (http://patchwork.ozlabs.org/project/uboot/list/),
>> filter with "ARM: remove broken". You many need to remove the "action
>> needed" filter to see them all, as some boards are already marked 'Not
>> Applicable' or 'Rejected' because they are now building fine.
>>
>>> Cheers
>>
>> Amicalement,
>
> Let me send you a few fixes for xscale crap. Do you prefer pull request or just a
> bunch of emails ?

I prefer all PXA/Xscale patches to go through your repository and then a 
pull request from u-boot-pxa/master to u-boot-arm/master be issued; but 
in any case, if the patches have not been posted on the list so far, 
please post them first, then pull them in your repo -- and cc: the 
respective board maintainers.

> Cheers

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM

[Marek Vasut]

On Saturday, August 20, 2011 02:54:02 PM Albert ARIBAUD wrote:
> Hi Marek,
> 
> Le 20/08/2011 14:24, Marek Vasut a ?crit :
> > On Saturday, August 20, 2011 01:44:23 PM Albert ARIBAUD wrote:
> >> Hi Marek,
> >> 
> >> Le 20/08/2011 13:16, Marek Vasut a ?crit :
> >>> On Friday, August 19, 2011 12:09:56 AM Albert ARIBAUD wrote:
> >>>> Hi all,
> >>>> 
> >>>> This week-end I intend to go through the board removal patch set and
> >>>> apply those patches in it that still fail to compile with the current
> >>>> u-boot-arm/master tree. So:
> >>>> 
> >>>> 1) if there are any pull requests to u-voot-arm/master in the works,
> >>>> please try to submit them soon or at lease let me know, and
> >>>> 
> >>>> 2) if there are any board fix patches posted after merge window
> >>>> closure and still pending, please also let me know (those before the
> >>>> merge window closure should all be in u-boot-arm by now).
> >>>> 
> >>>> ATM, a './MAKEALL arm' on u-boot-arm/master using ELDK 4.2 on a 64-bit
> >>>> Natty Ubuntu yields 200 boards built, with 71 boards having warnings
> >>>> or errors.
> >>>> 
> >>>> Amicalement,
> >>> 
> >>> Hi Albert,
> >>> 
> >>> where can I find the board removal patchset?
> >> 
> >> Look in patchwork (http://patchwork.ozlabs.org/project/uboot/list/),
> >> filter with "ARM: remove broken". You many need to remove the "action
> >> needed" filter to see them all, as some boards are already marked 'Not
> >> Applicable' or 'Rejected' because they are now building fine.
> >> 
> >>> Cheers
> >> 
> >> Amicalement,
> > 
> > Let me send you a few fixes for xscale crap. Do you prefer pull request
> > or just a bunch of emails ?
> 
> I prefer all PXA/Xscale patches to go through your repository and then a
> pull request from u-boot-pxa/master to u-boot-arm/master be issued; but
> in any case, if the patches have not been posted on the list so far,
> please post them first, then pull them in your repo -- and cc: the
> respective board maintainers.

The board maintainers seem quite dead. There are two easy patches for PXA now, 
please just pick them if they're fine (they're posted now and while I ran MAKEALL 
on PXA, only zylonite is now FUBAR).

I think Wolfgang will kill Zylonite, but I'll probably (when time permits it) 
merge new version back.

Thanks, Albert!

Cheers
> 
> > Cheers
> 
> Amicalement,

[U-Boot] [STATUS] ARM (Tegra)

[Mike Frysinger]

On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
> 1) if there are any pull requests to u-voot-arm/master in the works,
> please try to submit them soon or at lease let me know, and

we've got some Tegra stuff that seems to be waiting for merging (or at least 
feedback as to anything left that needs to be done so it can be merged):
[RESEND PATCH v3 0/4] Add basic clock and pinmux functions to the Tegra2

to broach the more general tegra question, should these get sent to Tom and 
then he sends them to Albert, or should they get sent directly to Albert 
(since there is no dedicated tegra or nvidia u-boot tree atm) ?  we'd like to 
get this process smoothed out so we dont keep annoying people :).
-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/20110820/d89f4fa2/attachment.pgp 

[U-Boot] [STATUS] ARM (Tegra)

[Mike Frysinger]

On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
> On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
> > 1) if there are any pull requests to u-voot-arm/master in the works,
> > please try to submit them soon or at lease let me know, and
> 
> we've got some Tegra stuff that seems to be waiting for merging (or at
> least feedback as to anything left that needs to be done so it can be
> merged): [RESEND PATCH v3 0/4] Add basic clock and pinmux functions to the
> Tegra2
> 
> to broach the more general tegra question, should these get sent to Tom and
> then he sends them to Albert, or should they get sent directly to Albert
> (since there is no dedicated tegra or nvidia u-boot tree atm) ?  we'd like
> to get this process smoothed out so we dont keep annoying people :).

ping ...

if people dont care either way, we can just set up a u-boot/u-boot-tegra.git 
tree for Albert to pull from
-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/20110830/226fd12e/attachment.pgp 

[U-Boot] [STATUS] ARM (Tegra)

[Albert ARIBAUD]

Le 30/08/2011 17:20, Mike Frysinger a ?crit :
> On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
>> On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
>>> 1) if there are any pull requests to u-voot-arm/master in the works,
>>> please try to submit them soon or at lease let me know, and
>>
>> we've got some Tegra stuff that seems to be waiting for merging (or at
>> least feedback as to anything left that needs to be done so it can be
>> merged): [RESEND PATCH v3 0/4] Add basic clock and pinmux functions to the
>> Tegra2
>>
>> to broach the more general tegra question, should these get sent to Tom and
>> then he sends them to Albert, or should they get sent directly to Albert
>> (since there is no dedicated tegra or nvidia u-boot tree atm) ?  we'd like
>> to get this process smoothed out so we dont keep annoying people :).
>
> ping ...
>
> if people dont care either way, we can just set up a u-boot/u-boot-tegra.git
> tree for Albert to pull from

Seems like people don't care, and I'm fine with applying the patches 
myself, but I don't want to pull from a tree: I'll apply the patches as 
they appear on patchwork.

Are we talking about these four patches?

<http://patchwork.ozlabs.org/patch/110117/>
<http://patchwork.ozlabs.org/patch/110120/>
<http://patchwork.ozlabs.org/patch/110119/>
<http://patchwork.ozlabs.org/patch/110118/>

> -mike

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM (Tegra)

[Simon Glass]

On Tue, Aug 30, 2011 at 8:34 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 30/08/2011 17:20, Mike Frysinger a ?crit :
>>
>> On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
>>>
>>> On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
>>>>
>>>> 1) if there are any pull requests to u-voot-arm/master in the works,
>>>> please try to submit them soon or at lease let me know, and
>>>
>>> we've got some Tegra stuff that seems to be waiting for merging (or at
>>> least feedback as to anything left that needs to be done so it can be
>>> merged): [RESEND PATCH v3 0/4] Add basic clock and pinmux functions to
>>> the
>>> Tegra2
>>>
>>> to broach the more general tegra question, should these get sent to Tom
>>> and
>>> then he sends them to Albert, or should they get sent directly to Albert
>>> (since there is no dedicated tegra or nvidia u-boot tree atm) ? ?we'd
>>> like
>>> to get this process smoothed out so we dont keep annoying people :).
>>
>> ping ...
>>
>> if people dont care either way, we can just set up a
>> u-boot/u-boot-tegra.git
>> tree for Albert to pull from
>
> Seems like people don't care, and I'm fine with applying the patches myself,
> but I don't want to pull from a tree: I'll apply the patches as they appear
> on patchwork.
>
> Are we talking about these four patches?
>
> <http://patchwork.ozlabs.org/patch/110117/>
> <http://patchwork.ozlabs.org/patch/110120/>
> <http://patchwork.ozlabs.org/patch/110119/>
> <http://patchwork.ozlabs.org/patch/110118/>

Yes that's right, thanks.

Regards,
Simon

>
>> -mike
>
> Amicalement,
> --
> Albert.
>

[U-Boot] [STATUS] ARM (Tegra)

[Simon Glass]

Hi Albert,

On Tue, Aug 30, 2011 at 8:57 AM, Simon Glass <sjg@chromium.org> wrote:
> On Tue, Aug 30, 2011 at 8:34 AM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
>> Le 30/08/2011 17:20, Mike Frysinger a ?crit :
>>>
>>> On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
>>>>
>>>> On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
>>>>>
>>>>> 1) if there are any pull requests to u-voot-arm/master in the works,
>>>>> please try to submit them soon or at lease let me know, and
>>>>
>>>> we've got some Tegra stuff that seems to be waiting for merging (or at
>>>> least feedback as to anything left that needs to be done so it can be
>>>> merged): [RESEND PATCH v3 0/4] Add basic clock and pinmux functions to
>>>> the
>>>> Tegra2
>>>>
>>>> to broach the more general tegra question, should these get sent to Tom
>>>> and
>>>> then he sends them to Albert, or should they get sent directly to Albert
>>>> (since there is no dedicated tegra or nvidia u-boot tree atm) ? ?we'd
>>>> like
>>>> to get this process smoothed out so we dont keep annoying people :).
>>>
>>> ping ...
>>>
>>> if people dont care either way, we can just set up a
>>> u-boot/u-boot-tegra.git
>>> tree for Albert to pull from
>>
>> Seems like people don't care, and I'm fine with applying the patches myself,
>> but I don't want to pull from a tree: I'll apply the patches as they appear
>> on patchwork.
>>
>> Are we talking about these four patches?
>>
>> <http://patchwork.ozlabs.org/patch/110117/>
>> <http://patchwork.ozlabs.org/patch/110120/>
>> <http://patchwork.ozlabs.org/patch/110119/>
>> <http://patchwork.ozlabs.org/patch/110118/>

I have just sent v4 to the list, which is a rebase against master, and
also removes a function from a header file as noticed in the review.
Please can you please pick up this one? We can then start working on
the peripheral drivers, etc.

Regards,
Simon

>
> Yes that's right, thanks.
>
> Regards,
> Simon
>
>>
>>> -mike
>>
>> Amicalement,
>> --
>> Albert.
>>
>

[U-Boot] [STATUS] ARM (Tegra)

[Albert ARIBAUD]

Le 30/08/2011 17:57, Simon Glass a ?crit :
> On Tue, Aug 30, 2011 at 8:34 AM, Albert ARIBAUD
> <albert.u.boot@aribaud.net>  wrote:
>> Le 30/08/2011 17:20, Mike Frysinger a ?crit :
>>>
>>> On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
>>>>
>>>> On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
>>>>>
>>>>> 1) if there are any pull requests to u-voot-arm/master in the works,
>>>>> please try to submit them soon or at lease let me know, and
>>>>
>>>> we've got some Tegra stuff that seems to be waiting for merging (or at
>>>> least feedback as to anything left that needs to be done so it can be
>>>> merged): [RESEND PATCH v3 0/4] Add basic clock and pinmux functions to
>>>> the
>>>> Tegra2
>>>>
>>>> to broach the more general tegra question, should these get sent to Tom
>>>> and
>>>> then he sends them to Albert, or should they get sent directly to Albert
>>>> (since there is no dedicated tegra or nvidia u-boot tree atm) ?  we'd
>>>> like
>>>> to get this process smoothed out so we dont keep annoying people :).
>>>
>>> ping ...
>>>
>>> if people dont care either way, we can just set up a
>>> u-boot/u-boot-tegra.git
>>> tree for Albert to pull from
>>
>> Seems like people don't care, and I'm fine with applying the patches myself,
>> but I don't want to pull from a tree: I'll apply the patches as they appear
>> on patchwork.
>>
>> Are we talking about these four patches?
>>
>> <http://patchwork.ozlabs.org/patch/110117/>
>> <http://patchwork.ozlabs.org/patch/110120/>
>> <http://patchwork.ozlabs.org/patch/110119/>
>> <http://patchwork.ozlabs.org/patch/110118/>
>
> Yes that's right, thanks.

There was a comment on 110117 (patch 1/4) from Graeme about 
timer_get_future_us() still being there despite the history. Can you 
post a V4 for patch 1/4 only with this function removed entirely (make 
sure the subject and history are up to date for V4) ?

> Regards,
> Simon

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM (Tegra)

[Simon Glass]

On Tue, Aug 30, 2011 at 9:31 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 30/08/2011 17:57, Simon Glass a ?crit :
>>
>> On Tue, Aug 30, 2011 at 8:34 AM, Albert ARIBAUD
>> <albert.u.boot@aribaud.net> ?wrote:
>>>
>>> Le 30/08/2011 17:20, Mike Frysinger a ?crit :
>>>>
>>>> On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
>>>>>
>>>>> On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
>>>>>>
>>>>>> 1) if there are any pull requests to u-voot-arm/master in the works,
>>>>>> please try to submit them soon or at lease let me know, and
>>>>>
>>>>> we've got some Tegra stuff that seems to be waiting for merging (or at
>>>>> least feedback as to anything left that needs to be done so it can be
>>>>> merged): [RESEND PATCH v3 0/4] Add basic clock and pinmux functions to
>>>>> the
>>>>> Tegra2
>>>>>
>>>>> to broach the more general tegra question, should these get sent to Tom
>>>>> and
>>>>> then he sends them to Albert, or should they get sent directly to
>>>>> Albert
>>>>> (since there is no dedicated tegra or nvidia u-boot tree atm) ? ?we'd
>>>>> like
>>>>> to get this process smoothed out so we dont keep annoying people :).
>>>>
>>>> ping ...
>>>>
>>>> if people dont care either way, we can just set up a
>>>> u-boot/u-boot-tegra.git
>>>> tree for Albert to pull from
>>>
>>> Seems like people don't care, and I'm fine with applying the patches
>>> myself,
>>> but I don't want to pull from a tree: I'll apply the patches as they
>>> appear
>>> on patchwork.
>>>
>>> Are we talking about these four patches?
>>>
>>> <http://patchwork.ozlabs.org/patch/110117/>
>>> <http://patchwork.ozlabs.org/patch/110120/>
>>> <http://patchwork.ozlabs.org/patch/110119/>
>>> <http://patchwork.ozlabs.org/patch/110118/>
>>
>> Yes that's right, thanks.
>
> There was a comment on 110117 (patch 1/4) from Graeme about
> timer_get_future_us() still being there despite the history. Can you post a
> V4 for patch 1/4 only with this function removed entirely (make sure the
> subject and history are up to date for V4) ?

Hi Albert,

I just resent the series as v4 with this change - is that OK?

Regards,
Simon

> Amicalement,
> --
> Albert.
>

[U-Boot] [STATUS] ARM (Tegra)

[Albert ARIBAUD]

Le 30/08/2011 18:36, Simon Glass a ?crit :

> Hi Albert,
>
> I just resent the series as v4 with this change - is that OK?

Apologies -- I had not seen the V4 before posting.

V4 is fine to me and since there was only one comment for V3 and V4's 
only change is to address this comment, I think I can apply V4 right away.

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM (Tegra)

[Simon Glass]

On Tue, Aug 30, 2011 at 9:39 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 30/08/2011 18:36, Simon Glass a ?crit :
>
>> Hi Albert,
>>
>> I just resent the series as v4 with this change - is that OK?
>
> Apologies -- I had not seen the V4 before posting.
>
> V4 is fine to me and since there was only one comment for V3 and V4's only
> change is to address this comment, I think I can apply V4 right away.

Thank you Albert. Will wait for this, then get to work on the next
series. - Simon

>
> Amicalement,
> --
> Albert.
>

[U-Boot] [STATUS] ARM

[Dirk Behme]

On 19.08.2011 00:09, Albert ARIBAUD wrote:
> Hi all,
>
> This week-end I intend to go through the board removal patch set and
> apply those patches in it that still fail to compile with the current
> u-boot-arm/master tree. So:
>
> 1) if there are any pull requests to u-voot-arm/master in the works,
> please try to submit them soon or at lease let me know, and
>
> 2) if there are any board fix patches posted after merge window closure
> and still pending, please also let me know (those before the merge
> window closure should all be in u-boot-arm by now).

For me, recent u-boot-arm.git [1] compiles ./MAKEALL ARMV7 fine now:

 > ./MAKEALL ARMV7
...
--------------------- SUMMARY ----------------------------
Boards compiled: 31
----------------------------------------------------------

:)

Many thanks

Dirk

[1]

commit 5557e86bb0793012057d5462976c2a902bc629ac
omap4: increase SRAM budget to fix build error

[U-Boot] [STATUS] ARM status as of 2011-08-30

[Albert ARIBAUD]

Hi all,

I have just applied Wolfgang's updated ARM board removal patch set.

Currently, u-boot-arm/master builds 182 boards, of which:

- ELDK4.2 finds 37 boards with warnings or errors ( dnp1110 gcplus lart 
shannon ep7312 evb4510 impa7 lpc2292sodimm modnet50 SMN42 jadecpu 
smdk2410 VCMA9 versatile omap2420h4 apollon imx31_phycore 
imx31_phycore_eet mx31pdk mx31pdk_nand qong smdk6400 csb226 lubbock 
zylonite actux1_4_16 actux1_8_16 actux1_4_32 actux1_8_32 actux2 actux3 
actux4 dvlhost ixdp425 ixdpg425 pdnb3 scpu )

- CodeSourcery 2010q1 finds 100 (!) boards with warnings or errors ( 
dnp1110 gcplus lart shannon ep7312 evb4510 impa7 lpc2292sodimm modnet50 
SMN42 edminiv2 guruplug jadecpu km_kirkwood mv88f6281gtw_ge openrd_base 
openrd_client openrd_ultimate portl2 rd6281a sheevaplug smdk2410 VCMA9 
versatile omap2420h4 apollon imx31_phycore imx31_phycore_eet mx31pdk 
mx31pdk_nand qong smdk6400 efikamx at91rm9200ek at91rm9200ek_ram 
afeb9260 at91sam9260ek_nandflash at91sam9260ek_dataflash_cs0 
at91sam9260ek_dataflash_cs1 at91sam9261ek_nandflash 
at91sam9261ek_dataflash_cs0 at91sam9261ek_dataflash_cs3 
at91sam9263ek_nandflash at91sam9263ek_dataflash_cs0 
at91sam9263ek_dataflash at91sam9263ek_norflash 
at91sam9263ek_norflash_boot at91sam9g10ek_nandflash 
at91sam9g10ek_dataflash_cs0 at91sam9g10ek_dataflash_cs3 
at91sam9g20ek_nandflash at91sam9g20ek_dataflash_cs0 
at91sam9g20ek_dataflash_cs1 at91sam9m10g45ek_nandflash 
at91sam9xeek_nandflash at91sam9xeek_dataflash_cs0 
at91sam9xeek_dataflash_cs1 snapper9260 snapper9g20 sbc35_a9g20_nandflash 
sbc35_a9g20_eeprom cpu9260 cpu9260_nand cpu9260_128M cpu9260_nand_128M 
cpu9G20 cpu9G20_nand cpu9G20_128M cpu9G20_nand_128M top9000eval_xe 
top9000su_xe meesc meesc_dataflash otc570 otc570_dataflash pm9261 pm9263 
pm9g45 balloon3 colibri_pxa270 csb226 lubbock polaris trizepsiv 
vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 zylonite actux1_4_16 
actux1_8_16 actux1_4_32 actux1_8_32 actux2 actux3 actux4 dvlhost ixdp425 
ixdpg425 pdnb3 scpu )

However, most of the errors in the CodeSourcery case are actually the 
same, i.e. "warning: dereferencing pointer 'xxxxx' does break 
strict-aliasing rules", mostly in drivers/usb/host/ohci-hcd.c and once 
in fs/yaffs2/yaffs_tagscompat.c -- that is, errors seem not to be 
ARM-specific but rather compiler-dependent -- seems like each compiler 
has its own sensitivity. ELDK4.2 also has some errors in YAFFS code, BTW.

(Cc:ing R?my for USB stuff; for yaffs, I don't know whom I should Cc:)

For both CS and ELDK, there are a lot of "arm-linux-ld: stubs.o: 
compiled for a big endian system and target is little endian
arm-linux-ld: failed to merge target specific data of file stubs.o" 
which I'll look into.

Meanwhile, I suggest that the current u-boot-arm/master be considered 
rc1-ready, with the effort until rc2 focused on finding and fixing 
code-wide bugs such as those two above.

If that is ok, I'll send out a pull request today.

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM status as of 2011-08-30

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4E5D088B.7090702@aribaud.net> you wrote:
> 
> I have just applied Wolfgang's updated ARM board removal patch set.
> 
> Currently, u-boot-arm/master builds 182 boards, of which:
> 
> - ELDK4.2 finds 37 boards with warnings or errors ( dnp1110 gcplus lart 

I think we should try and separate the errors cases from the warnings
only ones - those boards with build errors need to be fixed, or
removed.

We can clean up warnings then, as we go on.

> - CodeSourcery 2010q1 finds 100 (!) boards with warnings or errors ( 

I guess it's additional warnings.  You will see even more when using
ELDK 5.x

> (Cc:ing R?my for USB stuff; for yaffs, I don't know whom I should Cc:)

yeaffs is generic code, i. e. it ends up on my plate.

> For both CS and ELDK, there are a lot of "arm-linux-ld: stubs.o: 
> compiled for a big endian system and target is little endian
> arm-linux-ld: failed to merge target specific data of file stubs.o" 
> which I'll look into.

You need a big endian ARM compiler for the ixp systems.

> Meanwhile, I suggest that the current u-boot-arm/master be considered 
> rc1-ready, with the effort until rc2 focused on finding and fixing 
> code-wide bugs such as those two above.

Agreed.

> If that is ok, I'll send out a pull request today.

Thanks a lot!

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
I realize that command does have its fascination, even under  circum-
stances such as these, but I neither enjoy the idea of command nor am
I  frightened  of  it. It simply exists, and I will do whatever logi-
cally needs to be done.
	-- Spock, "The Galileo Seven", stardate 2812.7

[U-Boot] [STATUS] ARM status as of 2011-08-30

[Albert ARIBAUD]

Le 30/08/2011 21:08, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4E5D088B.7090702@aribaud.net>  you wrote:
>>
>> I have just applied Wolfgang's updated ARM board removal patch set.
>>
>> Currently, u-boot-arm/master builds 182 boards, of which:
>>
>> - ELDK4.2 finds 37 boards with warnings or errors ( dnp1110 gcplus lart
>
> I think we should try and separate the errors cases from the warnings
> only ones - those boards with build errors need to be fixed, or
> removed.

Right, but the current MAKEALL output does not make it easy to sort this 
out. Maybe we could change MAKEALL to distinguish between error and 
warning counts (and produce LOG/*.MAKELOG, LOG/*.ERR and LOG/*.WARN 
accordingly).

> We can clean up warnings then, as we go on.

Agreed. However, I'd prefer it if no ARM board produced any warning -- 
granted, here it *looks like* many of these warnings are inocuous, and 
any new toolchain might produce some more, but if we don't keep the 
warning count at zero, then a less inocuous warning could creep in 
unnoticed.

>> - CodeSourcery 2010q1 finds 100 (!) boards with warnings or errors (
>
> I guess it's additional warnings.  You will see even more when using
> ELDK 5.x
>
>> (Cc:ing R?my for USB stuff; for yaffs, I don't know whom I should Cc:)
>
> yeaffs is generic code, i. e. it ends up on my plate.

There you are, then. :)

>> For both CS and ELDK, there are a lot of "arm-linux-ld: stubs.o:
>> compiled for a big endian system and target is little endian
>> arm-linux-ld: failed to merge target specific data of file stubs.o"
>> which I'll look into.
>
> You need a big endian ARM compiler for the ixp systems.

Got it -- actually, it is not a compiler issue, but a library issue: CS 
does compile for big-endian as well as little-endian, but does not 
provide big-endian libs 
(<http://www.codesourcery.com/sgpp/lite/arm/portal/kbentry36>, at least 
as I understand it). Apparently ELDK4.2 does not either. Would ELDK5.0 
have them? I haven't gotten around to setting it up.

>> Meanwhile, I suggest that the current u-boot-arm/master be considered
>> rc1-ready, with the effort until rc2 focused on finding and fixing
>> code-wide bugs such as those two above.
>
> Agreed.
>
>> If that is ok, I'll send out a pull request today.
>
> Thanks a lot!

Done, with a few hour's delay.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [STATUS] ARM status as of 2011-08-30

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4E5E0C2E.2030902@aribaud.net> you wrote:
>
> Got it -- actually, it is not a compiler issue, but a library issue: CS 
> does compile for big-endian as well as little-endian, but does not 
> provide big-endian libs 
> (<http://www.codesourcery.com/sgpp/lite/arm/portal/kbentry36>, at least 
> as I understand it). Apparently ELDK4.2 does not either. Would ELDK5.0 
> have them? I haven't gotten around to setting it up.

Sorry, no.  The relevance of IXP is not even close to justifying the
efforts to support a configuation for it.

> Done, with a few hour's delay.

At the moment I'm on hold, as you asked for.

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
"Free markets select for winning solutions."        - Eric S. Raymond