arm64 broken in -next by commit 08d53aa58cb1 (of/fdt: export fdt blob as /sys/firmware/fdt)

[Catalin Marinas]

On Wed, Dec 10, 2014 at 01:50:12PM +0000, Grant Likely wrote:
> On Wed, Dec 10, 2014 at 1:31 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> > On Wed, Dec 10, 2014 at 12:22:10PM +0000, Catalin Marinas wrote:
> >> On Wed, Dec 10, 2014 at 12:13:26PM +0000, Catalin Marinas wrote:
> >> > On Wed, Dec 10, 2014 at 12:04:23PM +0000, Catalin Marinas wrote:
> >> > > Ard,
> >> > >
> >> > > I noticed that linux-next no longer boots on Juno. Bisecting, I ended up
> >> > > on your commit above and reverting it gets things going again. I
> >> > > initially thought it has something to do with the hardware crypto since
> >> > > you added some crc32_be() calls but disabling arm64 hw crypto didn't
> >> > > make any difference.
> >> >
> >> > Commenting out crc32_be() in early_init_dt_verify() allows it to boot.
> >> > Some printk, it shows:
> >> >
> >> > initial_boot_params = 0xffffffc01fe00000
> >> > fdt_totalsize(initial_boot_params) = 2108105
> >> >
> >> > Isn't it quite big?
> >>
> >> We assume that the DT blob is maximum 2MB in the initial kernel mapping.
> >> I'm not sure why it is that big here but early_init_dt_verify() most
> >> likely doesn't have the areas around initial_boot_params mapped, only
> >> 2MB section. The crc probably triggers a very early data abort.
> >
> > For now, I blame my Juno firmware or dtb file. I'll let you know.
> 
> Blech. I've not sent my pull request to Linus yet, so I'll revert this
> patch before I ask him to pull.

As I said, I wouldn't blame this patch, it just causes the fault early
but the dtb totalsize that gets to the kernel is definitely wrong.

The juno.dtb in firmware is 10185 bytes at the dtb totalsize agrees with
this. However, /sys/firmware/fdt (after I comment out the crc32 checks)
shows a totalsize of 2108105 and it's encoded accordingly in the second
word of the file.

I think that UEFI is somehow corrupting the dtb totalsize field before
it gets to the kernel. Still looking into this.

-- 
Catalin