Enable support for XIP (execute in place) of U-Boot or kernel image. There is
no need to copy image from flash to ram if flash supports execute in place.

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Reviewed-by: Alexandru Gagniuc <alex.g@adaptrum.com>

On ARM v7M, the processor will return to ARM mode when executing blx
instruction with bit 0 of the address == 0. Always set it to 1 to stay in thumb
mode.

At present, it is applied only for raw U-Boot. This patch moves it to just
before booting next image. This way armv7m will be in thumb mode for any image
like raw or image with header like zImage or standard U-Boot.

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>

Unit tests require mallinfo which in turn requires DEBUG on
dlmalloc to be enabled.

The dependancy on CONFIG_SANDBOX is wrong.

Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Much of the entries here simply depend on SPL (or TPL).  Instead of this
redundancy use if SPL / if TPL to guard the rest of the choices and only
show them when we have the relevant option enabled.

Signed-off-by: Tom Rini <trini@konsulko.com>

This time is interesting as a comparision with the flat device tree time.
Add it to the record.

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

At present bootstage only supports U-Boot proper. But SPL can also consume
boot time so it is useful to have the record start there.

Add bootstage support to SPL. Also support stashing the timing information
when SPL finishes so that it can be picked up and reported by U-Boot
proper. This provides a full boot time record, excluding only the time
taken by the boot ROM.

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

There are a few places that should use const *, such as
bootstage_unstash(). Update these to make it clearer when parameters are
changed.

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

We should return a proper error number instead of just -1. This helps the
caller to determine what when wrong. Update a few functions to fix this.

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

Driver model is set up ones before relocation and once after. Record the
time taken in each case.

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

At present we don't allow use of bootstage before driver model is running.
This means we cannot time the init of driver model itself.

Now that bootstage requires its own board-specific timer, we can move its
init to earlier in the sequence, both before and after relocation.

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

Some boards cannot access pre-relocation data after relocation. Reserve
space for this and copy it during preparation for relocation.

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

We don't normally want to see these messages. Change them to debug-only.

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

We can now use the record count to determine whether a record is valid or
not. Drop the test for a zero time.

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

At present bootstage has a large array with all possible bootstage IDs
recorded. It adds times to the array element indexed by the ID. This is
inefficient because many IDs are not used during boot. We can save space
by only recording those IDs which actually have timestamps.

Update the array to use a record count, which increments with each
addition of a new timestamp. This takes longer to record a time, since it
may involve an array search. Such a search may be particularly expensive
before relocation when the CPU is running slowly or the cache is off. But
at that stage there should be very few records.

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

There are several code style and comment nits. Fix them and also remove
the comment about passing bootstage to the kernel being TBD. This is
already supported.

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

At present bootstage uses the data section of the image to store its
information. There are a few problems with this:

- It does not work on all boards (e.g. those which run from flash before
relocation)
- Allocated strings still point back to the pre-relocation data after
relocation

Now that U-Boot has a pre-relocation malloc() we can use this instead,
with a pointer to the data in global_data. Update bootstage to do this and
set up an init routine to allocate the memory.

Now that we have a real init function, we can drop the fake 'reset' record
and add a normal one instead.

Note that part of the problem with allocated strings remains. They are
reallocated but this will only work where pre-relocation memory is
accessible after relocation.

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

There is no good read to make this hex, and integer is more natural for
this type of setting. Update it.

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

At present we provide a default version of this function for use by
bootstage. However it uses the system timer and therefore likely requires
driver model. This makes it impossible to time driver-model init.

Drop the function and require boards to provide their own. Add a sandbox
version also. There is a default implememtation in lib/time.c for boards
which use CONFIG_SYS_TIMER_COUNTER.

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

With a small tweak we can avoid including these files for all boards.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Put this in its own header instead of using common.h.

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

Add Kconfig symbols for various configurations
supported by FAT filesystem support code.

CONFIG_SUPPORT_VFAT has been left out since its
force enabled in include/fat.h and probably
should get removed at some point.

Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[trini: add select FS_FAT for CMD_FAT and SPL_FAT_SUPPORT]
Signed-off-by: Tom Rini <trini@konsulko.com>

This patch adds support for flashing zImage to the Android boot
partition on eMMC.

Usage:

    $ fastboot flash zImage <path_to_zImage>

It's based on [1].

[1] http://omapzoom.org/?p=repo/u-boot.git;a=commit;h=3393b908c1e848bba3706612cbe50aa8970720b3



Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

These two functions have an of_ prefix which conflicts with naming used
in of_addr. Rename them:

   fdt_read_number
   fdt_support_bus_default_count_cells

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

This function does not change the device tree so adjust it to use const
for this parameter.

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

If enabled, build a live device tree after relocation. This can then be
used by driver model.

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

With driver model MMC is probed automatically when needed. We should not
re-init MMC each time.

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

This header includes things that are needed to make driver build. Adjust
existing users to include that always, even if other dm/ includes are
present

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

Currently these (board agnostic) commands cannot be selected using
menuconfig and friends. Fix this the obvious way.  As part of this,
don't muddle the meaning of CONFIG_HASH_VERIFY to mean both 'hash -v'
and "we have a hashing command" as this makes the Kconfig logic odd.

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
[trini: Re-apply, add imply for a few cases, run moveconfig.py, also
        migrate CRC32_VERIFY]
Signed-off-by: Tom Rini <trini@konsulko.com>

This introduces the ability to override the environment offets from the
device tree by setting the following nodes in '/config':
	'u-boot,mmc-env-offset' - overrides CONFIG_ENV_OFFSET
	'u-boot,mmc-env-offset-redundant'
				- overrides CONFIG_ENV_OFFSET_REDUND

