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