
On 17-10-13 08:27, Albert ARIBAUD wrote:
Hi Scott,
On Tue, 15 Oct 2013 12:57:33 -0500, Scott Wood scottwood@freescale.com wrote:
On Tue, 2013-10-15 at 09:12 +0200, Albert ARIBAUD wrote:
Hi Oliver,
On Mon, 07 Oct 2013 04:41:31 +0200, Oliver Schinagl oliver+list@schinagl.nl wrote:
Hey all,
Having not received any feed back at all, I went ahead and did the changes anyway. Everything seems to run and work fine for sunxi and prints proper sizes.
For the other boards, I tried to run a MAKEALL but there where so many random other warnings I can't say for 100% certainty there where no mistakes that crept in.
There cannot possibly be a single warning if you're working from an official U-Boot repo, as warnings are considered failures and thus no patch reaches u-boot/master if it causes a warning.
That might be the theory, but in practice this is simply false. Different toolchains produce different warnings, and not all patches always get test-built on every target (especially on obscure architectures). And since it's false that no warnings exist, that means sometimes even when a patch is test-built, some newly introduced warnings get missed (I got an e-mail pointing out such an occurance just today).
You are correct that the same code may or may not emit warnings depending on the toolchain, and that U-Boot's build system won't stop building because of warnings.
However, when a new toolchain version causes such warnings, but they are not 'random' in any case; they may be numerous though, if in some source code used in a lot of boards.
In any case, if Oliver gets warnings, chances are we'll get them to when applying his code, in which case it'll be rejected, or we'll see them happening later if he's unsing a common toolchain in a new version, or he's using an unusual toolchain.
I wasn't getting warnings or errors even remotely related to my patches and while it's a pitty we are discussing peanuts without even looking at the patch, cest la vie.
A few of the warnings are from my toolchain (missing bits) a few others from random stuff, here a few one liners to give an indication where boards break:
mxc_gpio.c:105:9: error: dereferencing pointer to incomplete type
at91rm9200_devices.c:64:20: error: ‘AT91_PIO_PORTA’ undeclared (first use in this function)
mini2440.c:70:24: error: ‘GPH8’ undeclared (first use in this function
/silo/build/sunxi-bsp/u-boot-sunxi/include/config.h:7:0: warning: "CONFIG_SYS_SOC" redefined [enabled by default] /silo/build/sunxi-bsp/build/u-boot-all/include/config.h:9:0: note: this is the location of the previous definition /silo/build/sunxi-bsp/u-boot-sunxi/include/config.h:8:0: warning: "CONFIG_BOARDDIR" redefined [enabled by default] / tons of errors on this one for the atmel at91sam configs
at91sam9260_devices.c:34:20: error: ‘AT91_PIO_PORTB’ undeclared (first use in this function)
da8xx_gpio.c:388:1: error: dereferencing pointer to incomplete type
dm355leopard.c:35:2: error: ‘DAVINCI_GPIO_BINTEN’ undeclared (first use in this function) dm355leopard.c:38:2: error: dereferencing pointer to incomplete type
I must admit however, quite a few boards built cleanly, so I may have overstated things?
I'm building using gcc-4.6.3 on gentoo (with gcc build natively via cross-dev) The command I used was: CROSS_COMPILE=arm-pc-linux-gnueabi- BUILD_DIR=/silo/build/sunxi-bsp/build/u-build-all ./MAKEALL -a arm
So while a few of these errors might be long fixed, we merge the u-boot patches on a monthly or so basis, I can't imagine all these errors being from the wrong toolchain?
So now that that's settled, anything fundamentally wrong with my patch? :)
oliver
-Scott
Amicalement,