Patchwork [U-Boot] omap3: beagle: Fix build warning

login
register
mail settings
Submitter Sanjeev Premi
Date Sept. 5, 2011, 10:25 a.m.
Message ID <1315218353-18173-1-git-send-email-premi@ti.com>
Download mbox | patch
Permalink /patch/113336/
State Accepted
Commit 8c4e0ca69e09e05c2857f49b233df7ac38451fef
Headers show

Comments

Sanjeev Premi - Sept. 5, 2011, 10:25 a.m.
This patch fixes the warning dure to recent changes to the board
configuration:
cmd_i2c.o cmd_i2c.c -c
cmd_i2c.c:109:1: warning: missing braces around initializer
cmd_i2c.c:109:1: warning: (near initialization for 'i2c_no_probes[0]')

Signed-off-by: Sanjeev Premi <premi@ti.com>
Cc: Jason Kridner <jkridner@beagleboard.org>
---

 Patch was compile tested against the latest u-boot-arm.git at:
 58c583b : net: Check network device driver name
 
 include/configs/omap3_beagle.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Albert ARIBAUD - Sept. 5, 2011, 11:35 a.m.
Hi Sanjeev,

Le 05/09/2011 12:25, Sanjeev Premi a écrit :
> This patch fixes the warning dure to recent changes to the board
> configuration:
> cmd_i2c.o cmd_i2c.c -c
> cmd_i2c.c:109:1: warning: missing braces around initializer
> cmd_i2c.c:109:1: warning: (near initialization for 'i2c_no_probes[0]')
>
> Signed-off-by: Sanjeev Premi<premi@ti.com>
> Cc: Jason Kridner<jkridner@beagleboard.org>
> ---
>
>   Patch was compile tested against the latest u-boot-arm.git at:
>   58c583b : net: Check network device driver name
>
>   include/configs/omap3_beagle.h |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> index 18c6deb..a891246 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -118,7 +118,7 @@
>   #define CONFIG_I2C_MULTI_BUS		1
>
>   /* Probe all devices */
> -#define CONFIG_SYS_I2C_NOPROBES		{0x0, 0x0}
> +#define CONFIG_SYS_I2C_NOPROBES		{{0x0, 0x0}}
>
>   /* USB */
>   #define CONFIG_MUSB_UDC			1

Won't all board configs which use CONFIG_SYS_I2C_NOPROBES suffer from 
the same bug? I would hate to see an endless trickle of individual board 
config patches, and would much prefer a single patch to fix all boards 
in one go if you are willing to do it -- yes, it would touch boards that 
you cannot even test, but I'd say the risk is next to zero.

Wolfgang, Heiko, your opinion?

Amicalement,
Sanjeev Premi - Sept. 5, 2011, 11:47 a.m.
> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.u.boot@aribaud.net] 
> Sent: Monday, September 05, 2011 5:06 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de; Heiko Schocher; Wolfgang Denk
> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
> 
> Hi Sanjeev,
> 
> Le 05/09/2011 12:25, Sanjeev Premi a écrit :
> > This patch fixes the warning dure to recent changes to the board
> > configuration:
> > cmd_i2c.o cmd_i2c.c -c
> > cmd_i2c.c:109:1: warning: missing braces around initializer
> > cmd_i2c.c:109:1: warning: (near initialization for 
> 'i2c_no_probes[0]')
> >
> > Signed-off-by: Sanjeev Premi<premi@ti.com>
> > Cc: Jason Kridner<jkridner@beagleboard.org>
> > ---
> >
> >   Patch was compile tested against the latest u-boot-arm.git at:
> >   58c583b : net: Check network device driver name
> >
> >   include/configs/omap3_beagle.h |    2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/configs/omap3_beagle.h 
> b/include/configs/omap3_beagle.h
> > index 18c6deb..a891246 100644
> > --- a/include/configs/omap3_beagle.h
> > +++ b/include/configs/omap3_beagle.h
> > @@ -118,7 +118,7 @@
> >   #define CONFIG_I2C_MULTI_BUS		1
> >
> >   /* Probe all devices */
> > -#define CONFIG_SYS_I2C_NOPROBES		{0x0, 0x0}
> > +#define CONFIG_SYS_I2C_NOPROBES		{{0x0, 0x0}}
> >
> >   /* USB */
> >   #define CONFIG_MUSB_UDC			1
> 
> Won't all board configs which use CONFIG_SYS_I2C_NOPROBES suffer from 
> the same bug? I would hate to see an endless trickle of 
> individual board 
> config patches, and would much prefer a single patch to fix 
> all boards 

