This command is based on driver model regulator's API.
The user interface provides:
- list UCLASS regulator devices
- show or [set] operating regulator device
- print constraints info
- print operating status
- print/[set] voltage value [uV] (force)
- print/[set] current value [uA]
- print/[set] operating mode id
- enable the regulator output
- disable the regulator output

The 'force' option can be used for setting the value which exceeds
the constraints min/max limits.
Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This is new command for the PMIC devices based on driver model PMIC API.
Command features are unchanged:
- list UCLASS pmic devices
- show or [set] operating pmic device (NEW)
- dump registers
- read byte of register at address
- write byte to register at address

The only one change for this command is 'dev' subcommand.
Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Add a simple command which provides access to a list of available CPUs along
with descriptions and basic information.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

As suggested by Simon Glass, rename the sb command to host but keep the
old sb command as an alias
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: NSimon Glass <sjg@chromium.org>

Sometimes, for example if the display is mounted in portrait mode or even if it
is mounted landscape but rotated by 180 degrees, we need to rotate our content
of the display respectively the framebuffer, so that user can read the messages
which are printed out.

For this we introduce the feature called "CONFIG_LCD_ROTATION", this may be
defined in the board-configuration if needed. After this the lcd_console will
be initialized with a given rotation from "vl_rot" out of "vidinfo_t" which is
provided by the board specific code.

If CONFIG_LCD_ROTATION is not defined, the console will be initialized with
0 degrees rotation.
Signed-off-by: NHannes Petermaier <hannes.petermaier@br-automation.com>
Signed-off-by: NHannes Petermaier <oe5hpm@oevsv.at>
Acked-by: NNikita Kiryanov <nikita@compulab.co.il>
[agust: fixed 'struct vidinfo' has no member named 'vl_rot' errors]
Signed-off-by: NAnatolij Gustschin <agust@denx.de>

The ARM reference designs all use a special flash image format
that stores a footer (two versions exist) at the end of the last
erase block of the image in flash memory.

Version one of the footer is indicated by the magic number
0xA0FFFF9F at 12 bytes before the end of the flash block and
version two is indicated by the magic number 0x464F4F54 0x464C5348
(ASCII for "FLSHFOOT") in the very last 8 bytes of the erase block.

This command driver implements support for both versions of the
AFS images (the name comes from the Linux driver in drivers/mtd/afs.c)
and makes it possible to list images and load an image by name into
the memory with these commands:

afs - lists flash contents
afs load <image> - loads image to address indicated in the image
afs load <image> <addres> - loads image to a specified address

This image scheme is used on the ARM Integrator family, ARM
Versatile family, ARM RealView family (not yet supported in U-Boot)
and ARM Versatile Express family up to and including the new
Juno board for 64 bit development.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We now have api functions that can support compiling simplefb code as its own
module. Since this code is not part of the display functionality, extract it
to its own file.

Raspberry Pi is updated to accommodate the changes.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NBo Shen <voice.shen@atmel.com>
Tested-by: NJosh Wu <josh.wu@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>

The common/board_r.c has show_model_r() to display the model name
if the DTB has a "model" property.  It sounds useful to have a similar
function in common/board_f.c too because most of the boards show
their board name before relocation.

Instead of implementing the same function in both common/board_f.c
and common/board_r.c, let's split it up into common/show_board_info.c.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Move board/compulab/common/splash.c code to
common/splash_source.c to make it available for everybody. This move
renames cl_splash_screen_prepare() to splash_source_load(), and
the compilation of this code is conditional on CONFIG_SPLASH_SOURCE.

splash_source features:
* Provide a standardized way for declaring board specific splash screen
  locations
* Provide existing routines for auto loading the splash image from the
  locations as declared by the board
* Introduce the "splashsource" environment variable, which makes it
  possible to select the splash image source.

cm-t35 and cm-fx6 are updated to use the modified version.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Anatolij Gustschin <agust@denx.de>
Reviewed-by: NTom Rini <trini@ti.com>
Acked-by: NIgor Grinberg <grinberg@compulab.co.il>

common/lcd.c is a mix of code portions that do different but related
things. To improve modularity, the various code portions should be split
into their own modules. Separate lcd console code into its own file.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

To support interactive DDR debugger, cli_simple.o, cli.o, cli_readline.o,
command.o, s_record.o, xyzModem.o and cmd_disk.o are all needed for
drivers/ddr/fsl/interactive.c.

In current common/Makefile, the above .o files are only produced when
CONFIG_SPL_BUILD is disabled.

For LS102xA, interactive DDR debugger is needed in SD/NAND boot too, and
I enabled CONFIG_FSL_DDR_INTERACTIVE. But according to the current
common/Makfile, all the above .o files are not produced in SPL part
because CONFIG_SPL_BUILD is enabled in SPL part, the following error
will be shown,

