tools: moveconfig: do not cleanup headers in include/generated

The files in include/generated are generated during build and removed
by "make mrproper", so it has no point to touch them by this tool

tools: moveconfig: do not cleanup headers in include/generated

The files in include/generated are generated during build and removed
by "make mrproper", so it has no point to touch them by this tool.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

buildman: Add a quick-start note

For those who just want to build a board, it is useful to see a quick hint
right at the start of the documentation. Add a few commands showing how to
download toolch

buildman: Add a quick-start note

For those who just want to build a board, it is useful to see a quick hint
right at the start of the documentation. Add a few commands showing how to
download toolchains and build a board.

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

show more ...

buildman: Avoid overwriting existing toolchain entries

The current code for setting up the toolchain config always writes the new
paths to an item called 'toolchain'. This means that it will overwri

buildman: Avoid overwriting existing toolchain entries

The current code for setting up the toolchain config always writes the new
paths to an item called 'toolchain'. This means that it will overwrite any
existing toolchain item with the same name. In practice, this means that:

buildman --fetch-arch all

will fetch all toolchains, but only the path of the final one will be added
to the config. This normally works out OK, since most toolchains are the
same version (e.g. gcc 4.9) and will be found on the same path. But it is
not correct and toolchains for archs which don't use the same version will
not function as expected.

Adjust the code to use a complete glob of the toolchain path.

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

show more ...

buildman: Drop the toolchain error when downloading toolchains

It doesn't make sense to complain about missing toolchains when the
--fetch-arch option is being used. The user is presumably aware tha

buildman: Drop the toolchain error when downloading toolchains

It doesn't make sense to complain about missing toolchains when the
--fetch-arch option is being used. The user is presumably aware that there
is a toolchain problem and is actively correcting it by running with this
option.

Refactor the code to avoid printing this confusing message.

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

show more ...

buildman: Fix a typo in TestSettingsHasPath()

The function comment should say 'buildman'. Fix it.

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

buildman: Improve the toolchain progress/error output

Use colour to make it easier to see what is going on. Also print a message
before downloading a new toolchain. Mention --fetch-arch in the messa

buildman: Improve the toolchain progress/error output

Use colour to make it easier to see what is going on. Also print a message
before downloading a new toolchain. Mention --fetch-arch in the message that
is shown when there are no available toolchains, since this is the quickest
way to resolve the problem.

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

show more ...

buildman: Allow the toolchain error to be suppressed

When there are no toolchains a warning is printed. But in some cases this is
confusing, such as when the user is fetching new toolchains.

Adjust

buildman: Allow the toolchain error to be suppressed

When there are no toolchains a warning is printed. But in some cases this is
confusing, such as when the user is fetching new toolchains.

Adjust the function to supress the warning in this case.

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

show more ...

buildman: Fix the 'help' test to use the correct path

When buildman is run via a symlink, this test fails. Fix it to work the same
way as buildman itself.

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

buildman: Fix the 'help' test to use the correct path

When buildman is run via a symlink, this test fails. Fix it to work the same
way as buildman itself.

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

show more ...

buildman: Automatically create a config file if needed

If there is no ~/.buildman file, buildman currently complains and exists. To
make things a little more friendly, create an empty one automatica

buildman: Automatically create a config file if needed

If there is no ~/.buildman file, buildman currently complains and exists. To
make things a little more friendly, create an empty one automatically. This
will not allow things to be built, but --fetch-arch can be used to handle
that.

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

show more ...

buildman: Tidy up the README a little

Tidy up some problems found by a recent review.

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

Merge branch 'master' of git://git.denx.de/u-boot-i2c

tools: env: Fix format warnings in debug

Format warnings (-Wformat) were shown in printf() calls after defining
DEBUG macro.

Update format string and explicitly cast variables to suppress all
warni

tools: env: Fix format warnings in debug

Format warnings (-Wformat) were shown in printf() calls after defining
DEBUG macro.

Update format string and explicitly cast variables to suppress all
warnings.

Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>

show more ...

