From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 07 Sep 2011 15:04:19 +0200 Subject: [U-Boot] [PATCH] omap3: beagle: Fix build warning In-Reply-To: References: <1315218353-18173-1-git-send-email-premi@ti.com> <4E670B27.5000208@aribaud.net> <4E67200F.2080000@denx.de> Message-ID: <4E676BD3.2050202@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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 at denx.de] >> Sent: Wednesday, September 07, 2011 1:11 PM >> To: Albert ARIBAUD >> Cc: Premi, Sanjeev; u-boot at lists.denx.de; Dirk Behme; >> agnel.joel at 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 >> 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, -- Albert.