u-boot.git/scripts, branch v2016.11-rc1 Unnamed repository; edit this file 'description' to name the repository. spl: dfu: add dfu support in SPL 2016-09-27T21:30:17+00:00 B, Ravi ravibabu@ti.com 2016-07-28T12:09:14+00:00 bc5dbcb91813a429d168de58b37cb5b291d7be75 Traditionally the DFU support is available only as part 2nd stage boot loader(u-boot) and DFU is not supported in SPL. The SPL-DFU feature is useful for boards which does not have MMC/SD, ethernet boot mechanism to boot the board and only has USB inteface. This patch add DFU support in SPL with RAM memory device support to load and execute u-boot. And then leverage full functionality DFU in u-boot to flash boot inital binary images to factory or bare-metal boards to memory devices like SPI, eMMC, MMC/SD card using USB interface. This SPL-DFU support can be enabled through Menuconfig->Boot Images->Enable SPL-DFU support Signed-off-by: Ravi Babu <ravibabu@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
Traditionally the DFU support is available only
as part 2nd stage boot loader(u-boot) and DFU
is not supported in SPL.

The SPL-DFU feature is useful for boards which
does not have MMC/SD, ethernet boot mechanism
to boot the board and only has USB inteface.

This patch add DFU support in SPL with RAM
memory device support to load and execute u-boot.
And then leverage full functionality DFU in
u-boot to flash boot inital binary images to
factory or bare-metal boards to memory devices
like SPI, eMMC, MMC/SD card using USB interface.

This SPL-DFU support can be enabled through
Menuconfig->Boot Images->Enable SPL-DFU support

Signed-off-by: Ravi Babu <ravibabu@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
kconfig: introduce kconfig for UBI 2016-09-26T17:24:43+00:00 Heiko Schocher hs@denx.de 2016-09-21T05:58:19+00:00 8f2fe0c86c56175dd7d5d0e3bc26bef41f224f03 move the UBI config options into Kconfig. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andrew F. Davis <afd@ti.com> Reviewed by: Evgeni Dobrev <evgeni at studio-punkt.com> 
move the UBI config options into Kconfig.

Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Reviewed by: Evgeni Dobrev <evgeni at studio-punkt.com>
Makefile: rm u-boot.cfg dependencies are missing 2016-09-22T15:34:59+00:00 Stephen Warren swarren@nvidia.com 2016-09-19T18:20:26+00:00 a6c1309782e7a4a6b18e9514ca927487b5727232 Prior to the previous patch, a freshly created .u-boot.cfg.cmd may not correctly represent all dependencies for u-boot.cfg. The previous change only solved this issue for fresh builds; when performing an incremental build, the deficient .u-boot.cfg.cmd is already present, so u-boot.cfg is not rebuilt, and hence .u-boot.cfg.cmd is not rebuilt with the correct content. Solve this by explicitly detecting when the dependency file .u-boot.cfg.d has not been integrated into .u-boot.cfg.cmd, and force u-boot.cfg to be rebuilt in this case by deleting it first. This is possible since if_changed_dep will always delete .u-boot.cfg.d when it executes successfully, so its presence means either that the previous build was made by a source tree that contained a Makefile that didn't include the previous patch, or that the build failed part way through executing if_changed_dep for u-boot.cfg. Forcing a rebuild of u-boot.cfg is required in the former case, and will cause no additional work in the latter case, since the file would be rebuilt anyway for the same reason it was being rebuilt by the previous build. Signed-off-by: Stephen Warren <swarren@nvidia.com> 
Prior to the previous patch, a freshly created .u-boot.cfg.cmd may not
correctly represent all dependencies for u-boot.cfg. The previous change
only solved this issue for fresh builds; when performing an incremental
build, the deficient .u-boot.cfg.cmd is already present, so u-boot.cfg
is not rebuilt, and hence .u-boot.cfg.cmd is not rebuilt with the correct
content.

Solve this by explicitly detecting when the dependency file .u-boot.cfg.d
has not been integrated into .u-boot.cfg.cmd, and force u-boot.cfg to be
rebuilt in this case by deleting it first. This is possible since
if_changed_dep will always delete .u-boot.cfg.d when it executes
successfully, so its presence means either that the previous build was
made by a source tree that contained a Makefile that didn't include the
previous patch, or that the build failed part way through executing
if_changed_dep for u-boot.cfg. Forcing a rebuild of u-boot.cfg is required
in the former case, and will cause no additional work in the latter case,
since the file would be rebuilt anyway for the same reason it was being
rebuilt by the previous build.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Makefile: use if_change_dep for u-boot.cfg 2016-09-22T15:34:59+00:00 Stephen Warren swarren@nvidia.com 2016-09-19T18:20:25+00:00 fcd29a4d0e2ae3adbb129cf8e39eb025dc55e549 cmd_cpp_cfg generates a dependency output, but because it's invoked using if_changed rather than if_changed_dep, that dependency file is ignored. This results in Kbuild not knowing about which files u-boot.cfg depends on, so it may not be rebuilt when required. A practical result of this is that u-boot.cfg may continue to reference CONFIG_ options that no longer exist in the source tree, and this can cause the adhoc config options check to fail. This change modifies Makefile to use if_changed_dep, which in turn causes all dependencies to be known to the next make invocation. Signed-off-by: Stephen Warren <swarren@nvidia.com> 
cmd_cpp_cfg generates a dependency output, but because it's invoked using
if_changed rather than if_changed_dep, that dependency file is ignored.
This results in Kbuild not knowing about which files u-boot.cfg depends
on, so it may not be rebuilt when required.

