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

[Simon Glass]

Hi Albert,

On Sun, Feb 19, 2012 at 10:33 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Simon,
>
> Le 19/02/2012 17:23, Simon Glass a écrit :
>
>
>> 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.
>
>
> (Formally there are two "objcopy steps" in u-boot building. One happens
> after the link step, where from the u-boot ELF binary objcopy derives the
> u-boot.bin pure binary and u-boot.srec S-Record file. I suspect you're
> referring to the other one, which happens before the link stage and which
> turns the binary FDT data into an ELF-linkable object. Correct?)
>
> Maybe one is allowed to specify alignment requirements when making an ELF
> object file from a pure binary with objcopy; but obviously it does not work
> as you want it to, whereas section alignment in linker scripts is a tried
> and proven method.
>
>
>>>>> 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.
>
>
> So are the relocation tables in .rel.dyn and .dynsyms, but that does not
> mean they have to go to the "dot data" output section.
>
>
>>>> 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.
>
>
> Thanks. This should be fairly easy to do in the linker script by inserting
> an output section (e.g. ".fdt") after .data, aligning the start of that
> section to a word boundary, and explicitly mapping the .data section of the
> FDT object file into it.

Just an update on this: I am going to drop this patch from the series
now and deal with it later once the lds cleanup series lands. I don't
want to patch a file that is being removed.

Regards,
Simon

>
>
>> Regards,
>> Simon
>
>
> Amicalement,
> --
> Albert.