Fix several warnings when enabling UBIFS on MIPS:

In file included from ubifs.h:2137:0,
                 from ubifs.c:26:
misc.h: In function 'ubifs_zn_dirty':
misc.h:38:2: warning: passing argument 2 of 'test_bit' discards 'const' qualifier from pointer target type [enabled by default]
../include/asm/bitops.h:569:23: note: expected 'volatile void *' but argument is of type 'const long unsigned int *'
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

If bal is 8 bytes aligned, the _gp will not be 8 bytes aligned.
then the following ld insntrustion generates a Adel exception.
So here make _gp be always aligned in 8 bytes.
Signed-off-by: NZhi-zhou Zhang <zhizhou.zh@gmail.com>
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

The filename buffer is allocated dynamically. It must be cache aligned.
Moreover, it is necessary to erase its content before we use it for
file name operations.

This prevents from corruption of written file names.
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

Several fixes to suppress compiler's (eldk-5.[12].x  gcc 4.6)
warning  [-Wunused-but-set-variable]
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

The device block descriptor (block_dev_desc_t) )shall be stored at
ext4 early code (at ext4fs_set_blk_dev in this case) to be available
for latter use (like put_ext4()).
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

The ext4write code has been using direct calls to 64-32 division
(/ and %).

Officially supported u-boot toolchains (eldk-5.[12].x) generate calls
to __aeabi_uldivmod(), which is niether defined in the toolchain libs
nor u-boot source tree.

Due to that, when the ext4write command has been executed, "undefined
instruction" execption was generated (since the __aeabi_uldivmod()
is not provided).

To fix this error, lldiv() for division and do_div() for modulo have
been used.

Those two functions are recommended for performing 64-32 bit number
division in u-boot.
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

Change e-mail address of Luka Perkov.
Signed-off-by: NLuka Perkov <luka@openwrt.org>
CC: Luka Perkov <uboot@lukaperkov.net>

If the pl011 is connected to another device which has hardware
flow-control on, characters are never received by the pl011.
Asserting RTS when flow-control is off will have no effect.

This is in line with how Linux behaves.
Signed-off-by: NJoshua Housh <joshua.housh@calxeda.com>
Tested-by: NMarek Vasut <marex@denx.de>

Since there's no obvious mention, add a brief reference to the
custodians page at www.denx.de
Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>

The config is current broken. It compiles but does not boot because IDE is
enabled. Remove all IDE options, and enable SCSI instead.

Also add a working boot command and Linux bootargs, and enable command
line editing to make it easier to work with.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This allows u-boot to figure out the partitions of a chrome-os install.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Enable the display on coreboot, using CFB.
Signed-off-by: NSimon Glass <sjg@chromium.org>

When running from coreboot we don't want this code, so make it
optional.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function is not intended to be exported from the video drivers, so
remove the prototype. This fixes an error:

cfb_console.c:1793:12: error: static declaration of 'video_init' follows non-static declaration
Signed-off-by: NSimon Glass <sjg@chromium.org>

This command will start erasing at memory address zero
if there is not a valid framebuffer address that was found
during video_init().

This is a common case with Chrome OS devices in normal mode
when we do not execute the video option rom in coreboot.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

The function setup_pcat_compatibility() is weak and implemented as empty
function in board.c hence we don't have to override that with another
empty function.

monitor_flash_len is unused, drop it.
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

... because that information is already "encoded" in the directory name.
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Some systems (like Google Link device) provide the ability to keep a
history of the target CPU port80 accesses, which is extremely handy
for debugging. The problem is that the EC handling port 80 access is
orders of magnitude slower than the AP. This causes random loss of
trace data.

This change allows to throttle port 80 accesses such that in case the
AP is trying to post faster than the EC can handle, a delay is
introduced to make sure that the post rate is throttled. Experiments
have shown that on Link the delay should be at least 350,000 of tsc
clocks.

Throttling is not being enabled by default: to enable it one would
have to set MIN_PORT80_KCLOCKS_DELAY to something like 400 and rebuild
the u-boot image. With upcoming EC code optimizations this number
could be decreased (new new value should be established
experimentally).
Signed-off-by: NVadim Bendebury <vbendeb@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Some u-boot modules rely on availability of get_ticks() and
get_tbclk() functions, reporting a free running clock and its
frequency respectively. Traditionally these functions return number
and frequency of timer interrupts.

Intel's core architecture processors however are known to run the
rdtsc instruction at a constant rate of the so called 'Max Non Turbo
ratio' times the external clock frequency which is 100MHz. This is
just as good for the timer tick functions in question.
Signed-off-by: NVadim Bendebury <vbendeb@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This will write magic value to APMC command port which
will trigger an SMI and cause coreboot to lock down
the ME, chipset, and CPU.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Coreboot was always using MTRR 7 for the write-protect
cache entry that covers the ROM and U-boot was removing it.
However with 4GB configs we need more MTRRs for the BIOS
and so the WP MTRR needs to move.  Instead coreboot will
always use the last available MTRR that is normally set
aside for OS use and U-boot can clear it before the OS.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This helps us monitor boot progress and determine where U-Boot dies if
there are any problems.
Signed-off-by: NStefan Reinauer <reinauer@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This contains just the minimum information for a coreboot-based board.
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

We will use coreboot.dtsi as our fdt include file.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Allow a device tree to be provided through the standard mechanisms.
Signed-off-by: NGabe Black <gabeblack@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This option delays loading of the environment until later, so that only the
default environment will be available to U-Boot.

This can address the security risk of untrusted data being used during boot.

When CONFIG_DELAY_ENVIRONMENT is defined, it is convenient to have a
run-time way of enabling loadinlg of the environment. Add this to the
fdt as /config/delay-environment.

Note: This patch depends on http://patchwork.ozlabs.org/patch/194342/Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>

These were removed, but actually are useful.

Cold means that we started from a reset/power on.
Warm means that we started from another U-Boot.

We determine whether u-boot on x86 was warm or cold booted (really if
it started at the beginning of the text segment or at the ELF entry point).
We plumb the result through to the global data structure.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Because calculate_relocation_address now uses the e820 map, it will be able
to avoid addresses over 32 bits and regions that are at high addresses but
not big enough for U-Boot. It also means we can remove the hack which
limitted U-Boot's idea of the size of memory to less than 4GB.

Also take into account the space needed for the heap and stack, so we avoid
picking a very small region those areas might overlap with something it
shouldn't.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Different systems may have different mechanisms for picking a suitable place
to relocate U-Boot to.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This seems to be a bug.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This changes the layout in decreasing addresses from:

1. Stack
2. Sections in the image
3. Heap

to

1. Sections in the image
2. Heap
3. Stack

This allows the stack to grow significantly more since it isn't constrained by
the other u-boot areas. More importantly, the generic memory wipe code assumes
that the stack is the lowest addressed area used by the main part of u-boot.
In the original layout, that means that u-boot tramples all over itself. In
the new layout, it works.
Signed-off-by: NGabe Black <gabeblack@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

If we have SPI support, make sure that we init it.
Signed-off-by: NGabe Black <gabeblack@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NVic Yang <victoryang@chromium.org>

Implement arch_phys_memset so that it can set memory at physical addresses
above 4GB using PAE paging. Because there are only 5 page tables in PAE mode,
1 PDPT and 4 PDTs, those tables are statically allocated in the BSS. The
tables must be 4K page aligned and are declared that way, and because U-Boot
starts as 4K aligned and the relocation code relocates it to a 4K aligned
address, the tables work as intended.

While paging is turned on, all 4GB are identity mapped except for one 2MB
page which is used as the window into high memory. This way, U-Boot will
continue to work as expected when running code that expects to access memory
freely, but the code can still get at high memory through its window.

The window is put at 2MB so that it's 2MB page aligned, low in memory to be
out of the way of things U-Boot is likely to care about, and above the lowest
1MB where lots of random things live.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

The default implementation of this function is just memset, but other
implementations will be needed when physical memory isn't accessible by
U-Boot using normal addressing mechanisms.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NChe-Liang Chiou <clchiou@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

These types should be 64 bits long to reflect the fact that physical
addresses and the size of physical areas of memory are more than 32 bits
long.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

The use of post-increment with a do-while loop results in
the loop going one step too far when handling relocation fixups.

In about 1/100 cases this would cause it to hang.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

U-boot is unable to actually use that memory and it can
cause problems with relocation if it tries to.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Enable this option to support booting a zImage.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This fixes the following warning:

zimage.c:312: Warning: indirect jmp without `*'

Also fixed these warnings to keep checkpatch quiet:

warning: arch/x86/lib/zimage.c,311: unnecessary whitespace before a quoted newline
warning: arch/x86/lib/zimage.c,312: unnecessary whitespace before a quoted newline
warning: arch/x86/lib/zimage.c,313: unnecessary whitespace before a quoted newline
Signed-off-by: NSimon Glass <sjg@chromium.org>