[PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Simon Glass]

Hi Albert,

On Feb 19, 2012 12:27 AM, "Albert ARIBAUD" <albert.u.boot at 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.boot at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120219/7a70430f/attachment.html>