mkimage: rockchip: add suport for rk33 serial

Add support for rockchip rk33 series Soc like rk3368 and rk3399

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromi

mkimage: rockchip: add suport for rk33 serial

Add support for rockchip rk33 series Soc like rk3368 and rk3399

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

mkimage: rockchip: add suport for rk33 serial

Add support for rockchip rk33 series Soc like rk3368 and rk3399

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromi

mkimage: rockchip: add suport for rk33 serial

Add support for rockchip rk33 series Soc like rk3368 and rk3399

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

dtoc: Correct the type widening code in fdt_fallback

This code does not match the fdt version in fdt.py. When dtoc is unable to
use the Python libfdt library, it uses the fallback version, which doe

dtoc: Correct the type widening code in fdt_fallback

This code does not match the fdt version in fdt.py. When dtoc is unable to
use the Python libfdt library, it uses the fallback version, which does not
widen arrays correctly.

Fix this to avoid a warning 'excess elements in array initialize' in
dt-platdata.c which happens on some platforms.

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

show more ...

tools, rsa: Further minor cleanups on top of c236ebd and 2b9ec7

[NOTE: I took v1 of these patches in, and then v2 came out, this commit
is squashing the minor deltas from v1 -> v2 of updates to c236

tools, rsa: Further minor cleanups on top of c236ebd and 2b9ec7

[NOTE: I took v1 of these patches in, and then v2 came out, this commit
is squashing the minor deltas from v1 -> v2 of updates to c236ebd and
2b9ec76 into this commit - trini]

- Added an additional NULL check, as suggested by Simon Glass to
fit_image_process_sig
- Re-formatted the comment blocks

Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
[For merging the chnages from v2 back onto v1]
Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...

tools: Fix return code of fit_image_process_sig()

When signing images, we repeatedly call fit_add_file_data() with
successively increasing size values to include the keys in the DTB.

Unfortunately,

tools: Fix return code of fit_image_process_sig()

When signing images, we repeatedly call fit_add_file_data() with
successively increasing size values to include the keys in the DTB.

Unfortunately, if large keys are used (such as 4096 bit RSA keys), this
process fails sometimes, and mkimage needs to be called repeatedly to
integrate the keys into the DTB.

This is because fit_add_file_data actually returns the wrong error
code, and the loop terminates prematurely, instead of trying again with
a larger size value.

This patch corrects the return value and also removes a error message,
which is misleading, since we actually allow the function to fail. A
(hopefully helpful) comment is also added to explain the lack of error
message.

This is probably related to 1152a05 ("tools: Correct error handling in
fit_image_process_hash()") and the corresponding error reported here:

https://www.mail-archive.com/u-boot@lists.denx.de/msg217417.html

Signed-off-by: Mario Six <mario.six@gdsys.cc>

show more ...

tools/env: reuse fw_getenv in fw_printenv function

Try to avoid adhoc iteration of the environment. Reuse fw_getenv
to find the variables that should be printed. Only use open-coded
iteration when p

tools/env: reuse fw_getenv in fw_printenv function

Try to avoid adhoc iteration of the environment. Reuse fw_getenv
to find the variables that should be printed. Only use open-coded
iteration when printing all variables.
For backwards compatibility, keep emitting a newline when
printing with value_only.

Signed-off-by: Andreas Fenkart <andreas.fenkart@digitalstrom.com>

show more ...

tools/env: move envmatch further up in file to avoid forward declarations

forward declaration not needed when re-ordered

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

tools/env: move envmatch further up in file to avoid forward declarations

forward declaration not needed when re-ordered

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andreas Fenkart <andreas.fenkart@digitalstrom.com>

show more ...

tools/env: kernel-doc for fw_printenv, fw_getenv and fw_parse_script

there are two groups of functions:
- application ready tools: fw_setenv/fw_getenv/fw_parse_script
these are used, when creating a

tools/env: kernel-doc for fw_printenv, fw_getenv and fw_parse_script

there are two groups of functions:
- application ready tools: fw_setenv/fw_getenv/fw_parse_script
these are used, when creating a single binary containing multiple
tools (busybox like)
- file access like: open/read/write/close
above functions are implemented on top of these. applications
can use those to modify several variables without creating a
temporary batch script file
tested with "./scripts/kernel-doc -html -v tools/env/fw_env.h"

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andreas Fenkart <andreas.fenkart@digitalstrom.com>

show more ...

tools/env: allow negative offsets

A negative value for the offset is treated as a backwards offset for
from the end of the device/partition for block devices. This aligns
the behavior of the config

tools/env: allow negative offsets

A negative value for the offset is treated as a backwards offset for
from the end of the device/partition for block devices. This aligns
the behavior of the config file with the syntax of CONFIG_ENV_OFFSET
where the functionality has been introduced with
commit 5c088ee841f9 ("env_mmc: allow negative CONFIG_ENV_OFFSET").

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

show more ...

tools/env: complete environment device config early

Currently flash_read completes a crucial part of the environment
device configuration, the device type (mtd_type). This is rather
confusing as fla

tools/env: complete environment device config early

Currently flash_read completes a crucial part of the environment
device configuration, the device type (mtd_type). This is rather
confusing as flash_io calls flash_read conditionally, and one might
think flash_write, which also makes use of mtd_type, gets called
before flash_read. But since flash_io is always called with O_RDONLY
first, this is not actually the case in reality.

However, it is much cleaner to complete and verify the config early
in parse_config. This also prepares the code for further extension.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Reviewed-by: Andreas Fenkart

show more ...

Various, unrelated tree-wide typo fixes.

Fix a number of typos, including:

* "compatble" -> "compatible"
* "eanbeld" -> "enabled"
* "envrionment" -> "environment"
* "FTD" ->

Various, unrelated tree-wide typo fixes.

Fix a number of typos, including:

* "compatble" -> "compatible"
* "eanbeld" -> "enabled"
* "envrionment" -> "environment"
* "FTD" -> "FDT" (for "flattened device tree")
* "ommitted" -> "omitted"
* "overriden" -> "overridden"
* "partiton" -> "partition"
* "propogate" -> "propagate"
* "resourse" -> "resource"
* "rest in piece" -> "rest in peace"
* "suport" -> "support"
* "varible" -> "variable"

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

show more ...

Merge git://git.denx.de/u-boot-dm

dm: core: Expand platdata for of-platdata devices

Devices which use of-platdata have their own platdata. However, in many
cases the driver will have its own auto-alloced platdata, for use with the
d

dm: core: Expand platdata for of-platdata devices

Devices which use of-platdata have their own platdata. However, in many
cases the driver will have its own auto-alloced platdata, for use with the
device tree. The ofdata_to_platdata() method converts the device tree
settings to platdata.

With of-platdata we would not normally allocate the platdata since it is
provided by the U_BOOT_DEVICE() declaration. However this is inconvenient
since the of-platdata struct is closely tied to the device tree properties.
It is unlikely to exactly match the platdata needed by the driver.

In fact a useful approach is to declare platdata in the driver like this:

struct r3288_mmc_platdata {
struct dtd_rockchip_rk3288_dw_mshc of_platdata;
/* the 'normal' fields go here */
};

In this case we have dt_platadata available, but the normal fields are not
present, since ofdata_to_platdata() is never called. In fact driver model
doesn't allocate any space for the 'normal' fields, since it sees that there
is already platform data attached to the device.

To make this easier, adjust driver model to allocate the full size of the
struct (i.e. platdata_auto_alloc_size from the driver) and copy in the
of-platdata. This means that when the driver's bind() method is called,
the of-platdata will be present, followed by zero bytes for the empty
'normal field' portion.

A new DM_FLAG_OF_PLATDATA flag is available that indicates that the platdata
came from of-platdata. When the allocation/copy happens, the
DM_FLAG_ALLOC_PDATA flag will be set as well. The dtoc tool is updated to
output the platdata_size field, since U-Boot has no other way of knowing
the size of the of-platdata struct.

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

show more ...