drivers/ddr/fsl/built-in.o: In function `fsl_ddr_interactive':
/home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1871:
undefined reference to `cli_readline_into_buffer'
/home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1873:
undefined reference to `cli_simple_parse_line'
make[1]: *** [spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl] Error 2

So this patch fixed this issue and the above .o files will be produced
no matter CONFIG_SPL_BUILD is enabled or disabled.
Signed-off-by: NAlison Wang <alison.wang@freescale.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

Some filesystems have a UUID stored in its superblock. To
allow using root=UUID=... for the kernel command line we
need a way to read-out the filesystem UUID.

changes rfc -> v1:
 - make the environment variable an option parameter. If not
   given, the UUID is printed out. If given, it is stored in the env
   variable.
 - corrected typos
 - return error codes

changes v1 -> v2:
 - fix return code of do_fs_uuid(..)
 - document do_fs_uuid(..)
 - implement fs_uuid_unsuported(..) be more consistent with the
   way other optional functionality works

changes v2 -> v3:
 - change ext4fs_uuid(..) to make use of #if .. #else .. #endif
   construct to get rid of unreachable code

Hit any key to stop autoboot:  0
=> fsuuid
fsuuid - Look up a filesystem UUID

Usage:
fsuuid <interface> <dev>:<part>
    - print filesystem UUID
fsuuid <interface> <dev>:<part> <varname>
    - set environment variable to filesystem UUID

=> fsuuid mmc 0:1
d9f9fc05-45ae-4a36-a616-fccce0e4f887
=> fsuuid mmc 0:2
eb3db83c-7b28-499f-95ce-9e0bb21cda81
=> fsuuid mmc 0:1 uuid1
=> fsuuid mmc 0:2 uuid2
=> printenv uuid1
uuid1=d9f9fc05-45ae-4a36-a616-fccce0e4f887
=> printenv uuid2
uuid2=eb3db83c-7b28-499f-95ce-9e0bb21cda81
=>
Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: NStephen Warren <swarren@nvidia.com>

The simple malloc() implementation is used when memory is tight. It provides
a simple buffer with an incrementing pointer.

At present the implementation is inside dlmalloc. Move it into its own file
so that it is easier to find.

Rather than using relocation as a signal that the full malloc() is
available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the
simple malloc() should no longer be used.

In some cases, such as SPL, even the code space used by the full malloc() is
wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple
malloc. In this case the full malloc is not available at all. It saves about
1KB of code space and about 0.5KB of data on Thumb 2.
Acked-by: NTom Rini <trini@ti.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

If CONFIG_SPL_BUILD and CONFIG_ENV_IS_IN_FAT are
defined, u-boot spl will fail to build. Fix that.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Freescale's SEC block has built-in Blob Protocol which provides
a method for protecting user-defined data across system power
cycles. SEC block protects data in a data structure called a Blob,
which provides both confidentiality and integrity protection.

Encapsulating data as a blob
Each time that the Blob Protocol is used to protect data, a
different randomly generated key is used to encrypt the data.
This random key is itself encrypted using a key which is derived
from SoC's non volatile secret key and a 16 bit Key identifier.
The resulting encrypted key along with encrypted data is called a blob.
The non volatile secure key is available for use only during secure boot.

During decapsulation, the reverse process is performed to get back
the original data.

Commands added
--------------
    blob enc - encapsulating data as a cryptgraphic blob
    blob dec - decapsulating cryptgraphic blob to get the data

Commands Syntax
---------------
	blob enc src dst len km

	Encapsulate and create blob of data $len bytes long
	at address $src and store the result at address $dst.
	$km is the 16 byte key modifier is also required for
	generation/use as key for cryptographic operation. Key
	modifier should be 16 byte long.

	blob dec src dst len km

	Decapsulate the  blob of data at address $src and
	store result of $len byte at addr $dst.
	$km is the 16 byte key modifier is also required for
	generation/use as key for cryptographic operation. Key
	modifier should be 16 byte long.
Signed-off-by: NRuchika Gupta <ruchika.gupta@freescale.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

[1] Move driver/core/, driver/input/ and drivers/input/ entries
    from the top Makefile to drivers/Makefile

[2] Remove the conditional by CONFIG_DM in drivers/core/Makefile
    because the whole drivers/core directory is already selected
    by CONFIG_DM in the upper level

[3] Likewise for CONFIG_DM_DEMO in drivers/demo/Makefile

[4] Simplify common/Makefile - both CONFIG_DDR_SPD and
    CONFIG_SPD_EEPROM are boolean macros so they can directly
    select objects
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NMarek Vasut <marex@denx.de>

- add capability to "fastboot flash" with sparse format images
Signed-off-by: NSteve Rae <srae@broadcom.com>
Acked-by: NLukasz Majewski <l.majewski@samsung.com>

- add support for 'fastboot flash' command for eMMC devices
Signed-off-by: NSteve Rae <srae@broadcom.com>

CONFIG_SPL_NET_SUPPORT is not the only time we want SPL to ahve
environment, CONFIG_SPL_ENV_SUPPORT is when we want it.
Signed-off-by: NTom Rini <trini@ti.com>

When debugging drivers it is useful to see what I/O accesses were done
and in what order.

Even if the individual accesses are of little interest it can be useful to
verify that the access pattern is consistent each time an operation is
performed. In this case a checksum can be used to characterise the operation
of a driver. The checksum can be compared across different runs of the
operation to verify that the driver is working properly.

In particular, when performing major refactoring of the driver, where the
access pattern should not change, the checksum provides assurance that the
refactoring work has not broken the driver.

Add an I/O tracing feature and associated commands to provide this facility.
It works by sneaking into the io.h heder for an architecture and redirecting
I/O accesses through its tracing mechanism.

For now no commands are provided to examine the trace buffer. The format is
fairly simple, so 'md' is a reasonable substitute.

Note: The checksum feature is only useful for I/O regions where the contents
do not change outside of software control. Where this is not suitable you can
fall back to manually comparing the addresses. It might be useful to enhance
tracing to only checksum the accesses and not the data read/written.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This file has code in three different categories:
- Command processing
- OS-specific boot code
- Locating images and setting up to boot

Only the first category really belongs in a file called cmd_bootm.c.

Leave the command processing code where it is. Split out the OS-specific
boot code into bootm_os.c. Split out the other code into bootm.c

Header files and extern declarations are tidied but otherwise no code
changes are made, to make it easier to review.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This code is only used by one board, so it seems a shame to clutter up
the readline code with it. Move it into its own file.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We now have a single entry point to the CLI, whether simple or hush. Put
this in its own file.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The autoboot code is complex and long. It deserves its own file with
a simple interface from main.c.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It doesn't make sense to have the simple parser and the readline code
all in main. Split them out into separate files.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Hush is a command-line interpreter, so rename it to make that clearer.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This patch contains an implementation of the fastboot protocol on the
device side and documentation. This is based on USB download gadget
infrastructure. The fastboot function implements the getvar, reboot,
download and reboot commands. What is missing is the flash handling i.e.
writting the image to media.

v3 (Rob Herring):
This is based on http://patchwork.ozlabs.org/patch/126798/ with the
following changes:
- Rebase to current mainline and updates for current gadget API
- Use SPDX identifiers for licenses
- Traced the history and added missing copyright to cmd_fastboot.c
- Use load_addr/load_size for transfer buffer
- Allow vendor strings to be optional
- Set vendor/product ID from config defines
- Allow Ctrl-C to exit fastboot mode
v4:
- Major re-write to use the USB download gadget. Consolidated function
code to a single file.
- Moved globals into single struct.
- Use puts and putc as appropriate.
- Added CONFIG_USB_FASTBOOT_BUF_ADDR and CONFIG_USB_FASTBOOT_BUF_SIZE to
set the fastboot transfer buffer.
v5:
- Add CONFIG option documentation to README
- Rebase using new downloader registration
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NRob Herring <robh@kernel.org>

This patch adds support for the Android boot-image format. The header
file is from the Android project and got slightly alterted so the struct +
its defines are not generic but have something like a namespace. The
header file is from bootloader/legacy/include/boot/bootimg.h. The header
parsing has been written from scratch and I looked at
bootloader/legacy/usbloader/usbloader.c for some details.
The image contains the physical address (load address) of the kernel and
ramdisk. This address is considered only for the kernel image.
The "second image" defined in the image header is currently not
supported. I haven't found anything that is creating this.

v3 (Rob Herring):
This is based on http://patchwork.ozlabs.org/patch/126797/ with the
following changes:
- Rebased to current mainline
- Moved android image handling to separate functions in
  common/image-android.c
- s/u8/char/ in header to fix string function warnings
- Use SPDX identifiers for licenses
- Cleaned-up file source information:
  android_image.h is from file include/boot/bootimg.h in repository:
  https://android.googlesource.com/platform/bootable/bootloader/legacy
  The git commit hash is 4205b865141ff2e255fe1d3bd16de18e217ef06a
  usbloader.c would be from the same commit, but it does not appear
  to have been used for any actual code.
v4:
- s/andriod/android/
- Use a separate flag ep_found to track if the entry point has been set
rather than using a magic value.

Cc: Wolfgang Denk <wd@denx.de>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NRob Herring <robh@kernel.org>
Reviewed-by: NTom Rini <trini@ti.com>
Reviewed-by: NLukasz Majewski <l.majewski@samsung.com>

I needed to be able to uncompress lzma files. I did this command
based on unzip command and propose it if it could help.
Signed-off-by: NPatrice Bouchand <pbfwdlist@gmail.com>
Changed to work with sandbox
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add simple 'aes' command, which allows using the AES-128-CBC encryption
and decryption functions from U-Boot command line.
Signed-off-by: NMarek Vasut <marex@denx.de>

Add a common library for obtaining access to the Chrome OS EC. This is
used by boards which need to talk to the EC.
Reviewed-by: NVadim Bendebury <vbendeb@google.com>
Tested-by: NVadim Bendebury <vbendeb@google.com>
Signed-off-by: NVadim Bendebury <vbendeb@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

As an example of how to write a uclass and a driver, provide a demo version
of each, accessible through the 'demo' command.

To use these with driver model, define CONFIG_CMD_DEMO and CONFIG_DM_DEMO.

The two demo drivers are enabled with CONFIG_DM_DEMO_SIMPLE and
CONFIG_DM_DEMO_SHAPE.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NPavel Herrmann <morpheus.ibis@gmail.com>
Signed-off-by: NViktor Křivák <viktor.krivak@gmail.com>
Signed-off-by: NTomas Hlavacek <tmshlvck@gmail.com>

When we tell the compiler to optimize for ARMv7 (and ARMv6 for that
matter) it assumes a default of SCTRL.A being cleared and unaligned
accesses being allowed and fast at the hardware level.  We set this bit
and must pass along -mno-unaligned-access so that the compiler will
still breakdown accesses and not trigger a data abort.

To better help understand the requirements of the project with respect
to unaligned memory access, the
Documentation/unaligned-memory-access.txt file has been added as
doc/README.unaligned-memory-access.txt and is taken from the v3.14-rc1
tag of the kernel.

Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Mans Rullgard <mans@mansr.com>
Signed-off-by: NTom Rini <trini@ti.com>

We have an unused FAT implementation in fs/fdos, remove.
Signed-off-by: NTom Rini <trini@ti.com>

Now we are ready to switch over to real Kbuild.

This commit disables temporary scripts:
  scripts/{Makefile.build.tmp, Makefile.host.tmp}
and enables real Kbuild scripts:
  scripts/{Makefile.build,Makefile.host,Makefile.lib}.

This switch is triggered by the line in scripts/Kbuild.include
  -build := -f $(if $(KBUILD_SRC),$(srctree)/)scripts/Makefile.build.tmp obj
  +build := -f $(if $(KBUILD_SRC),$(srctree)/)scripts/Makefile.build obj

We need to adjust some build scripts for U-Boot.
But smaller amount of modification is preferable.

Additionally, we need to fix compiler flags which are
locally added or removed.

In Kbuild, it is not allowed to change CFLAGS locally.
Instead, ccflags-y, asflags-y, cppflags-y,
CFLAGS_$(basetarget).o, CFLAGS_REMOVE_$(basetarget).o
are prepared for that purpose.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: NGerhard Sittig <gsi@denx.de>

This commit changes the working directory
where the build process occurs.

Before this commit, build process occurred under the source
tree for both in-tree and out-of-tree build.

That's why we needed to add $(obj) prefix to all generated
files in makefiles like follows:
  $(obj)u-boot.bin:  $(obj)u-boot

Here, $(obj) is empty for in-tree build, whereas it points
to the output directory for out-of-tree build.

And our old build system changes the current working directory
with "make -C <sub-dir>" syntax when descending into the
sub-directories.

On the other hand, Kbuild uses a different idea
to handle out-of-tree build and directory descending.

The build process of Kbuild always occurs under the output tree.
When "O=dir/to/store/output/files" is given, the build system
changes the current working directory to that directory and
restarts the make.

Kbuild uses "make -f $(srctree)/scripts/Makefile.build obj=<sub-dir>"
syntax for descending into sub-directories.
(We can write it like "make $(obj)=<sub-dir>" with a shorthand.)
This means the current working directory is always the top
of the output directory.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: NGerhard Sittig <gsi@denx.de>

Add spl_sata to read a fat partition from a bootable SATA
drive.
Signed-off-by: NDan Murphy <dmurphy@ti.com>
Reviewed-by: NRoger Quadros <rogerq@ti.com>

Command provides just dump subcommand for showing clock
frequencies in a soc.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Acked-by: NStefano Babic <sbabic@denx.de>

Add SPL support to be able to detect a USB Mass Storage device
connected to a USB host.  Once a USB Mass storage device is detected
the SPL will load the u-boot.img from a FAT partition to target address.
Signed-off-by: NDan Murphy <dmurphy@ti.com>

Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>