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,
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:
- 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
- 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
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:
- 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
- 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.
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 :
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:
- 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
- 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.
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,
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a écrit :
This one lowers bad board builds from 69 to 62, and has been applied.
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.
This one lowers bad board builds from 62 to 58, and has been applied.
Amicalement,
On 20.08.2011 17:32, Albert ARIBAUD wrote:
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a écrit :
This one lowers bad board builds from 69 to 62, and has been applied.
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 :
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,
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
On 20.08.2011 17:32, Albert ARIBAUD wrote:
Hi all,
Le 20/08/2011 13:12, Albert ARIBAUD a écrit :
...
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)
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 :
...
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
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 :
This one lowers bad board builds from 69 to 62, and has been applied.
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 :
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 :
This one lowers bad board builds from 69 to 62, and has been applied.
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:
This indeed fixes it. Strange that the warning is not emitted by your toolchain.
best regards, Aneesh
Amicalement,
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 :
This one lowers bad board builds from 69 to 62, and has been applied.
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:
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 :
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,
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
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
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:
- 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
- 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
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:
- 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
- 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,
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:
- 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
- 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
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:
- 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
- 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,
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:
- 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
- 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,
On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
- 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
On Saturday, August 20, 2011 14:50:27 Mike Frysinger wrote:
On Thursday, August 18, 2011 18:09:56 Albert ARIBAUD wrote:
- 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
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:
- 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,
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:
- 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.
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:
- 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.
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:
- 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,
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:
- 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.
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,
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.
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:
- 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
- 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
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,
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
Le 30/08/2011 21:08, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4E5D088B.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,
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
participants (10)
-
Albert ARIBAUD -
Aneesh V -
Dirk Behme -
Marek Vasut -
Michael Jones -
Mike Frysinger -
Simon Glass -
Simon Schwarz -
V, Aneesh
-
Wolfgang Denk