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

Hi Albert,

On Sun, Feb 19, 2012 at 10:33 AM, Albert ARIBAUD
[off-list ref] wrote:

Hi Simon,

Le 19/02/2012 17:23, Simon Glass a écrit :

quoted

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.

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

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

quoted

quoted

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.

quoted

quoted

quoted

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

quoted

Regards,
Simon

Amicalement,
--
Albert.