[U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update MTD infrastructure to support 64bit device size" CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output and to remove annoying warning
warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations.
Signed-off-by: Dirk Behme dirk.behme@googlemail.com
---
This patch is against recent mainline "MAINTAINERS: fix sorting, remove duplicates." 3672cd5c3b53d219d33345eebad4e25ad5bf6d52.
Compile tested with ./MAKEALL ARM_CORTEX_A8 and boot tested on Beagle board.
To be able to compile it independent of tool chain (libgcc) the following patches were applied for this:
http://lists.denx.de/pipermail/u-boot/2009-July/055599.html http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=07a6acbe20357ebc2af36... http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e...
include/configs/omap3_beagle.h | 1 + include/configs/omap3_evm.h | 1 + include/configs/omap3_overo.h | 1 + include/configs/omap3_pandora.h | 1 + include/configs/omap3_zoom1.h | 1 + include/configs/omap3_zoom2.h | 1 + 6 files changed, 6 insertions(+)
Index: omap3_patches/include/configs/omap3_zoom2.h =================================================================== --- omap3_patches.orig/include/configs/omap3_zoom2.h +++ omap3_patches/include/configs/omap3_zoom2.h @@ -150,6 +150,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_zoom1.h =================================================================== --- omap3_patches.orig/include/configs/omap3_zoom1.h +++ omap3_patches/include/configs/omap3_zoom1.h @@ -129,6 +129,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_evm.h =================================================================== --- omap3_patches.orig/include/configs/omap3_evm.h +++ omap3_patches/include/configs/omap3_evm.h @@ -130,6 +130,7 @@ /* * Board NAND Info. */ +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_pandora.h =================================================================== --- omap3_patches.orig/include/configs/omap3_pandora.h +++ omap3_patches/include/configs/omap3_pandora.h @@ -122,6 +122,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_beagle.h =================================================================== --- omap3_patches.orig/include/configs/omap3_beagle.h +++ omap3_patches/include/configs/omap3_beagle.h @@ -133,6 +133,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_overo.h =================================================================== --- omap3_patches.orig/include/configs/omap3_overo.h +++ omap3_patches/include/configs/omap3_overo.h @@ -119,6 +119,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
On 10:28 Sun 12 Jul , Dirk Behme wrote:
With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update MTD infrastructure to support 64bit device size" CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output and to remove annoying warning
warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations.
Signed-off-by: Dirk Behme dirk.behme@googlemail.com
you mush have all board maintainer ack
otherwise fine
Best Regards, J.
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:28 Sun 12 Jul , Dirk Behme wrote:
With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update MTD infrastructure to support 64bit device size" CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output and to remove annoying warning
warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations.
Signed-off-by: Dirk Behme dirk.behme@googlemail.com
you mush have all board maintainer ack
From technical point of view: What do you think what might be wrong with this change that any maintainer would reject it?
Dirk
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090712125617.GA7218@game.jcrosoft.org you wrote:
On 10:28 Sun 12 Jul , Dirk Behme wrote:
With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update MTD infrastructure to support 64bit device size" CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output and to remove annoying warning
warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations.
Signed-off-by: Dirk Behme dirk.behme@googlemail.com
you mush have all board maintainer ack
Please do not put things on their head. This is not how the mailing list works. The good old way in Netiquette is "No News is Good News." When I post a patch, I don't expect that all the subscribers on the list that agree with the patch will send an ACK - I expect that those who see problems with it will raise their voice.
Same here.
If none of the board maintatiners sends a NAK after a reasonable time (3...4 days or so, max 1 week), the we can assume that the patch is OK and should be applied.
Best regards,
Wolfgang Denk
On 16:41 Sun 12 Jul , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090712125617.GA7218@game.jcrosoft.org you wrote:
On 10:28 Sun 12 Jul , Dirk Behme wrote:
With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update MTD infrastructure to support 64bit device size" CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output and to remove annoying warning
warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations.
Signed-off-by: Dirk Behme dirk.behme@googlemail.com
you mush have all board maintainer ack
Please do not put things on their head. This is not how the mailing list works. The good old way in Netiquette is "No News is Good News." When I post a patch, I don't expect that all the subscribers on the list that agree with the patch will send an ACK - I expect that those who see problems with it will raise their voice.
Same here.
If none of the board maintatiners sends a NAK after a reasonable time (3...4 days or so, max 1 week), the we can assume that the patch is OK and should be applied.
you ask us multiple time when we touch a board config we do need the board maintainer ack I've 10's of patch that you have nack because I never receive the board maintainer and they still wait to have board Maintainer ack.
So please give only one rules
Best Regards, J.
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090712152355.GH7218@game.jcrosoft.org you wrote:
If none of the board maintatiners sends a NAK after a reasonable time (3...4 days or so, max 1 week), the we can assume that the patch is OK and should be applied.
you ask us multiple time when we touch a board config we do need the board maintainer ack I've 10's of patch that you have nack because I never receive the board maintainer and they still wait to have board Maintainer ack.
You are right. It's difficult to write don rules that cover all cases - which is one reason why I try to avoid writing down them in the first place.
To me it seems reasonable to ask for maintainer feedback when changes affect a small number of boards - in such a case there is danger, that problems might remain unnoticed if the maintainers are not aware of the patch (which might sail under a subject that does not trigger their awareness), as nobody else is affected.
If a patch affects a large number of boards in exactly the same way, such explicit triggering is less needed - it is very likely that a few of these boards will be tested in any way, so any problems will be noticed even if no extra notification of board maintainers takes place.
To trigger a maintainer it should be sufficient to send him an e-mail (i. e. put him on cc: on the posting). If he does not apply in a reasonable time, we assume his implicit ACK.
Sorry that I cannot provide a strict rule with clear decision criteria; if in doubt, use common sense. Thanks.
Best regards,
Wolfgang Denk
On 20:37 Sun 12 Jul , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090712152355.GH7218@game.jcrosoft.org you wrote:
If none of the board maintatiners sends a NAK after a reasonable time (3...4 days or so, max 1 week), the we can assume that the patch is OK and should be applied.
you ask us multiple time when we touch a board config we do need the board maintainer ack I've 10's of patch that you have nack because I never receive the board maintainer and they still wait to have board Maintainer ack.
You are right. It's difficult to write don rules that cover all cases
- which is one reason why I try to avoid writing down them in the
first place.
To me it seems reasonable to ask for maintainer feedback when changes affect a small number of boards - in such a case there is danger, that problems might remain unnoticed if the maintainers are not aware of the patch (which might sail under a subject that does not trigger their awareness), as nobody else is affected.
If a patch affects a large number of boards in exactly the same way, such explicit triggering is less needed - it is very likely that a few of these boards will be tested in any way, so any problems will be noticed even if no extra notification of board maintainers takes place.
To trigger a maintainer it should be sufficient to send him an e-mail (i. e. put him on cc: on the posting). If he does not apply in a reasonable time, we assume his implicit ACK.
Sorry that I cannot provide a strict rule with clear decision criteria; if in doubt, use common sense. Thanks.
when increase the u-boot size IMHO we do need to have the board maintainer ack because we do not known if it will break or not the board
If it's global or arch specifc we all take care the responsability to this ofcourse we will try to contact the board maintainers and yes not all of them will ack the patch but we will do our best. As example we the errno.h cleanup.
Furehermore here all the boards maintainer are active on the ML so it's make sense to ask them there ack.
But I'd like that we put a rules if the developer that post a patch do his best to have the board maintainer ack but not succed on it. The decission to ack it anyway will come to the Custiodians & you at the end.
Best Regards, J.
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090712193430.GB1686@game.jcrosoft.org you wrote:
when increase the u-boot size IMHO we do need to have the board maintainer ack because we do not known if it will break or not the board
It's not practical to wait for all BM's to ACK such a patch - you could reject it right away as well.
Furehermore here all the boards maintainer are active on the ML so it's make sense to ask them there ack.
Do you really want to see - say - 200 ACK messages here? It's not practical.
But I'd like that we put a rules if the developer that post a patch do his best to have the board maintainer ack but not succed on it. The decission to ack it anyway will come to the Custiodians & you at the end.
If you have a proposal for rules that will actually work in such cases, please feel free to post them here.
Best regards,
Wolfgang Denk
This patch is obsolete now with
http://git.denx.de/?p=u-boot.git;a=commit;h=2eb99ca8029b44c988d5f6312f97e68d...
Thanks
Dirk
Dirk Behme wrote:
With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update MTD infrastructure to support 64bit device size" CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output and to remove annoying warning
warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations.
Signed-off-by: Dirk Behme dirk.behme@googlemail.com
This patch is against recent mainline "MAINTAINERS: fix sorting, remove duplicates." 3672cd5c3b53d219d33345eebad4e25ad5bf6d52.
Compile tested with ./MAKEALL ARM_CORTEX_A8 and boot tested on Beagle board.
To be able to compile it independent of tool chain (libgcc) the following patches were applied for this:
http://lists.denx.de/pipermail/u-boot/2009-July/055599.html http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=07a6acbe20357ebc2af36... http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e...
include/configs/omap3_beagle.h | 1 + include/configs/omap3_evm.h | 1 + include/configs/omap3_overo.h | 1 + include/configs/omap3_pandora.h | 1 + include/configs/omap3_zoom1.h | 1 + include/configs/omap3_zoom2.h | 1 + 6 files changed, 6 insertions(+)
Index: omap3_patches/include/configs/omap3_zoom2.h
--- omap3_patches.orig/include/configs/omap3_zoom2.h +++ omap3_patches/include/configs/omap3_zoom2.h @@ -150,6 +150,7 @@
- Board NAND Info.
*/ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_zoom1.h =================================================================== --- omap3_patches.orig/include/configs/omap3_zoom1.h +++ omap3_patches/include/configs/omap3_zoom1.h @@ -129,6 +129,7 @@
- Board NAND Info.
*/ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_evm.h =================================================================== --- omap3_patches.orig/include/configs/omap3_evm.h +++ omap3_patches/include/configs/omap3_evm.h @@ -130,6 +130,7 @@ /*
- Board NAND Info.
*/ +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_pandora.h =================================================================== --- omap3_patches.orig/include/configs/omap3_pandora.h +++ omap3_patches/include/configs/omap3_pandora.h @@ -122,6 +122,7 @@
- Board NAND Info.
*/ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_beagle.h =================================================================== --- omap3_patches.orig/include/configs/omap3_beagle.h +++ omap3_patches/include/configs/omap3_beagle.h @@ -133,6 +133,7 @@
- Board NAND Info.
*/ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ Index: omap3_patches/include/configs/omap3_overo.h =================================================================== --- omap3_patches.orig/include/configs/omap3_overo.h +++ omap3_patches/include/configs/omap3_overo.h @@ -119,6 +119,7 @@
- Board NAND Info.
*/ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
participants (3)
-
Dirk Behme -
Jean-Christophe PLAGNIOL-VILLARD -
Wolfgang Denk