[sp] Actually, not all boards suffer from this issue.
     But yes, I can make a single patch and submit it
     in next couple of hours.

> in one go if you are willing to do it -- yes, it would touch 
> boards that 
> you cannot even test, but I'd say the risk is next to zero.
> 
> Wolfgang, Heiko, your opinion?
> 
> Amicalement,
> -- 
> Albert.
>
Heiko Schocher - Sept. 5, 2011, 1:30 p.m.
Hello Sanjeev,

Premi, Sanjeev wrote:
>> -----Original Message-----
>> From: Albert ARIBAUD [mailto:albert.u.boot@aribaud.net] 
>> Sent: Monday, September 05, 2011 5:06 PM
>> To: Premi, Sanjeev
>> Cc: u-boot@lists.denx.de; Heiko Schocher; Wolfgang Denk
>> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
>>
>> Hi Sanjeev,
>>
>> Le 05/09/2011 12:25, Sanjeev Premi a écrit :
>>> This patch fixes the warning dure to recent changes to the board
>>> configuration:
>>> cmd_i2c.o cmd_i2c.c -c
>>> cmd_i2c.c:109:1: warning: missing braces around initializer
>>> cmd_i2c.c:109:1: warning: (near initialization for 
>> 'i2c_no_probes[0]')
>>> Signed-off-by: Sanjeev Premi<premi@ti.com>
>>> Cc: Jason Kridner<jkridner@beagleboard.org>
>>> ---
>>>
>>>   Patch was compile tested against the latest u-boot-arm.git at:
>>>   58c583b : net: Check network device driver name
>>>
>>>   include/configs/omap3_beagle.h |    2 +-
>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/include/configs/omap3_beagle.h 
>> b/include/configs/omap3_beagle.h
>>> index 18c6deb..a891246 100644
>>> --- a/include/configs/omap3_beagle.h
>>> +++ b/include/configs/omap3_beagle.h
>>> @@ -118,7 +118,7 @@
>>>   #define CONFIG_I2C_MULTI_BUS		1
>>>
>>>   /* Probe all devices */
>>> -#define CONFIG_SYS_I2C_NOPROBES		{0x0, 0x0}
>>> +#define CONFIG_SYS_I2C_NOPROBES		{{0x0, 0x0}}
>>>
>>>   /* USB */
>>>   #define CONFIG_MUSB_UDC			1
>> Won't all board configs which use CONFIG_SYS_I2C_NOPROBES suffer from 
>> the same bug? I would hate to see an endless trickle of 
>> individual board 
>> config patches, and would much prefer a single patch to fix 
>> all boards 
> 
> [sp] Actually, not all boards suffer from this issue.
>      But yes, I can make a single patch and submit it
>      in next couple of hours.

Isn;t this issue introduced just from commit

author	Jason Kridner <jkridner@beagleboard.org>
 Sat, 23 Jul 2011 04:42:44 +0000 (23:42 -0500)
committer	Albert ARIBAUD <albert.u.boot@aribaud.net>
 Sun, 4 Sep 2011 09:36:21 +0000 (11:36 +0200)
commit	f74fc4ae6d6257ecdbc0049f6aa2e96212207f05

so ~1day old ... Hmm, I think, this is just a single board bugfix,
as this warning only raises, if CONFIG_I2C_MULTI_BUS and
CONFIG_SYS_I2C_NOPROBES is defined ... as introduced for the beagle
board through above commit ... other boards should be clean, as I tend
to do a MAKEALL after applying patches from ML ... but if you find
time and can check this, it would be nice!

bye,
Heiko
Sanjeev Premi - Sept. 5, 2011, 2:42 p.m.
> -----Original Message-----
> From: Heiko Schocher [mailto:hs@denx.de] 
> Sent: Monday, September 05, 2011 7:01 PM
> To: Premi, Sanjeev
> Cc: Albert ARIBAUD; u-boot@lists.denx.de; Wolfgang Denk
> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
> 
> Hello Sanjeev,
> 
> Premi, Sanjeev wrote:
> >> -----Original Message-----
> >> From: Albert ARIBAUD [mailto:albert.u.boot@aribaud.net] 
> >> Sent: Monday, September 05, 2011 5:06 PM
> >> To: Premi, Sanjeev
> >> Cc: u-boot@lists.denx.de; Heiko Schocher; Wolfgang Denk
> >> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
> >>
[snip]...[snip]

> >>> --- a/include/configs/omap3_beagle.h
> >>> +++ b/include/configs/omap3_beagle.h
> >>> @@ -118,7 +118,7 @@
> >>>   #define CONFIG_I2C_MULTI_BUS		1
> >>>
> >>>   /* Probe all devices */
> >>> -#define CONFIG_SYS_I2C_NOPROBES		{0x0, 0x0}
> >>> +#define CONFIG_SYS_I2C_NOPROBES		{{0x0, 0x0}}
> >>>
> >>>   /* USB */
> >>>   #define CONFIG_MUSB_UDC			1
> >> Won't all board configs which use CONFIG_SYS_I2C_NOPROBES 
> suffer from 
> >> the same bug? I would hate to see an endless trickle of 
> >> individual board 
> >> config patches, and would much prefer a single patch to fix 
> >> all boards 
> > 
> > [sp] Actually, not all boards suffer from this issue.
> >      But yes, I can make a single patch and submit it
> >      in next couple of hours.
> 
> Isn;t this issue introduced just from commit
> 
> author	Jason Kridner <jkridner@beagleboard.org>
>  Sat, 23 Jul 2011 04:42:44 +0000 (23:42 -0500)
> committer	Albert ARIBAUD <albert.u.boot@aribaud.net>
>  Sun, 4 Sep 2011 09:36:21 +0000 (11:36 +0200)
> commit	f74fc4ae6d6257ecdbc0049f6aa2e96212207f05
> 
> so ~1day old ... Hmm, I think, this is just a single board bugfix,
> as this warning only raises, if CONFIG_I2C_MULTI_BUS and
> CONFIG_SYS_I2C_NOPROBES is defined ... as introduced for the beagle
> board through above commit ... other boards should be clean, as I tend
> to do a MAKEALL after applying patches from ML ... but if you find

[sp] Yes, you are right about the issue, and hence I posted it as
     single patch against beagleboard only.  The description includes
     a bash script that I used to "blindly" extent the fix to other
     boards.

     I guess, MAKEALL succeeds because the appropriate config options
     may not be enabled for the boards.

     Will dig on a few cases (of the ones changed) as to why the build
     succeeds.

> time and can check this, it would be nice!

[sp] I only have a arm codesourcery toolchain installed. Would be able
     to check only ARM boards (of the 31) impacted by the updated patch.

     Can do by tomorrow...

> 
> bye,
> Heiko
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>
Jason Kridner - Sept. 6, 2011, 10 p.m.
On Mon, Sep 5, 2011 at 6:25 AM, Sanjeev Premi <premi@ti.com> wrote:
> This patch fixes the warning dure to recent changes to the board
> configuration:
> cmd_i2c.o cmd_i2c.c -c
> cmd_i2c.c:109:1: warning: missing braces around initializer
> cmd_i2c.c:109:1: warning: (near initialization for 'i2c_no_probes[0]')
>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> Cc: Jason Kridner <jkridner@beagleboard.org>

Acked-by: Jason Kridner <jdk@ti.com>

I confirmed that this fixes the above warning and builds and operates
properly.  As far as other platforms needing this type of patch, it
seems there is a challenge in speaking for all of them, so I hope this
patch can be applied.

> ---
>
>  Patch was compile tested against the latest u-boot-arm.git at:
>  58c583b : net: Check network device driver name
>
>  include/configs/omap3_beagle.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> index 18c6deb..a891246 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -118,7 +118,7 @@
>  #define CONFIG_I2C_MULTI_BUS           1
>
>  /* Probe all devices */
> -#define CONFIG_SYS_I2C_NOPROBES                {0x0, 0x0}
> +#define CONFIG_SYS_I2C_NOPROBES                {{0x0, 0x0}}
>
>  /* USB */
>  #define CONFIG_MUSB_UDC                        1
> --
> 1.7.2.2
>
>
Albert ARIBAUD - Sept. 7, 2011, 6:11 a.m.
(Cc:ing Dirk for the non-patch-related error)

Hi Sanjeev,

Le 05/09/2011 12:25, Sanjeev Premi a écrit :

> This patch fixes the warning dure to recent changes to the board
> configuration:
> cmd_i2c.o cmd_i2c.c -c
> cmd_i2c.c:109:1: warning: missing braces around initializer
> cmd_i2c.c:109:1: warning: (near initialization for 'i2c_no_probes[0]')
>
> Signed-off-by: Sanjeev Premi<premi@ti.com>
> Cc: Jason Kridner<jkridner@beagleboard.org>
> ---

Applied to u-boot-arm/master as it does fix the warning.

Note however that there is an error, independent from this patch, in 
building this board with ELDK42 and CS 2011q1 :

Configuring for omap3_beagle board...
beagle.c:532: warning: initialization from incompatible pointer type
led.c: In function '__led_toggle':
led.c:62: warning: implicit declaration of function 'omap_get_gpio_dataout'
board/ti/beagle/libbeagle.o: In function `__led_toggle':
/home/uboot/src/u-boot-arm/board/ti/beagle/led.c:62: undefined reference 
to `omap_get_gpio_dataout'
arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail 
/opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/binutils-2.17.90/bfd/elf32-arm.c:8886
arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail 
/opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/binutils-2.17.90/bfd/elf32-arm.c:9117

(foillows a linker segmentation error)

Anyone can reproduce and tell what the issue is?

Amicalement,
Stefano Babic - Sept. 7, 2011, 7:41 a.m.
On 09/07/2011 08:11 AM, Albert ARIBAUD wrote:
> (Cc:ing Dirk for the non-patch-related error)
> 

Hi Albert,

> Note however that there is an error, independent from this patch, in 
> building this board with ELDK42 and CS 2011q1 :
> 
> Configuring for omap3_beagle board...
> beagle.c:532: warning: initialization from incompatible pointer type
> led.c: In function '__led_toggle':
> led.c:62: warning: implicit declaration of function 'omap_get_gpio_dataout'
> board/ti/beagle/libbeagle.o: In function `__led_toggle':
> /home/uboot/src/u-boot-arm/board/ti/beagle/led.c:62: undefined reference 
> to `omap_get_gpio_dataout'
> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail 
> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/binutils-2.17.90/bfd/elf32-arm.c:8886
> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail 
> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/binutils-2.17.90/bfd/elf32-arm.c:9117
> 
> (foillows a linker segmentation error)
> 
> Anyone can reproduce and tell what the issue is?

I can reproduce it. IMHO this issue is introduced with the following commit:

commit b8bc8973a1830bb92e7a9bf3356dc209afb2f4e8
Author: Joel A Fernandes <agnel.joel@gmail.com>
Date:   Thu Aug 11 23:16:53 2011 -0500

There is no omap_get_gpio_dataout() actually in u-boot, but it is called
to get the value of the LED:
	state = omap_get_gpio_dataout(toggle_gpio);

Even if we had this function, it sounds odd to read the status of a LED
(or generally from a GPIO set to output), because we should already know
which value we have written before. Instead of reading from hardware
should we not save the state of the LED in a variable ?

Best regards,
Stefano Babic
Sanjeev Premi - Sept. 7, 2011, 8:47 a.m.
> -----Original Message-----
> From: Stefano Babic [mailto:sbabic@denx.de] 
> Sent: Wednesday, September 07, 2011 1:11 PM
> To: Albert ARIBAUD
> Cc: Premi, Sanjeev; u-boot@lists.denx.de; Dirk Behme; 
> agnel.joel@gmail.com
> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
> 
> On 09/07/2011 08:11 AM, Albert ARIBAUD wrote:
> > (Cc:ing Dirk for the non-patch-related error)
> > 
> 
> Hi Albert,
> 
> > Note however that there is an error, independent from this 
> patch, in 
> > building this board with ELDK42 and CS 2011q1 :
> > 
> > Configuring for omap3_beagle board...
> > beagle.c:532: warning: initialization from incompatible pointer type
> > led.c: In function '__led_toggle':
> > led.c:62: warning: implicit declaration of function 
> 'omap_get_gpio_dataout'
> > board/ti/beagle/libbeagle.o: In function `__led_toggle':
> > /home/uboot/src/u-boot-arm/board/ti/beagle/led.c:62: 
> undefined reference 
> > to `omap_get_gpio_dataout'
> > arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail 
> > 
> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
eabi/binutils-2.17.90/bfd/elf32-arm.c:8886
> > arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail 
> > 
> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
eabi/binutils-2.17.90/bfd/elf32-arm.c:9117
> > 
> > (foillows a linker segmentation error)
> > 
> > Anyone can reproduce and tell what the issue is?
> 
> I can reproduce it. IMHO this issue is introduced with the 
> following commit:
> 
> commit b8bc8973a1830bb92e7a9bf3356dc209afb2f4e8
> Author: Joel A Fernandes <agnel.joel@gmail.com>
> Date:   Thu Aug 11 23:16:53 2011 -0500
> 
> There is no omap_get_gpio_dataout() actually in u-boot, but 
> it is called
> to get the value of the LED:
> 	state = omap_get_gpio_dataout(toggle_gpio);

[sp] I reported the missing function few days ago:
     http://marc.info/?l=u-boot&m=131522045310324&w=2

~sanjeev

> 
> Even if we had this function, it sounds odd to read the 
> status of a LED
> (or generally from a GPIO set to output), because we should 
> already know
> which value we have written before. Instead of reading from hardware
> should we not save the state of the LED in a variable ?
> 
> Best regards,
> Stefano Babic
> 
> -- 
> =====================================================================
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
> =====================================================================
>
Albert ARIBAUD - Sept. 7, 2011, 1:04 p.m.
cc:ing Sandeep as the commit apparently comes from the TI tree.

Le 07/09/2011 10:47, Premi, Sanjeev a écrit :
>> -----Original Message-----
>> From: Stefano Babic [mailto:sbabic@denx.de]
>> Sent: Wednesday, September 07, 2011 1:11 PM
>> To: Albert ARIBAUD
>> Cc: Premi, Sanjeev; u-boot@lists.denx.de; Dirk Behme;
>> agnel.joel@gmail.com
>> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
>>
>> On 09/07/2011 08:11 AM, Albert ARIBAUD wrote:
>>> (Cc:ing Dirk for the non-patch-related error)
>>>
>>
>> Hi Albert,
>>
>>> Note however that there is an error, independent from this
>> patch, in
>>> building this board with ELDK42 and CS 2011q1 :
>>>
>>> Configuring for omap3_beagle board...
>>> beagle.c:532: warning: initialization from incompatible pointer type
>>> led.c: In function '__led_toggle':
>>> led.c:62: warning: implicit declaration of function
>> 'omap_get_gpio_dataout'
>>> board/ti/beagle/libbeagle.o: In function `__led_toggle':
>>> /home/uboot/src/u-boot-arm/board/ti/beagle/led.c:62:
>> undefined reference
>>> to `omap_get_gpio_dataout'
>>> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail
>>>
>> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
>> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
> eabi/binutils-2.17.90/bfd/elf32-arm.c:8886
>>> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail
>>>
>> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
>> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
> eabi/binutils-2.17.90/bfd/elf32-arm.c:9117
>>>
>>> (foillows a linker segmentation error)
>>>
>>> Anyone can reproduce and tell what the issue is?
>>
>> I can reproduce it. IMHO this issue is introduced with the
>> following commit:
>>
>> commit b8bc8973a1830bb92e7a9bf3356dc209afb2f4e8
>> Author: Joel A Fernandes<agnel.joel@gmail.com>
>> Date:   Thu Aug 11 23:16:53 2011 -0500
>>
>> There is no omap_get_gpio_dataout() actually in u-boot, but
>> it is called
>> to get the value of the LED:
>> 	state = omap_get_gpio_dataout(toggle_gpio);
>
> [sp] I reported the missing function few days ago:
>       http://marc.info/?l=u-boot&m=131522045310324&w=2
>
> ~sanjeev

