ppc64/purgatory: Device tree values should be read/stored in Big Endian

The purgatory code reads the device tree's version and stores if needed the
currently running CPU number. These 2 values are stored in Big Endian
format in the device tree and should be byte swapped when running in Little
Endian mode.

Without this fix, when running in SMP environment, kexec or kdump kernel may
fail booting with the following message :
Failed to identify boot CPU

Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data

e820 reserved region could be useful in 2nd kernel.

For example, PCI mmconf (extended mode) requires reserved region
otherwise it falls back to legacy mode. The following log is from Cliff
Wickman <cpw@sgi.com>:

 PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000)
 [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources
 PCI: not using MMCONFIG

PCI devices on segment 1 (>0) can't fall back to legacy mode, thus
kernel probing fails and device can't be found.

We don't pass reserved region because these regions could be too much
and eat up our very limited kernel command line resource in
memmap=exactmap case.

However now we use e820 map and setup_data to pass memory map to 2nd
kernel and the number of reserved regions should not be a problem any
more.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
zImage-arm: get rid of static offset

The code in arch/arm/kexec-zImage-arm.c currently enforces a hard limit
on the maximum size a dtb blob can occupy. This limit is set to 32k,
which is quite low for device tree blobs nowadays.

Get rid of this assumption, and calculate the added size dynamically.
For this, we need to slurp in the dtb file earlier in order to
determine its size, because the memory hole allocation for 'base'
takes this size into account.

For ATAGs, we keep the current value of 32k, which should in fact be
enough.

With this change in place, the 'DTB too large!' error message can go
away. Successfully tested on a AM335x board.

Signed-off-by: Daniel Mack <zonque@gmail.com>
[s.neumann@raumfeld.com: Fix ATAGs case]
Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Simon Horman <horms@verge.net.au>