Hi Tom & Rob,
On Thu, 8 Apr 2021 at 06:09, Tom Rini <trini@xxxxxxxxxxxx> wrote:
>
> On Thu, Apr 08, 2021 at 03:35:35AM +1200, Simon Glass wrote:
> > Hi Rob,
> >
> > On Wed, 7 Apr 2021 at 07:07, Rob Herring <robh@xxxxxxxxxx> wrote:
> > >
> > > Only checking the FDT alignment in fdt_ro_probe_() means that
> > > fdt_check_header() can pass, but then subsequent API calls fail on
> > > alignment checks. Let's add an alignment check to fdt_check_header() so
> > > alignment errors are found up front.
> > >
> > > Cc: Tom Rini <trini@xxxxxxxxxxxx>
> > > Cc: Frank Rowand <frowand.list@xxxxxxxxx>
> > > Signed-off-by: Rob Herring <robh@xxxxxxxxxx>
> > > ---
> > > For background, the new alignment check triggered a crash in the
> > > linux kernel. Yes, we should fix the error handling, but
> > > fdt_check_header() shouldn't tell us the FDT is valid only to fail
> > > later on.
> > >
> > > Maybe we should move the check instead, but fdt_ro_probe_() and
> > > fdt_check_header() already have a lot of the same checks.
> > >
> > > libfdt/fdt.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> >
> > At present U-Boot uses a 4-byte alignment, so far as I know, so this
> > will break things.
>
> It's 8 byte, not 4 byte and I have nothing good to say about places that
> get by with 4-and-not-8 alignment.
I am thinking of this in arch/arm/cpu/u-boot.lds :
. = ALIGN(4);
.image_copy_end : {
At least for now, we use 4-byte alignment on 32-bit ARM, for example.
Regards,
Simon
