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

[Simon Glass]

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.

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

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

We could have a separate output section if you like. Up to you.

Regards,
Simon

>
> Amicalement,
> --
> Albert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120218/7391fcf3/attachment.html>