[U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long

[Oliver Schinagl]

On 17-10-13 08:27, Albert ARIBAUD wrote:
> Hi Scott,
>
> On Tue, 15 Oct 2013 12:57:33 -0500, Scott Wood
> <scottwood at 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 at 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,
>