[U-Boot] [PATCH] omap3: beagle: Fix build warning
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
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 Premipremi@ti.com Cc: Jason Kridnerjkridner@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 Premipremi@ti.com Cc: Jason Kridnerjkridner@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 Premipremi@ti.com Cc: Jason Kridnerjkridner@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 Premipremi@ti.com Cc: Jason Kridnerjkridner@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 Fernandesagnel.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 Fernandesagnel.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 Fernandesagnel.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
participants (8)
-
Albert ARIBAUD -
Heiko Schocher -
Jason Kridner -
Joel A Fernandes -
Paulraj, Sandeep -
Premi, Sanjeev -
Sanjeev Premi
-
Stefano Babic