Hi Albert, On Feb 19, 2012 12:27 AM, "Albert ARIBAUD" <albert.u.b...@aribaud.net> wrote: > > Hi Simon, > > Le 18/02/2012 19:09, Simon Glass a écrit : > >> Hi Albert, >> >> On Feb 18, 2012 3:51 AM, "Albert ARIBAUD"<albert.u.b...@aribaud.net> wrote: >>> >>> >>> Hi Simon, >>> >>> Le 12/01/2012 05:32, Simon Glass a écrit : >>> >>>> By putting the fdt blob into a distinctive area we can ensure that it >> >> appears >>>> >>>> at the start of the data section and is word-aligned. >>>> >>>> Note: It does not seem to be possible to get objcopy to honour its >>>> --section-alignment flag, which would otherwise provide an easier fix >>>> for this problem. >>> >>> >>> >>> Stop me if I am wrong, but objcopy obviously works with output sections >> >> of its input file, not with input ones that this file was linked from, and >> so it cannot act upon alignment of data input sections, right? And as, >> before your patch, there is no designated output section for DTS data, it >> ends up (possibly mis-aligned) in the .data output section (which is >> globally aligned however), so there is no chance anyway that objcopy can >> re-align DTS data if they were mis-aligned. >> >> Well that's a shame if true. I was rather hoping that it would respect >> input section alignment when packing into an output section - it must do >> that in at least some cases since otherise I don't see how code regions >> could be collected together without one becoming misaligned if the one >> before was an odd size. > > > Objcopy is only a utility to convert built binaries from one format to another, and rightly ignores any alignment considerations. Alignment constraints are solved at link time within the .lds file. This is why I suggest a separate output section in u-boot.lds, because then you can set that section's alignment where all alignment constraints are laid out. >
Sorry I had that wrong - it's not the link step I am bothered by, it is the objcopy step. What I would like to do is mark the input section, created by objcopy, with a particular alignment so that the linker does the right thing. This feature appears to be present in objcopy but does not appear to work. Perhaps I should debug that first to see what is going on. > >>> So I must be missing something. Can you clarify the scenario that gets >> >> fixed here? >> >> The fdt blob is in one of the object files. If during linking the file >> before it has a data segment whose size is not a multiple of 4, then the >> fdt object can be misaligned in the output. > > > Understood. This example of an alignment failure scenario shows that the failure cause is indeed that the FDT is embedded in the .data output section at link time. > > >>> Not that I am against the patch, mind you, quite the opposite. I am just >> >> wondering about the pros and cons of having a separated (and aligned) DTS >> data *output* section and placing that section after .code and .data rather >> than between them. >> >> Bear in mind that embedding the fdt in the image is really only for >> development. > > > Understood, and I think that's one more reason to make sure that the act of FDT embedding does not alter .data input section ordering. > Well it is just a data section really. > >> We could have a separate output section if you like. Up to you. > > > I much prefer embedded FDT data to be explicitly mapped to a a dedicated .fdt output section in u-boot.lds, because it ensures that aligment constaints for .fdt and .data can be controlled independently. I will take a look at this. Regards, Simon > > >> Regards, >> Simon > > > Amicalement, > -- > Albert.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