Apologies for not noticing.

>> Even if we had this function, it sounds odd to read the
>> status of a LED
>> (or generally from a GPIO set to output), because we should
>> already know
>> which value we have written before. Instead of reading from hardware
>> should we not save the state of the LED in a variable ?

Actually, this is not that weird. All GPIOs I have dealt with can 
provide the value of their output, and I don't see what added value 
there is in storing their value in a RAM variable also.

What worries me, though, is that this commit is obviously dependent on 
other code changes that we don't have. Joel, can you help?

>> Best regards,
>> Stefano Babic

Amicalement,
Sandeep Paulraj - Sept. 7, 2011, 2:12 p.m.
> Le 07/09/2011 10:47, Premi, Sanjeev a écrit :
> >> -----Original Message-----
> >> From: Stefano Babic [mailto:sbabic@denx.de]
> >> Sent: Wednesday, September 07, 2011 1:11 PM
> >> To: Albert ARIBAUD
> >> Cc: Premi, Sanjeev; u-boot@lists.denx.de; Dirk Behme;
> >> agnel.joel@gmail.com
> >> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
> >>
> >> On 09/07/2011 08:11 AM, Albert ARIBAUD wrote:
> >>> (Cc:ing Dirk for the non-patch-related error)
> >>>
> >>
> >> Hi Albert,
> >>
> >>> Note however that there is an error, independent from this
> >> patch, in
> >>> building this board with ELDK42 and CS 2011q1 :
> >>>
> >>> Configuring for omap3_beagle board...
> >>> beagle.c:532: warning: initialization from incompatible pointer type
> >>> led.c: In function '__led_toggle':
> >>> led.c:62: warning: implicit declaration of function
> >> 'omap_get_gpio_dataout'
> >>> board/ti/beagle/libbeagle.o: In function `__led_toggle':
> >>> /home/uboot/src/u-boot-arm/board/ti/beagle/led.c:62:
> >> undefined reference
> >>> to `omap_get_gpio_dataout'
> >>> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail
> >>>
> >> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
> >> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
> > eabi/binutils-2.17.90/bfd/elf32-arm.c:8886
> >>> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail
> >>>
> >> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
> >> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
> > eabi/binutils-2.17.90/bfd/elf32-arm.c:9117
> >>>
> >>> (foillows a linker segmentation error)
> >>>
> >>> Anyone can reproduce and tell what the issue is?
> >>
> >> I can reproduce it. IMHO this issue is introduced with the
> >> following commit:
> >>
> >> commit b8bc8973a1830bb92e7a9bf3356dc209afb2f4e8
> >> Author: Joel A Fernandes<agnel.joel@gmail.com>
> >> Date:   Thu Aug 11 23:16:53 2011 -0500
> >>
> >> There is no omap_get_gpio_dataout() actually in u-boot, but
> >> it is called
> >> to get the value of the LED:
> >> 	state = omap_get_gpio_dataout(toggle_gpio);
> >
> > [sp] I reported the missing function few days ago:
> >       http://marc.info/?l=u-boot&m=131522045310324&w=2
> >
> > ~sanjeev
> 
> Apologies for not noticing.
> 
> >> Even if we had this function, it sounds odd to read the
> >> status of a LED
> >> (or generally from a GPIO set to output), because we should
> >> already know
> >> which value we have written before. Instead of reading from hardware
> >> should we not save the state of the LED in a variable ?
> 
> Actually, this is not that weird. All GPIOs I have dealt with can
> provide the value of their output, and I don't see what added value
> there is in storing their value in a RAM variable also.
> 
> What worries me, though, is that this commit is obviously dependent on
> other code changes that we don't have. Joel, can you help?

Albert,


The patch is in the TI tree.

We were having some issues w.r.t the GPIO.

Patches for this have been sent to the list. I was waiting for some testing to see whether the GPIO patches actually work.