To keep with the previous logic, the CONFIG_* defines still need to
be available and the statically defined values become the defaults,
when the corresponding properties are not set in the device-tree.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>

At present IDE support is controlled by CONFIG_CMD_IDE. Add a separate
CONFIG_IDE option so that IDE support can be enabled without requiring
the 'ide' command.

Update existing users and move the ide driver into drivers/block since
it should not be in common/.

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

At present CONFIG_CMD_HASH enables the 'hash' command which also brings
in the hashing API. Some boards may wish to enable the API without the
command. Add a separate CONFIG to permit this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Commit 94e3c8c4 ("crypto/fsl - Add progressive hashing support
using hardware acceleration.") created entries for CONFIG_SHA1,
CONFIG_SHA256, CONFIG_SHA_HW_ACCEL, and CONFIG_SHA_PROG_HW_ACCEL.
However, no defconfig has migrated to it.  Complete the move by first
adding additional logic to various Kconfig files to select this when
required and then use the moveconfig tool.  In many cases we can select
these because they are required to implement other drivers.  We also
correct how we include the various hashing algorithms in SPL.

This commit was generated as follows (after Kconfig additions):

[1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
[2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL

Note:
We cannot move SHA_HW_ACCEL and SHA_PROG_HW_ACCEL simultaneously
because there is dependency between them.

Cc: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Cc: Naveen Burmi <NaveenBurmi@freescale.com>
Cc: Po Liu <po.liu@freescale.com>
Cc: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Cc: Priyanka Jain <Priyanka.Jain@freescale.com>
Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
Cc: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Chander Kashyap <k.chander@samsung.com>
Cc: Steve Rae <steve.rae@raedomain.com>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Feng Li <feng.li_2@nxp.com>
Cc: Alison Wang <alison.wang@freescale.com>
Cc: Sumit Garg <sumit.garg@nxp.com>
Cc: Mingkai Hu <Mingkai.Hu@freescale.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Akshay Saraswat <akshay.s@samsung.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_SPL_BOARD_INIT

Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
[trini: Update the Kconfig logic]
Signed-off-by: Tom Rini <trini@konsulko.com>

So far we were not using the FIT image format to its full potential:
The SPL FIT loader was just loading the first image from the /images
node plus one of the listed DTBs.
Now with the refactored loader code it's easy to load an arbitrary
number of images in addition to the two mentioned above.
As described in the FIT image source file format description, iterate
over all images listed at the "loadables" property in the configuration
node and load every image at its desired location.
This allows to load any kind of images:
- firmware images to execute before U-Boot proper (for instance
  ARM Trusted Firmware (ATF))
- firmware images for management processors (SCP, arisc, ...)
- firmware images for devices like WiFi controllers
- bit files for FPGAs
- additional configuration data
- kernels and/or ramdisks
The actual usage of this feature would be platform and/or board specific.

Also update the FIT documentation to mention the new SPL feature and
provide an example .its file to demonstrate its features.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>

At the moment we load two images from a FIT image: the actual U-Boot
image and the .dtb file. Both times we have very similar code, that deals
with alignment requirements the media we load from imposes upon us.
Factor out this code into a new function, which we just call twice.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Jagan Teki <jagan@openedev.com>

At the moment we ignore any errors due to missing FIT properties,
instead go ahead and calculate our addresses with the -1 return value.
Fix this and bail out if any of the mandatory properties are missing.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>

Currently the SPL FIT loader always looks only for the first image in
the /images node a FIT tree, which it loads and later executes.

Generalize this by looking for a "firmware" property in the matched
configuration subnode, or, if that does not exist, for the first string
in the "loadables" property. Then using the string in that property,
load the image of that name from the /images node.
This still loads only one image at the moment, but refactors the code to
allow extending this in a following patch.
To simplify later re-usage, we also generalize the spl_fit_select_index()
function to not return the image location, but just the node offset.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Jagan Teki <jagan@openedev.com>

Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
find the offset to the right DTB within the FIT image.
For this it iterates over all subnodes of the /configuration node in
the FIT tree and compares all "description" strings therein using a
board specific matching function.
If that finds a match, it uses the string in the "fdt" property of that
subnode to locate the matching subnode in the /images node, which points
to the DTB data.
Now this works very well, but is quite specific to cover this particular
use case. To open up the door for a more generic usage, let's split this
function into:
1) a function that just returns the node offset for the matching
   configuration node (spl_fit_find_config_node())
2) a function that returns the image data any given property in a given
   configuration node points to, additionally using a given index into
   a possbile list of strings (spl_fit_select_index())
This allows us to replace the specific function above by asking for the
image the _first string of the "fdt" property_ in the matching
configuration subnode points to.

This patch introduces no functional changes, it just refactors the code
to allow reusing it later.

(diff is overly clever here and produces a hard-to-read patch, so I
recommend to throw a look at the result instead).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Jagan Teki <jagan@openedev.com>

Due to a typo, the 24 bit-per-pixel configuration ends in 24BMP
instead of 24BPP. This change renames it throughout the source tree
for consistency and to make moving these options into Kconfig easier
and less error-prone.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>

Some DVI monitors don't show anything in HDMI mode since audio stream
confuses them. To solve this situation, this commit adds HDMI flag in
timing data and sets it accordingly during edid parsing.

First existence of extension block is checked. If it exists and it is
CEA861 extension, then data blocks are checked for presence of HDMI
vendor specific data block. If it is present, HDMI flag is set.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Simon Glass <sjg@chromium.org>