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

[Ard Biesheuvel]

On 10 December 2014 at 13:22, Catalin Marinas <catalin.marinas at arm.com> 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.
>

Looking at the patch history, I just noticed that the crc() call got
moved to before fdt_check_header(), which means initial_boot_params
may point to something else than an FDT.
How exactly that may happen, and how the system ends up booting after
all is not clear to me, but the crc32() call should be moved down
regardless

-- 
Ard.