These are pure lookup tables -- no need to be writable.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

By now, the majority of architectures have working relocation
support, so the few remaining architectures have become exceptions.
To make this more obvious, we make working relocation now the default
case, and flag the remaining cases with CONFIG_NEEDS_MANUAL_RELOC.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Tested-by: Heiko Schocher <hs@denx.de>
Tested-by: Reinhard Meyer <u-boot@emk-elektronik.de>

The device tree (fdt) must always exist in within the bootmap (usually the
first 16MB of RAM).  If it doesn't, then boot_relocate_fdt() will allocate
an LMB region in the bootmap and copy the fdt into that region.  It will
also increase the size of the fdt.

If the fdt is already in the bootmap, then previously the memory was just
reserved.  There was no contingency if the reservation failed, however.

By always allocating an lmb region and copying/resizing the fdt into that
region, the code is simplified and the memory region is always allocated
properly.

Also change the types of some variables to avoid some typecasts.

Signed-off-by: Timur Tabi <timur@freescale.com>
Tested-by: Ira Snyder <iws@ovro.caltech.edu>
Acked-by: Gerald Van Baren <vanbaren@cideas.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

The routines boot_ramdisk_high, boot_get_cmdline and boot_get_kbd
are currently enabled by various combinations of CONFIG_M68K,
CONFIG_POWERPC and CONFIG_SPARC.

Use CONFIG_SYS_BOOT_<FEATURE> defines instead.

CONFIG_SYS_BOOT_RAMDISK_HIGH
CONFIG_SYS_BOOT_GET_CMDLINE
CONFIG_SYS_BOOT_GET_KBD

Define these as appropriate in arch/include/asm/config.h files.

Signed-off-by: John Rigby <john.rigby@linaro.org>
Acked-by: Wolfgang Denk <wd@denx.de>

fdt_totalsize returns size in cpu endian so don't call be32_to_cpu
on the result.  This was harmless on big endian platforms but not
on little endian ARMs.

Signed-off-by: John Rigby <john.rigby@linaro.org>

boot_relocate_fdt is called on platforms with CONFIG_SYS_BOOTMAPSZ
defined to relocate the device tree blob to be inside the
boot map area between bootmap_base and bootmap_base+CONFIG_SYS_BOOTMAPSZ.

For the case where the blob needs to be relocated, space is
allocated inside the bootmap by calling lmb_alloc_base with
size passed in plus some padding:

    of_len = *of_size + CONFIG_SYS_FDT_PAD;

For the case where the blob is already inside the bounds of the boot map
area, lmb_reserve is called to reserve the the space where the blob is
already residing.  The calculation for this case is currently:

    of_len = (CONFIG_SYS_BOOTMAPSZ + bootmap_base) - (ulong)fdt_blob;

This is wrong because it reserves all the space in the boot map area
from the blob to the end ignoring completely the actual size. The
worst case is where the blob is at the beginning and the entire boot map
area get reserved. Fix this by changing the length calculation to this:

    of_len = *of_size + CONFIG_SYS_FDT_PAD;

This bug has likely never manifested itself because bootm has never
been called with the fdt blob already in the bootmap area.  In my
testing on an OMAP3 beagle board I initially worked around the bug
by simply moving the initial location of the fdt blob.  I have tested
with the new calculation with the fdt blob both inside and outside
the boot map area.

Signed-off-by: John Rigby <john.rigby@linaro.org>

Add OSE as operating system for mkimage and bootm.

Signed-off-by: Torkel Lundgren <torkel.lundgren@enea.com>

Platforms with flat device tree support can use a bootmap to relocate
the fdt_blob. This is not a must. That's why the relocation function
boot_relocate_fdt() should be use only if CONFIG_OF_LIBFDT was defined
together with CONFIG_SYS_BOOTMAPSZ (see common/cmd_bootm.c).

On MicroBlaze platforms there is no need to use a bootmap to relocate
a fdt blob. So we need a more precise focus on the compilation and usage
of boot_relocate_fdt().

In general it is valid to exclude the function boot_relocate_fdt() if
the bootmap size CONFIG_SYS_BOOTMAPSZ is not defined.

Signed-off-by: Stephan Linz <linz@li-pro.net>

If the user sets bootm_low and does not set bootm_size, u-boot will
report the memory node in the flat device tree incorrectly. Instead
of reporting the remaining size of memory, it will report the total
available memory which is incorrect.

Specifically this fixes the situation when booting a relocatable
kernel and the memory is reported as an offset and size in the
device tree, and the size needs to be adjusted accordingly.

Signed-off-by: Matthew McClintock <msm@freescale.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>

The hush shell dynamically allocates (and re-allocates) memory for the
argument strings in the "char *argv[]" argument vector passed to
commands.  Any code that modifies these pointers will cause serious
corruption of the malloc data structures and crash U-Boot, so make
sure the compiler can check that no such modifications are being done
by changing the code into "char * const argv[]".

This modification is the result of debugging a strange crash caused
after adding a new command, which used the following argument
processing code which has been working perfectly fine in all Unix
systems since version 6 - but not so in U-Boot:

int main (int argc, char **argv)
{
	while (--argc > 0 && **++argv == '-') {
/* ====> */	while (*++*argv) {
			switch (**argv) {
			case 'd':
				debug++;
				break;
			...
			default:
				usage ();
			}
		}
	}
	...
}

The line marked "====>" will corrupt the malloc data structures and
usually cause U-Boot to crash when the next command gets executed by
the shell.  With the modification, the compiler will prevent this with
an
	error: increment of read-only location '*argv'

N.B.: The code above can be trivially rewritten like this:

	while (--argc > 0 && **++argv == '-') {
		char *arg = *argv;
		while (*++arg) {
			switch (*arg) {
			...

Signed-off-by: Wolfgang Denk <wd@denx.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>