ARM
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,
Signature · 1 line
Albert.
Hi Albert,
Quoted 6 lines · 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:
Quoted 6 lines
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
Quoted 11 lines · Aneesh V
Hi Albert,
Quoted 8 lines · 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
Please don't miss
http://lists.denx.de/pipermail/u-boot/2011-August/098795.html
Quoted 9 lines
Quoted 3 lines
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
Aneesh, Dirk,
Le 19/08/2011 20:19, Dirk Behme a ?crit :
Quoted 10 lines · Aneesh V
Quoted 9 lines
Hi Albert,
Quoted 6 lines · 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:
Quoted 16 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 9 lines
Quoted 3 lines
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.
Quoted 8 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
Many thanks and best regards
Dirk
Amicalement,
Signature · 1 line
Albert.
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
Quoted 1 line
Quoted 1 line
Quoted 1 line
This one lowers bad board builds from 69 to 62, and has been applied.
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.
Quoted 1 line
Quoted 1 line
This one lowers bad board builds from 62 to 58, and has been applied.
Amicalement,
Signature · 1 line
Albert.
Quoted 10 lines · Albert ARIBAUD
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
Quoted 1 line
Quoted 1 line
Quoted 1 line
This one lowers bad board builds from 69 to 62, and has been applied.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 7 lines
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
Hi Dirk,
Le 21/08/2011 09:11, Dirk Behme a ?crit :
Quoted 5 lines
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.
Quoted 3 lines
Best regards
Dirk
Amicalement,
Signature · 1 line
Albert.
V
Hi Albert,
Quoted 4 lines · Albert ARIBAUD
Hi Dirk,
Le 21/08/2011 09:11, Dirk Behme a ?crit :
Quoted 8 lines
Quoted 5 lines
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
Quoted 3 lines · Albert ARIBAUD
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
...
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
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]
Quoted 1 line
cat
include/configs/omap4_sdp4430.h| grepCONFIG_SPL_MAX_SIZE
#define CONFIG_SPL_MAX_SIZE (38 * 1024)
Quoted 1 line
./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
----------------------------------------------------------
Quoted 1 line
cat
include/configs/omap4_panda.h| grepCONFIG_SPL_MAX_SIZE
#define CONFIG_SPL_MAX_SIZE (38 * 1024)
Quoted 1 line
./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)
V
Hi Dirk,
Quoted 20 lines · Dirk Behme
Quoted 3 lines · Albert ARIBAUD
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
...
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.cwarning you report above. That would mean it would be worth to apply 108865 to fix at least the linking issue.
Quoted 5 lines
Second, applying 108865 to the recent u-boot-arm.git doesn't show any
clocks.cwarning 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
V
Hi Albert,
Quoted 8 lines · Albert ARIBAUD
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
Quoted 1 line
Quoted 1 line
Quoted 1 line
This one lowers bad board builds from 69 to 62, and has been applied.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
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
Hi Aneesh,
Le 21/08/2011 09:51, V, Aneesh a ?crit :
Quoted 17 lines
Hi Albert,
Quoted 13 lines · Albert ARIBAUD
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
Quoted 1 line
Quoted 1 line
Quoted 1 line
This one lowers bad board builds from 69 to 62, and has been applied.
Quoted 1 line
Quoted 1 line
Quoted 1 line
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:
Quoted 8 lines
Quoted 2 lines
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:
This indeed fixes it. Strange that the warning is not emitted by your toolchain.
Quoted 2 lines
best regards,
Aneesh
Amicalement,
Signature · 1 line
Albert.
V
Hi Albert,
Quoted 31 lines · Albert ARIBAUD
Hi Aneesh,
Le 21/08/2011 09:51, V, Aneesh a ?crit :
Quoted 28 lines
Hi Albert,
Quoted 9 lines · On Sat, Aug 20, 2011 at 9:02 PM, Albert ARIBAUD <[email protected]>…
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a ?crit :
Quoted 1 line
Quoted 1 line
Quoted 1 line
This one lowers bad board builds from 69 to 62, and has been applied.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
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:
Quoted 4 lines
Quoted 1 line
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
Hi Aneesh,
Le 21/08/2011 10:56, V, Aneesh a ?crit :
Quoted 6 lines
Quoted 2 lines
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.
Quoted 2 lines
br,
Aneesh
Amicalement,
Signature · 1 line
Albert.
Hi Albert,
Quoted 4 lines · Albert ARIBAUD
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
Hi Albert,
Quoted 6 lines · Simon Schwarz
Hi Albert,
Quoted 2 lines · Albert ARIBAUD
snip>
Quoted 8 lines
Quoted 2 lines
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/
Quoted 3 lines
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
Quoted 13 lines · 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).
Quoted 5 lines
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
Hi Marek,
Le 20/08/2011 13:16, Marek Vasut a ?crit :
Quoted 18 lines · Albert ARIBAUD
Quoted 17 lines
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 1 line
Cheers
Amicalement,
Signature · 1 line
Albert.
Quoted 27 lines · Albert ARIBAUD
Hi Marek,
Le 20/08/2011 13:16, Marek Vasut a ?crit :
Quoted 18 lines · Albert ARIBAUD
Quoted 17 lines
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.
Quoted 5 lines
Quoted 1 line
Amicalement,
Hi Albert,
where can I find the board removal patchset?
Quoted 8 lines
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.Quoted 1 line
Cheers
Amicalement,
Let me send you a few fixes for xscale crap. Do you prefer pull request or just a bunch of emails ?
Cheers
Hi Marek,
Le 20/08/2011 14:24, Marek Vasut a ?crit :
Quoted 33 lines · Albert ARIBAUD
Quoted 32 lines
Hi Marek,
Le 20/08/2011 13:16, Marek Vasut a ?crit :
Quoted 18 lines · Albert ARIBAUD
Quoted 17 lines
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 1 line
Cheers
Amicalement,
Signature · 1 line
Albert.
Quoted 40 lines · Albert ARIBAUD
Hi Marek,
Le 20/08/2011 14:24, Marek Vasut a ?crit :
Quoted 37 lines · Albert ARIBAUD
Quoted 35 lines
Hi Marek,
Le 20/08/2011 13:16, Marek Vasut a ?crit :
Quoted 18 lines · Albert ARIBAUD
Quoted 17 lines
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.
Quoted 5 lines
Quoted 1 line
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.Quoted 1 line
Cheers
Amicalement,
Quoted 8 lines
Quoted 2 lines
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
Quoted 4 lines
Quoted 2 lines
Cheers
Amicalement,
[U-Boot] [STATUS] ARM (Tegra)
In reply to Albert ARIBAUDQuoted 2 lines · 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)
Quoted 9 lines · On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
Quoted 2 lines · 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
Quoted 4 lines
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)
Le 30/08/2011 17:20, Mike Frysinger a ?crit :
Quoted 15 lines · On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
Quoted 9 lines · On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
Quoted 2 lines
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
Quoted 4 lines
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 :).
Quoted 4 lines
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/>
Quoted 1 line
-mike
Amicalement,
Signature · 1 line
Albert.
[U-Boot] [STATUS] ARM (Tegra)
Quoted 32 lines · Albert ARIBAUD
Le 30/08/2011 17:20, Mike Frysinger a ?crit :
Quoted 21 lines · On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
Quoted 12 lines · On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
Quoted 3 lines
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
Tegra2Quoted 6 lines
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 :).Quoted 5 lines
ping ...
if people dont care either way, we can just set up a u-boot/u-boot-tegra.git
tree for Albert to pull fromSeems 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.
Quoted 6 lines
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
Quoted 7 lines
Quoted 2 lines
-mike
Amicalement,
--
Albert.
[U-Boot] [STATUS] ARM (Tegra)
Hi Albert,
Quoted 34 lines · Simon Glass
Quoted 32 lines · Albert ARIBAUD
Le 30/08/2011 17:20, Mike Frysinger a ?crit :
Quoted 21 lines · On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
Quoted 12 lines · On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
Quoted 3 lines
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
Tegra2Quoted 6 lines
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 :).Quoted 5 lines
ping ...
if people dont care either way, we can just set up a u-boot/u-boot-tegra.git
tree for Albert to pull fromSeems 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.
Quoted 6 lines
Quoted 6 lines
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
Quoted 14 lines
Yes that's right, thanks.
Regards,
SimonQuoted 7 lines
Quoted 2 lines
-mike
Amicalement,
--
Albert.
[U-Boot] [STATUS] ARM (Tegra)
In reply to Simon GlassLe 30/08/2011 17:57, Simon Glass a ?crit :
Quoted 34 lines
Quoted 32 lines · Albert ARIBAUD
Le 30/08/2011 17:20, Mike Frysinger a ?crit :
Quoted 21 lines · On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
Quoted 12 lines · On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
Quoted 3 lines
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
Tegra2Quoted 6 lines
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 :).Quoted 5 lines
ping ...
if people dont care either way, we can just set up a u-boot/u-boot-tegra.git
tree for Albert to pull fromSeems 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.
Quoted 8 lines
Quoted 6 lines
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) ?
Quoted 2 lines
Regards,
Simon
Amicalement,
Signature · 1 line
Albert.
[U-Boot] [STATUS] ARM (Tegra)
Quoted 47 lines · Albert ARIBAUD
Le 30/08/2011 17:57, Simon Glass a ?crit :
Quoted 46 lines
Quoted 42 lines · On Tue, Aug 30, 2011 at 8:34 AM, Albert ARIBAUD <[email protected]>…
Le 30/08/2011 17:20, Mike Frysinger a ?crit :
Quoted 22 lines · On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
Quoted 12 lines · On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
Quoted 3 lines
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
Tegra2Quoted 7 lines
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 :).Quoted 5 lines
ping ...
if people dont care either way, we can just set up a u-boot/u-boot-tegra.git
tree for Albert to pull fromSeems 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/>
Quoted 6 lines
Quoted 1 line
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
Quoted 4 lines
Amicalement,
--
Albert.
[U-Boot] [STATUS] ARM (Tegra)
Le 30/08/2011 18:36, Simon Glass a ?crit :
Quoted 3 lines
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,
Signature · 1 line
Albert.
[U-Boot] [STATUS] ARM (Tegra)
Quoted 10 lines · Albert ARIBAUD
Le 30/08/2011 18:36, Simon Glass a ?crit :
Quoted 3 lines
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
Quoted 5 lines
Amicalement,
--
Albert.
Quoted 6 lines · 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:
Quoted 6 lines
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:
Quoted 1 line
./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
In reply to Albert ARIBAUDHi 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,
Signature · 1 line
Albert.
[U-Boot] [STATUS] ARM status as of 2011-08-30
Dear Albert ARIBAUD,
Quoted 6 lines · In message <[email protected]> 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.
Quoted 1 line
- 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
Quoted 1 line
(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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 1 line
If that is ok, I'll send out a pull request today.
Thanks a lot!
Best regards,
Wolfgang Denk
Signature · 8 lines
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
Le 30/08/2011 21:08, Wolfgang Denk a ?crit :
Quoted 6 lines
Dear Albert ARIBAUD,
Quoted 3 lines · In message<[email protected]> you wrote:
I have just applied Wolfgang's updated ARM board removal patch set.
Quoted 7 lines
Quoted 3 lines
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).
Quoted 1 line
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.
Quoted 8 lines
Quoted 1 line
- 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
Quoted 1 line
(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. :)
Quoted 6 lines
Quoted 4 lines
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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 1 line
If that is ok, I'll send out a pull request today.
Thanks a lot!
Done, with a few hour's delay.
Quoted 3 lines
Best regards,
Wolfgang Denk
Amicalement,
Signature · 1 line
Albert.
[U-Boot] [STATUS] ARM status as of 2011-08-30
Dear Albert ARIBAUD,
Quoted 7 lines · In message <[email protected]> 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.
Quoted 1 line
Done, with a few hour's delay.
At the moment I'm on hold, as you asked for.
Best regards,
Wolfgang Denk
Signature · 4 lines
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