Some issues seem to be present after rebasing with mainline but they don't seem to be GPIO related.

I'll send a pull request soon.

Regards,
Sandeep
Joel Fernandes - Sept. 7, 2011, 9:40 p.m.
On Wed, Sep 7, 2011 at 8:04 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> cc:ing Sandeep as the commit apparently comes from the TI tree.
>
> Le 07/09/2011 10:47, Premi, Sanjeev a écrit :
>>>
>>> -----Original Message-----
>>> From: Stefano Babic [mailto:sbabic@denx.de]
>>> Sent: Wednesday, September 07, 2011 1:11 PM
>>> To: Albert ARIBAUD
>>> Cc: Premi, Sanjeev; u-boot@lists.denx.de; Dirk Behme;
>>> agnel.joel@gmail.com
>>> Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
>>>
>>> On 09/07/2011 08:11 AM, Albert ARIBAUD wrote:
>>>>
>>>> (Cc:ing Dirk for the non-patch-related error)
>>>>
>>>
>>> Hi Albert,
>>>
>>>> Note however that there is an error, independent from this
>>>
>>> patch, in
>>>>
>>>> building this board with ELDK42 and CS 2011q1 :
>>>>
>>>> Configuring for omap3_beagle board...
>>>> beagle.c:532: warning: initialization from incompatible pointer type
>>>> led.c: In function '__led_toggle':
>>>> led.c:62: warning: implicit declaration of function
>>>
>>> 'omap_get_gpio_dataout'
>>>>
>>>> board/ti/beagle/libbeagle.o: In function `__led_toggle':
>>>> /home/uboot/src/u-boot-arm/board/ti/beagle/led.c:62:
>>>
>>> undefined reference
>>>>
>>>> to `omap_get_gpio_dataout'
>>>> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail
>>>>
>>> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
>>> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
>>
>> eabi/binutils-2.17.90/bfd/elf32-arm.c:8886
>>>>
>>>> arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail
>>>>
>>> /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto
>>> ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu
>>
>> eabi/binutils-2.17.90/bfd/elf32-arm.c:9117
>>>>
>>>> (foillows a linker segmentation error)
>>>>
>>>> Anyone can reproduce and tell what the issue is?
>>>
>>> I can reproduce it. IMHO this issue is introduced with the
>>> following commit:
>>>
>>> commit b8bc8973a1830bb92e7a9bf3356dc209afb2f4e8
>>> Author: Joel A Fernandes<agnel.joel@gmail.com>
>>> Date:   Thu Aug 11 23:16:53 2011 -0500
>>>
>>> There is no omap_get_gpio_dataout() actually in u-boot, but
>>> it is called
>>> to get the value of the LED:
>>>        state = omap_get_gpio_dataout(toggle_gpio);
>>
>> [sp] I reported the missing function few days ago:
>>      http://marc.info/?l=u-boot&m=131522045310324&w=2
>>
>> ~sanjeev
>
> Apologies for not noticing.
>
>>> Even if we had this function, it sounds odd to read the
>>> status of a LED
>>> (or generally from a GPIO set to output), because we should
>>> already know
>>> which value we have written before. Instead of reading from hardware
>>> should we not save the state of the LED in a variable ?
>
> Actually, this is not that weird. All GPIOs I have dealt with can provide
> the value of their output, and I don't see what added value there is in
> storing their value in a RAM variable also.

True, this was discussed here hence the patch:
http://lists.denx.de/pipermail/u-boot/2011-May/093068.html

>
> What worries me, though, is that this commit is obviously dependent on other
> code changes that we don't have. Joel, can you help?

I hope from Sandeep's response, it is clarified that the new patch is
not yet in explaining the undefined reference. Let me know if you need
any other help from me. Thanks,
Joel

Patch

diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 18c6deb..a891246 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -118,7 +118,7 @@ 
 #define CONFIG_I2C_MULTI_BUS		1
 
 /* Probe all devices */
-#define CONFIG_SYS_I2C_NOPROBES		{0x0, 0x0}
+#define CONFIG_SYS_I2C_NOPROBES		{{0x0, 0x0}}
 
 /* USB */
 #define CONFIG_MUSB_UDC			1