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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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@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.

>> 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.

> 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.

> Regards,
> Simon

Amicalement,
-- 
Albert.