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

Albert ARIBAUD
2010-10-05T10:33:01Z

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.