We are now using an env_ prefix for environment functions. Rename these
commonly used functions, for consistency. Also add function comments in
common.h.
Suggested-by: NWolfgang Denk <wd@denx.de>
Signed-off-by: NSimon Glass <sjg@chromium.org>

We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.
Suggested-by: NWolfgang Denk <wd@denx.de>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Use the env_save() function directly now that there is only one
implementation of saveenv().
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NWolfgang Denk <wd@denx.de>
Reviewed-by: NTom Rini <trini@konsulko.com>

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

This variable is declared as a global in most environment location
drivers. But it is not used outside the drivers and most of the
declarations are unnecessary.

Also some drivers call free() on env_ptr which seems wrong since it is
not in the heap.

Drop the variable where possible, and all calls to free().
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add a name to the driver and use that instead of the global variable
declared by each driver.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present we support multiple environment drivers but there is not way to
select between them at run time. Also settings related to the position and
size of the environment area are global (i.e. apply to all locations).

Until these limitations are removed we cannot really support more than one
environment location. Adjust the location to be a choice so that only one
can be selected. By default the environment is 'nowhere', meaning that the
environment exists only in memory and cannot be saved.

Also expand the help for the 'nowhere' option and move it to the top since
it is the default.
Signed-off-by: NSimon Glass <sjg@chromium.org>
[trini: Move all of the imply logic to default X if Y so it works again]
Signed-off-by: NTom Rini <trini@konsulko.com>

Set up a location driver for each supported environment location. At
present this just points to the global functions and is not used. A
later patch will switch this over to use private functions in each driver.

There are several special cases here in various drivers to handle
peculiarities of certain boards:

1. Some boards define CONFIG_ENV_IS_IN_FAT and CONFIG_SPL_ENV_SUPPORT but
do not actually load the environment in SPL. The env load code was
optimised out before but with the driver, it is not. Therefore a special
case is added to env/fat.c. The correct fix (depending on board testing
might be to disable CONFIG_SPL_ENV_SUPPORT.

2. A similar situations happens with CONFIG_ENV_IS_IN_FLASH. Some boards
do not actually load the environment in SPL, so to reduce code size we
need to drop that code. A similar fix may be possible with these boards,
or it may be possible to adjust the environment CONFIG settings.

Added to the above is that the CONFIG_SPL_ENV_SUPPORT option does not
apply when the environment is in flash.

Obviously the above has been discovered through painful and time-consuming
trial and error. Hopefully board maintainers can take a look and figure
out what is actually needed.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We want to use this name for all environment drivers. Update the nand
driver to use a more specific name.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

At present we have three states for the environment, numbered 0, 1 and 2.
Add an enum to record this to avoid open-coded values.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

This function is the same as env_get_char_spec() apart from dropping the
brackets. Drop the brackets from env_get_char_spec() and use that instead
of env_get_char_memory().
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

This function does nothing but call env_get_char_spec(). Drop it and
adjust its only caller.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

The check for gd->env_valid is used in both the 'if' and 'else' part of
env_get_char(). Move it into that function instead for simplicity. Drop
that code from the two leaf functions.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

This function is not used anywhere other than env_get_char(). Move the
code into that function.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

These functions are not used outside this file. Make them static and order
them to avoid forward declarations.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Tidy up the formatting of this option.
Signed-off-by: NSimon Glass <sjg@chromium.org>

About a quarter of the files in common/ relate to the environment. It
seems better to put these into their own subdirectory and remove the
prefix.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

This target stops us using 'env' as a subdirectory. It is not mentioned in
the help so seems to be an internal target. Rename it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

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

Rsync all defconfig files using moveconfig.py
Signed-off-by: NTom Rini <trini@konsulko.com>

Also introduce CONFIG_USE_BOOTARGS option so we can control if
CONFIG_BOOTARGS defined at all.
Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
[trini: Resync r8a779[56]_ulcb, various ls10xx targets]
Signed-off-by: NTom Rini <trini@konsulko.com>

Even after memory free of phydev, priv is still pointing to the
obsolete address.
So update priv->phydev as NULL after memory free.
Signed-off-by: NPrabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Signed-off-by: NAshish Kumar <Ashish.Kumar@nxp.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Add support for Microchip LAN7500, LAN7800 and LAN7850,
USB to 10/100/1000 Ethernet Controllers.
Signed-off-by: NYuiko Oshino <yuiko.oshino@microchip.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Add an mii helper function to resolve flow control status per
IEEE 802.3-2005 table 28B-3.
This function was taken from the Linux source tree.
Signed-off-by: NYuiko Oshino <yuiko.oshino@microchip.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

While it is likely that this entire case is superfluous and can be
removed, correct the test now to match what is in rockchip-common.h and
makes sense based on context of the code.  Otherwise we get a large
number of warnings.
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

A few years ago STM32F1 SoCs support has been added :
0144caf2  gpio: stm32: add stm32f1 support
2d18ef23  ARMv7M: add STM32F1 support

But neither STM32F1 dedicated defconfig nor board was
associated to these commits.

Got confirmation from Tom Rini and Matt Porter to remove
all this code [1]

[1] http://u-boot.10912.n7.nabble.com/Remove-STM32F1-support-td301603.htmlSigned-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

This appears to be a simple typo that dates back to the original
implementation of board_detail in commit e7939464 ("common: Update
cmd_bdinfo for PPC").
Signed-off-by: NChris Packham <judge.packham@gmail.com>

Move this test so that it will run when 'make tests' is used.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Convert this test to use the pytest framework.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We plan to rewrite this script to use the pytest framework. To make it
easier to review the changes, indent the code to match the next patch.
This gets all of the whitespace changes out of the way.
Signed-off-by: NSimon Glass <sjg@chromium.org>

OMAP5432 did go into production with AVS class0 registers which were
mutually exclusive from AVS Class 1.5 registers.

Most OMAP5-uEVM boards use the pre-production Class1.5 which has
production efuse registers set to 0. However on production devices,
these are set to valid data.

scale_vcore logic is already smart enough to detect this and use the
"Nominal voltage" on devices that do not have efuse registers populated.

On a test production device populated as follows:
MPU OPP_NOM:
=> md.l 0x04A0021C4 1
4a0021c4: 03a003e9                               ....
(0x3e9 = 1.01v) vs nom voltage of 1.06v
MPU OPP_HIGH:
=> md.l 0x04A0021C8 1
4a0021c8: 03400485                               ..@.

MM OPP_NOM:
=> md.l 0x04A0021A4 1
4a0021a4: 038003d4                               ....
(0x3d4 = 980mV) vs nom voltage of 1.025v
MM OPP_OD:
=> md.l 0x04A0021A8 1
4a0021a8: 03600403                               ..`.

CORE OPP_NOM:
=> md.l 0x04A0021D8 1
4a0021d8: 000003cf                               ....
(0x3cf = 975mV) vs nom voltage of 1.040v

Since the efuse values are'nt currently used, we do not regress on
existing pre-production samples (they continue to use nominal voltage).

But on boards that do have production samples populated, we can leverage
the optimal voltages necessary for proper operation.

Tested on:
a) 720-2644-001 OMAP5UEVM with production sample.
b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.

Data based on OMAP5432 Technical reference Manual SWPU282AF (May
2012-Revised Aug 2016)

NOTE: All collaterals on OMAP5432 silicon itself seems to have been
removed from ti.com, though EVM details are still available:
http://www.ti.com/tool/OMAP5432-EVMSigned-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>

ES2.0 descopes OPP_LOW definition. So remove it from macros defined.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>