| Message ID | 1315218353-18173-1-git-send-email-premi@ti.com |
|---|---|
| State | Accepted |
| Commit | 8c4e0ca69e09e05c2857f49b233df7ac38451fef |
| Headers | show |
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,
> -----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. >
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
> -----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 >
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 > >
(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,
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
> -----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 > ===================================================================== >
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,
> 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
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
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
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(-)