On 17-10-13 08:27, Albert ARIBAUD wrote:
Hi Scott,
On Tue, 15 Oct 2013 12:57:33 -0500, Scott Wood
<scottw...@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+l...@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,
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
