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

[Albert ARIBAUD]

Le 05/10/2010 12:40, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4CAAFEDD.4060005 at free.fr>  you wrote:
>>
>> 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.
>
> Correct.
>
>> 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.
>
> Agreed.
>
> Well, let's split development and testing from the final committing.
>
> I suggest you provide what you can in  single patch, and we put this
> in a separate branch of the git repository.  Heiko and me may then add
> support for the precessors we used for testing, i. e. arm1136 and
> armv7.  Hopefully others will pick up from there for the remaining
> processors.
>
> When committing to mainline (or to u-boot-arm) I can sqash all the
> processor related commits into a single one.

Let me recap to make sure I got things right.

Rather than submitting a patch set for mainline, I'll submit a single 
ELF patch that you will put on a specific branch (let's call it 
elf_reloc here for the sake of clarity)

In order to keep elf_reloc devoted to elf relocation and make it simpler 
for you to squash it back to main, elf_reloc should receive only changes 
which are imperative for elf relocation support.

This means the ble bugfix (changing existing ble's into blo's in all ARM 
start.S files) will be a separate patch to main, coming RSN.

Also, I won't submit changes to edminiv2 on elf_reloc either; that'll 
come on main once elf_reloc is squashed back onto it.

> Umm... is my understanding correct that we can drop the whole
> CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?

I believe we're just changing the relocation solution, but we're not 
changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.