tools/image-host: fix sign-images bug

property "sign-images" is never found, fix this.

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
fdt: add "fdt checksign" command

check if a fdt is correct signed
pass an optional addr value. Contains the addr of the key blob

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
fit: add sha256 support

add sha256 support to fit images

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
rsa: add sha256-rsa2048 algorithm

based on patch from andreas@oetken.name:

http://patchwork.ozlabs.org/patch/294318/
commit message:
I currently need support for rsa-sha256 signatures in u-boot and found out that
the code for signatures is not very generic. Thus adding of different
hash-algorithms for rsa-signatures is not easy to do without copy-pasting the
rsa-code. I attached a patch for how I think it could be better and included
support for rsa-sha256. This is a fast first shot.

aditionally work:
- removed checkpatch warnings
- removed compiler warnings
- rebased against current head

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: andreas@oetken.name
Cc: Simon Glass <sjg@chromium.org>
rsa: add sha256,rsa4096 algorithm

Add support for sha256,rsa4096 signatures in u-boot.

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: andreas@oetken.name
gen: Add progressive hash API

Add hash_init(), hash_update() and hash_finish() to the
hash_algo struct. Add hash_lookup_algo() to look up the
struct given an algorithm name.

Signed-off-by: Hung-ying Tyan <tyanh@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
tools, fit: add fit_info host command

add fit_info command to the host tools. This command prints
the name, offset and the len from a property from a node in
a fit file. This info can be used to extract a properties
data with linux tools, for example "dd".

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
tools, fit_check_sign: verify a signed fit image

add host tool "fit_check_sign" which verifies, if a fit image is
signed correct.

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
aes: Fix kerneldoc for aes.h

Fix the function annotations in aes.h so they're compatible with kerneldoc.

Signed-off-by: Marek Vasut <marex@denx.de>
aes: Move the AES-128-CBC encryption function to common code

Move the AES-128-CBC encryption function implemented in
tegra20-common/crypto.c into lib/aes.c . This is well re-usable common
code. Moreover, clean the code up a bit and fix the kerneldoc-style
annotations.

Signed-off-by: Marek Vasut <marex@denx.de>
aes: Implement AES-128-CBC decryption function

Implement a compatible AES-128-CBC decryption function as a counterpart
of the encryption function pulled from tegra20-common/crypto.c .

Signed-off-by: Marek Vasut <marex@denx.de>
aes: Add 'aes' command to access AES-128-CBC

Add simple 'aes' command, which allows using the AES-128-CBC encryption
and decryption functions from U-Boot command line.

Signed-off-by: Marek Vasut <marex@denx.de>
env: Add env_export() wrapper

Implement env_export() wrapper, so that all implementers of saveenv() don't
have to call hexport_r(), crc32() etc. sequence . This trims down a bit of
code duplication.

Signed-off-by: Marek Vasut <marex@denx.de>
env: Implement support for encrypting environment

Add function which allows encrypting the whole environment block with
AES-128-CBC. The key for the environment is retrieved by
env_aes_cbc_get_key() function, which must be implemented on a per-board
basis.

Signed-off-by: Marek Vasut <marex@denx.de>
env: Implement support for AES encryption into fw_* tools

Implement support for encrypting/decrypting the environment block
into the tools/env/fw_* tools. The cipher used is AES 128 CBC and
the implementation depends solely on components internal to U-Boot.

To allow building against the internal AES library, the library did
need minor adjustments to not include U-Boot's headers which are not
wanted to be included and define missing types.

Signed-off-by: Marek Vasut <marex@denx.de>
sparc: consolidate CONFIG_{LEON, LEON2, LEON3} definition

CONFIG_LEON is already defined in
arch/sparc/cpu/{leon2,leon3}/config.mk.
Remove the redundant definition in board header files.

All leon3 boards define CONFIG_LEON3 in board header files.
Move the definition to arch/sparc/cpu/leon3/config.mk.

CONFIG_LEON2 can be move to arch/sparc/cpu/leon2/config.mk
as well.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Daniel Hellstrom <daniel@gaisler.com>
i2c: sh_i2c: bugfix: i2c probe command does not work

This is regression of commit 2035d77d i2c: sh_i2c: Update to new CONFIG_SYS_I2C framework

Before commit 2035d77d, i2c probe command works properly on kzm9g board.

KZM-A9-GT# i2c probe
Valid chip addresses: 0C 12 1D 32 39 3D 40 60

After commit 2035d77d, i2c probe command does not work.

KZM-A9-GT# i2c probe
Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F

sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does not read device at all. This patch prepares dummy buffer and read data into it.

Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD

Add CONFIG_SYS_GENERIC_BOARD to use common/board_[fr].c for kzm9g.

Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Prepare v2014.04

Signed-off-by: Tom Rini <trini@ti.com>
Start the deprecation process for generic board

We should move forward to remove the old board init code. Add a
prominent message to encourage maintainers to get started on this
work.

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