These calls should not be made directly any more, since bootstage
will call the show_boot_...() functions as needed.

Signed-off-by: Simon Glass <sjg@chromium.org>

This changes the number 15 as used in boot_stage_progress() to use the
new name provided for it. This is a separate patch because it touches
so many files.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>

We already flush the kernel image after we've loaded it to ensure
visiblity to the other cores.  We need to do the same thing for the
ramdisk and device tree images.  In AMP boot scenarios we might not be
HW cache coherent with the secondary core that we are loading and
setting the ramdisk and device tree up for.  Thus we need to ensure
we've flushed the regions of memory utilized by ramdisk and device tree
so the loadding and any modifications (from decompression or fdt updates)
are made visible to the secondary cores.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Since we are loading an executable image into memory we need flush it
out of the cache to possible maintain coherence on CPUs with split
instruction and data caches.  We do this for other executable image
loading command.

On PowerPC once we do this we no longer need to explicitly flush the
dcache on multi-core systems in the BOOTM_STATE_OS_PREP phase.  We now
treat the BOOTM_STATE_OS_PREP as a no-op to maintain backwards
compatibility with the bootm subcommand.

Signed-off-by: James Yang <James.Yang@freescale.com>
Signed-off-by: Diana CRACIUN <Diana.Craciun@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Introduce ft_verify_fdt(), a function that is called after the device tree
has been fixed up, that displays warning messages if there is a mismatch
between the physical addresses of some devices that U-Boot has configured
with what the device tree says the addresses are.

This is a particular problem when booting a 36-bit device tree from a
32-bit U-Boot (or vice versa), because the physical address of CCSR is
wrong in the device tree.  When the operating system boots, no messages are
displayed, so the user generally has no idea what's wrong.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Had a typo in the ifdef for 85xx, should be CONFIG_MPC85xx for it to get
triggered.  Was pull in the non-BookE magic number.

Reported-by: John Cortell
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

When booting with a ramdisk we bump the amount of memory reserved for
the device tree by FDT_RAMDISK_OVERHEAD.  However we did not increase
the actual size in the device tree blob to match.

Its possible on boundary cases that we dont have enough memory according
to the device tree blob and get errors like:

WARNING: could not set linux,initrd-end FDT_ERR_NOSPACE

We can easily fix this by setting the device tree size at the same time
we bump the amount of memory reserved for the device tree.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Gerald Van Baren <vanbaren@cideas.com>

If a regions is reserved in the fdt, then it should not be used.  Add
the memreserve regions to the lmb so that u-boot doesn't use them to
store the initrd.

Signed-off-by: Grant Likely <grant.likely@linaro.org>

The previous patch makes u-boot use the full accessible size of ram as
the default boot mapped size if CONFIG_SYS_BOOTMAPSZ is not defined,
which means boot_relocate_fdt() can be changed to depend solely on
CONFIG_OF_LIBFDT.

Signed-off-by: Grant Likely <grant.likely@linaro.org>

This patch adds a function getenv_bootm_mapsize() for obtaining the
size of the early mapped region accessible by the kernel during early
boot.  It defaults to CONFIG_SYS_BOOTMAPSZ, or if not defined,
defaults to getenv_bootm_size(), which in turn defaults to the size of
RAM.

getenv_bootm_mapsize() can also be overridden with a "bootm_mapsize"
environmental variable.

Signed-off-by: Grant Likely <grant.likely@linaro.org>