Le 05/10/2010 12:40, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<[email protected]> 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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
