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

[Joel A Fernandes]

On Wed, Sep 7, 2011 at 8:04 AM, Albert ARIBAUD
<albert.u.boot at 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 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<agnel.joel at 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