From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Schinagl Date: Fri, 18 Oct 2013 02:04:09 +0200 Subject: [U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long In-Reply-To: <20131017082748.06618979@lilith> References: <524DDE54.7090709@schinagl.nl> <52521F5B.4090002@schinagl.nl> <20131015091241.48901e5c@lilith> <1381859853.7979.696.camel@snotra.buserror.net> <20131017082748.06618979@lilith> Message-ID: <52607AF9.7050302@schinagl.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 17-10-13 08:27, Albert ARIBAUD wrote: > Hi Scott, > > On Tue, 15 Oct 2013 12:57:33 -0500, Scott Wood > 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 >>> 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, >