[U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 05/10/2010 11:33, Reinhard Meyer a ?crit :
> Dear Heiko Schocher,
>>> start = first entry, end = address AFTER last entry,
>>> so it should be "blt", or?
>>
>> Yep. But I think, ble is right ... we should know, why this
>> entry is filled with 00000000
>
> No, we want a loop through all entries:
>
> start:	1st entry
> 	2nd entry
> 	...
> 	last entry
> end:
>
> so it must be:
>
> for (p = start; p<  end; p += 8)
> 	work;
> and not
>
> for (p = start; p<= end; p += 8)
> 	work;
>
> Reinhard

Indeed, hence my post on 'blo' vs 'ble'. Note that the same erroneous 
'ble' was used throughout start.S, for instance in the source-to-target 
copy loop and in the bss clear loop, which means those two had a latent 
bug since long ago.

It seems like fixing this 'ble' bug and adding Graeme's DISCARDs gives 
us a pretty good candidate for actual patch submission. If no one finds 
a serious blocker, I'll submit a patch set tonight french timezone.

As for splitting the thing into individual patches, I would like some 
advice. Obviously a first patch could be the bugfix to the ble/blo 
issuein existing start.S, and the last patch shall be the change to 
edminiv2.

My problem is with the essential part: changing only the compile and 
link options in arm, or changing only the start.S and u-boot.lds in 
arm926, produces a nonworking, non-buildable, tree. So it would seem 
that all of this should go in a single patch in order to remain bisectable.

However, changing arm without changing other cpus than arm926 would 
break build on these, so a bisectable change would require a single 
patch to arm and all its cpus. Seems a bit big for me.

Wolfgang, Heiko, your advice is sought.

Amicalement,
-- 
Albert.