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

[Catalin Marinas]

On Wed, Dec 10, 2014 at 02:01:15PM +0000, Catalin Marinas wrote:
> 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.

It looks like there is a bug in our UEFI when booting non-EFI kernels.
With some firmware update, I can at least boot EFI Linux with this patch
applied. So I don't think you should revert it.

We'll add a patch to make sure all the dtb is mapped in head.S even if
it is greater than 2MB, it helps with debugging (though we still require
it to be in the first 512MB of RAM).

-- 
Catalin