[U-Boot] Pull request: u-boot-arm/master -- updated

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 05/08/2011 03:08, Reinhard Meyer a ?crit :
> Dear Wolfgang,
>>> Hm... current build results are shattering; building for ARM with good
>>> old ELDK 4.2 gives this:
>>>
>>> --------------------- SUMMARY ----------------------------
>>> Boards compiled: 201
>>> Boards with warnings or errors: 99 ( assabet dnp1110 gcplus lart shannon ap7 ap720t armadillo
>>> B2 ep7312 evb4510 impa7 integratorap lpc2292sodimm modnet50 SMN42 ap920t ap922_XA10
>>> ap926ejs ap946es ap966 cp920t cp922_XA10 cp926ejs cp946es cp966 edb9301 edb9302 edb9302a
>>> edb9307 edb9307a edb9312 edb9315 edb9315a imx27lite jadecpu lpd7a400 magnesium mx1fs2 netstar
>>> sbc2410x scb9328 smdk2400 smdk2410 spear300 spear310 spear320 spear600 VCMA9 versatile
>>> versatileab versatilepb voiceblue integratorcp cp1026 cp1136 omap2420h4 apollon imx31
>>> litekit imx31_phycore imx31_phycore_eet mx31ads mx31pdk mx31pdk_nand qong dig297 igep0020
>>> mx51evk omap3_beagle omap3_overo omap3_evm omap3_zoom2 omap4_panda omap4_sdp4430
>> --
>>> at91cap9adk meesc meesc_dataflash pm9261 pm9263 at91sam9m10g45ek pm9g45 SBC35_A9G20 TNY_A9260 TNY_A9G20
>> --
>>> csb226 lubbock zylonite actux1_4_16 actux1_8_16 actux1_4_32 actux1_8_32 actux2 actux3 actux4
>>> dvlhost ixdp425 ixdpg425 pdnb3 scpu )
>>> ----------------------------------------------------------
>>
>> For the Atmel boards this is correct for the current state of the ARM
>> repo. It concurs with what my 4.5.2 gnu toolchain (running on 32 BIT)
>> says.
>
> That even concurs with what Albert has written after merging the Atmel
> repo:
> "Overall ARM builds (./MAKEALL arm) went from 199 boards built, 119 with
> warnings or errors before applying, to 201 boards, 97 with warnings or
> errors once applied."
> So it is about the same for EDLK (on 64 Bit?)
>
> I just pulled u-boot.git/master. It builds fine for all AT91 boards that
> have been fixed in that repo.
>
> Question is: what goes wrong if ELDK is on 32 Bit?

Since this is an ARM question, I'll look into it, and since Wolfgang 
will be on vacation, I suggest either that we either postpone -rc1, or 
(preferably IMO) that we tag -rc1 now with a specific warning about the 
ARM tree, and I analyze what the issue is using several ARM toolchains, 
both on a 32 and a 64 bits system, with a resolution on -rc2.

I think the resolution should be fast because on a 32-bit system (sorry, 
don't have one any more, will keep a VM somewhere from now on...) the 
failure rate is 100%, thus I should be able to quickly set up a 32-bit 
VM and ELDK 4.2 and pinpoint the issue, say during the week-end.

Amicalement,
-- 
Albert.