A practical result of this is that u-boot.cfg may continue to reference
CONFIG_ options that no longer exist in the source tree, and this can
cause the adhoc config options check to fail.

This change modifies Makefile to use if_changed_dep, which in turn causes
all dependencies to be known to the next make invocation.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
PowerPC: Update last users of CONFIG_ISO_STRING to Kconfig 2016-09-20T13:30:26+00:00 Tom Rini trini@konsulko.com 2016-09-20T02:02:46+00:00 60c629b836fb6b6ae79e4e0663977056d75de198 There are a few boards that use CONFIG_ISO_STRING as part of a sanity check during firmware update at run time. Move this string to Kconfig. Signed-off-by: Tom Rini <trini@konsulko.com> 
There are a few boards that use CONFIG_ISO_STRING as part of a sanity
check during firmware update at run time.  Move this string to Kconfig.

Signed-off-by: Tom Rini <trini@konsulko.com>
PowerPC: Update MIP405/MIP405T to use Kconfig better 2016-09-20T13:30:25+00:00 Tom Rini trini@konsulko.com 2016-09-20T01:55:34+00:00 adf32adb706760b1c527d0d4d6b4976b36f19338 Convert CONFIG_MIP405T from SYS_EXTRA_OPTIONS to a real config There are two boards, MIP405 and MIP405T that have a few differences. Start by checking for CONFIG_TARGET_MIP405. Then introduce CONFIG_TARGET_MIP405T and use that not CONFIG_MIP405T. Next, convert also convert the usage of CONFIG_ISO_STRING to be based on Kconfig. Signed-off-by: Tom Rini <trini@konsulko.com> 
Convert CONFIG_MIP405T from SYS_EXTRA_OPTIONS to a real config

There are two boards, MIP405 and MIP405T that have a few differences.
Start by checking for CONFIG_TARGET_MIP405.  Then introduce
CONFIG_TARGET_MIP405T and use that not CONFIG_MIP405T.  Next, convert
also convert the usage of CONFIG_ISO_STRING to be based on Kconfig.

Signed-off-by: Tom Rini <trini@konsulko.com>
Makefile: Give a build error if ad-hoc CONFIG options are added 2016-09-16T21:27:24+00:00 Simon Glass sjg@chromium.org 2016-09-14T03:44:07+00:00 371244cb19f9804711dd66e4281ff7979915fd2e New CONFIG options should be added via Kconfig. To help prevent new ad-hoc CONFIGs from being added, give a build error when these are detected. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> 
New CONFIG options should be added via Kconfig. To help prevent new ad-hoc
CONFIGs from being added, give a build error when these are detected.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Kconfig: Add a whitelist of ad-hoc CONFIG options 2016-09-16T21:27:24+00:00 Simon Glass sjg@chromium.org 2016-09-14T03:44:06+00:00 eed921d923480eae759ebb79d1a1cd04f54f9445 Add a list of ad-hoc CONFIG options that don't use Kconfig. This can be used to check that new ones are not being added. Signed-off-by: Simon Glass <sjg@chromium.org> 
Add a list of ad-hoc CONFIG options that don't use Kconfig. This can be used
to check that new ones are not being added.

Signed-off-by: Simon Glass <sjg@chromium.org>
Use separate options for TPL support 2016-09-16T21:03:39+00:00 Simon Glass sjg@chromium.org 2016-09-13T05:18:25+00:00 76f1f38816d8763b51e5f1d6ca099a88aa1fd077 At present TPL uses the same options as SPL support. In a few cases the board config enables or disables the SPL options depending on whether CONFIG_TPL_BUILD is defined. With the move to Kconfig, options are determined for the whole build and (without a hack like an #undef in a header file) cannot be controlled in this way. Create new TPL options for these and update users. This will allow Kconfig conversion to proceed for these boards. Signed-off-by: Simon Glass <sjg@chromium.org> 
At present TPL uses the same options as SPL support. In a few cases the board
config enables or disables the SPL options depending on whether
CONFIG_TPL_BUILD is defined.

With the move to Kconfig, options are determined for the whole build and
(without a hack like an #undef in a header file) cannot be controlled in this
way.

Create new TPL options for these and update users. This will allow Kconfig
conversion to proceed for these boards.

Signed-off-by: Simon Glass <sjg@chromium.org>
scripts: Makefile.lib: Sanitize DTB names 2016-08-20T15:34:59+00:00 Maxime Ripard maxime.ripard@free-electrons.com 2016-07-05T08:26:35+00:00 716f90852650406d616be69c01a4f10b49742006 Having dashes as a separator in the DTB name is a quite common practice. However, the current code to generate objects from DTBs assumes the separator is an underscore, leading to a compilation error when building a device tree with dashes. Replace all the dashes in the DTB name to generate the symbols name, which should solve this issue. Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> 
Having dashes as a separator in the DTB name is a quite common practice.

However, the current code to generate objects from DTBs assumes the
separator is an underscore, leading to a compilation error when building a
device tree with dashes.

Replace all the dashes in the DTB name to generate the symbols name, which
should solve this issue.

Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>