Hi Albert, On Tue, Feb 28, 2012 at 1:25 PM, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hi Simon, > > Le 21/02/2012 21:14, Simon Glass a écrit : >> >> Hi Albert, >> >> >> On Tue, Feb 21, 2012 at 11:52 AM, Albert ARIBAUD >> <albert.u.b...@aribaud.net> wrote: >>> >>> Hi Simon, >>> >>> Le 21/02/2012 18:02, Simon Glass a écrit : >>> >>> >>>>>> + . = ALIGN(4); >>>>> >>>>> >>>>> >>>>> >>>>> This "ALIGN(4)" is what upsets my edminiv2 build and makes it not >>>>> binary-identical. It is not in the current arm926ejs liner script. I >>>>> will >>>>> check if adding it to the current arm926ejs script produces a working >>>>> and >>>>> binary-identical u-boot. >>>> >>>> >>>> >>>> OK, but realistically we copy a word at a time (at least) and the >>>> .rel.dyn region is going to be word-aligned I think. All we are doing >>>> here is making sure that the image ends on a word boundary, which >>>> seems reasonable to me. >>>> >>>> In other words, I would like the __image_copy_start and >>>> __image_copy_end symbols to be word-aligned. >>> >>> >>> >>> I understand the requirement and agree to it -- only, it seems to me it >>> is >>> already fulfilled in the current lds files, so I still fail to see what >>> breaks 'near binary identity'. >> >> >> If we add any symbols or change the value of any of them, then the >> binary file may change. You can see the differences by doing something >> like: > > > This statement is true in a very general fashion, but becomes false for many > cases, including the one where the symbol is added at link stage and not > referenced in the build, which is the case for edminiv2. Then the ELF file's > symbol sections may change, but the .text and .data sections have no reason > to.
I agree with that. But do you see this behaviour? I did initially, until I realized that it was just that '-dirty' was be appended to the version string, which was increasing the .rodata size and just changing all the offsets in the text section. Once I committed the change and rebuilt, the problem went away. Please can you confirm what differences you are seeing with things like: armv7a-cros-linux-gnueabi-objdump -h u-boot armv7a-cros-linux-gnueabi-objdump -t u-boot armv7a-cros-linux-gnueabi-objdump -d u-boot ... > > Plus, you did not address my note that the current .lds already aligns the > start and end of copy section to a multiple of 4. I think I missed that comment. I saw that you said that the ALIGN before __image_copy_end was not in the arm926-ejs link script, but when I looked I did in fact see it, e.g. in e37ae40: arch/arm/cpu/arm926ejs/u-boot.lds: ... . = .; __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; . = ALIGN(4); ^^^^^^^^^^^^^ .rel.dyn : { ... In the link script in this patch I have: . = ALIGN(4); . = .; __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; . = ALIGN(4); __image_copy_end = .; .rel.dyn : { __rel_dyn_start = .; Granted, the last ALIGN should not be needed since the size of commands should be word-aligned anyway, and the first command is clearly word-aligned, but it does make things clear I think. Can you please explain more what you mean by ' the current .lds already aligns the start and end of copy section to a multiple of 4'. And also, how you would like me to change this patch. Just remove the last ALIGN? > > >> armv7a-cros-linux-gnueabi-objdump -b binary -m arm -D u-boot.bin >> >> on each file (but I guess you know that). > > > Yes, plus 'od -t x1z -A x u-boot.bin > u-boot.lst' :) and it does not > explain why the .text and .data sections should undergo any change when the > .lds introduces a symbol that neither section references. See my note above about 'dirty', but if you are saying it is due to the ALIGN, I am not sure what to say. I don't see that, so perhaps it is best to email the commands you are using so I can replicate. Regards, Smion > > >> Regards, >> Simon > > > Amicalement, > -- > Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot