All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
@ 2009-07-12  8:28 Dirk Behme
  2009-07-12 12:56 ` Jean-Christophe PLAGNIOL-VILLARD
  2009-07-19  7:16 ` Dirk Behme
  0 siblings, 2 replies; 9+ messages in thread
From: Dirk Behme @ 2009-07-12  8:28 UTC (permalink / raw)
  To: u-boot

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=07a6acbe20357ebc2af36ac32e7029828d895a62
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e2a7f3af809f828878fe

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12  8:28 [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND Dirk Behme
@ 2009-07-12 12:56 ` Jean-Christophe PLAGNIOL-VILLARD
  2009-07-12 12:59   ` Dirk Behme
  2009-07-12 14:41   ` Wolfgang Denk
  2009-07-19  7:16 ` Dirk Behme
  1 sibling, 2 replies; 9+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-07-12 12:56 UTC (permalink / raw)
  To: u-boot

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12 12:56 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-07-12 12:59   ` Dirk Behme
  2009-07-12 14:41   ` Wolfgang Denk
  1 sibling, 0 replies; 9+ messages in thread
From: Dirk Behme @ 2009-07-12 12:59 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12 12:56 ` Jean-Christophe PLAGNIOL-VILLARD
  2009-07-12 12:59   ` Dirk Behme
@ 2009-07-12 14:41   ` Wolfgang Denk
  2009-07-12 15:23     ` Jean-Christophe PLAGNIOL-VILLARD
  1 sibling, 1 reply; 9+ messages in thread
From: Wolfgang Denk @ 2009-07-12 14:41 UTC (permalink / raw)
  To: u-boot

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

-- 
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
A morsel of genuine history is a  thing  so  rare  as  to  be  always
valuable.                                          - Thomas Jefferson

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12 14:41   ` Wolfgang Denk
@ 2009-07-12 15:23     ` Jean-Christophe PLAGNIOL-VILLARD
  2009-07-12 18:37       ` Wolfgang Denk
  0 siblings, 1 reply; 9+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-07-12 15:23 UTC (permalink / raw)
  To: u-boot

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12 15:23     ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-07-12 18:37       ` Wolfgang Denk
  2009-07-12 19:34         ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 1 reply; 9+ messages in thread
From: Wolfgang Denk @ 2009-07-12 18:37 UTC (permalink / raw)
  To: u-boot

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

-- 
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
An Ada exception is when a routine gets in trouble and says
'Beam me up, Scotty'.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12 18:37       ` Wolfgang Denk
@ 2009-07-12 19:34         ` Jean-Christophe PLAGNIOL-VILLARD
  2009-07-12 21:17           ` Wolfgang Denk
  0 siblings, 1 reply; 9+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-07-12 19:34 UTC (permalink / raw)
  To: u-boot

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12 19:34         ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-07-12 21:17           ` Wolfgang Denk
  0 siblings, 0 replies; 9+ messages in thread
From: Wolfgang Denk @ 2009-07-12 21:17 UTC (permalink / raw)
  To: u-boot

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

-- 
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
"You can have my Unix system when you  pry  it  from  my  cold,  dead
fingers."                                                - Cal Keegan

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
  2009-07-12  8:28 [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND Dirk Behme
  2009-07-12 12:56 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-07-19  7:16 ` Dirk Behme
  1 sibling, 0 replies; 9+ messages in thread
From: Dirk Behme @ 2009-07-19  7:16 UTC (permalink / raw)
  To: u-boot


This patch is obsolete now with

http://git.denx.de/?p=u-boot.git;a=commit;h=2eb99ca8029b44c988d5f6312f97e68d3b9cb2bd

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=07a6acbe20357ebc2af36ac32e7029828d895a62
> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e2a7f3af809f828878fe
> 
>  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 */
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2009-07-19  7:16 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-12  8:28 [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND Dirk Behme
2009-07-12 12:56 ` Jean-Christophe PLAGNIOL-VILLARD
2009-07-12 12:59   ` Dirk Behme
2009-07-12 14:41   ` Wolfgang Denk
2009-07-12 15:23     ` Jean-Christophe PLAGNIOL-VILLARD
2009-07-12 18:37       ` Wolfgang Denk
2009-07-12 19:34         ` Jean-Christophe PLAGNIOL-VILLARD
2009-07-12 21:17           ` Wolfgang Denk
2009-07-19  7:16 ` Dirk Behme

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.