[U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
Albert ARIBAUD
albert.aribaud at free.fr
Tue Oct 5 12:33:01 CEST 2010
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.
More information about the U-Boot
mailing list