<p>Hi Albert,</p>
<p>On Feb 19, 2012 12:27 AM, "Albert ARIBAUD" <<a href="mailto:albert.u.boot@aribaud.net">albert.u.boot@aribaud.net</a>> wrote:<br>
><br>
> Hi Simon,<br>
><br>
> Le 18/02/2012 19:09, Simon Glass a écrit :<br>
><br>
>> Hi Albert,<br>
>><br>
>> On Feb 18, 2012 3:51 AM, "Albert ARIBAUD"<<a href="mailto:albert.u.boot@aribaud.net">albert.u.boot@aribaud.net</a>>  wrote:<br>
>>><br>
>>><br>
>>> Hi Simon,<br>
>>><br>
>>> Le 12/01/2012 05:32, Simon Glass a écrit :<br>
>>><br>
>>>> By putting the fdt blob into a distinctive area we can ensure that it<br>
>><br>
>> appears<br>
>>>><br>
>>>> at the start of the data section and is word-aligned.<br>
>>>><br>
>>>> Note: It does not seem to be possible to get objcopy to honour its<br>
>>>> --section-alignment flag, which would otherwise provide an easier fix<br>
>>>> for this problem.<br>
>>><br>
>>><br>
>>><br>
>>> Stop me if I am wrong, but objcopy obviously works with output sections<br>
>><br>
>> of its input file, not with input ones that this file was linked from, and<br>
>> so it cannot act upon alignment of data input sections, right? And as,<br>
>> before your patch, there is no designated output section for DTS data, it<br>
>> ends up (possibly mis-aligned) in the .data output section (which is<br>
>> globally aligned however), so there is no chance anyway that objcopy can<br>
>> re-align DTS data if they were mis-aligned.<br>
>><br>
>> Well that's a shame if true. I was rather hoping that it would respect<br>
>> input section alignment when packing into an output section - it must do<br>
>> that in at least some cases since otherise I don't see how code regions<br>
>> could be collected together without one becoming misaligned if the one<br>
>> before was an odd size.<br>
><br>
><br>
> 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.<br>

></p>
<p>Sorry I had that wrong - it's not the link step I am bothered by, it is the objcopy step.</p>
<p>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.</p>

<p>><br>
>>> So I must be missing something. Can you clarify the scenario that gets<br>
>><br>
>> fixed here?<br>
>><br>
>> The fdt blob is in one of the object files. If during linking the file<br>
>> before it has a data segment whose size is not a multiple of 4, then the<br>
>> fdt object can be misaligned in the output.<br>
><br>
><br>
> 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.<br>
><br>
><br>
>>> Not that I am against the patch, mind you, quite the opposite. I am just<br>
>><br>
>> wondering about the pros and cons of having a separated (and aligned) DTS<br>
>> data *output* section and placing that section after .code and .data rather<br>
>> than between them.<br>
>><br>
>> Bear in mind that embedding the fdt in the image is really only for<br>
>> development.<br>
><br>
><br>
> 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.<br>
></p>
<p>Well it is just a data section really.</p>
<p>><br>
>> We could have a separate output section if you like. Up to you.<br>
><br>
><br>
> 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.</p>
<p>I will take a look at this.</p>
<p>Regards,<br>
Simon</p>
<p>><br>
><br>
>> Regards,<br>
>> Simon<br>
><br>
><br>
> Amicalement,<br>
> -- <br>
> Albert.<br>
</p>