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

[Albert ARIBAUD]

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.

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.