06 Jul, 2018

1 commit


01 Jun, 2018

1 commit

  • When env save is failed, 2018 u-boot will loop infinitely to save the env,
    and each time returns failure. The root cause is env_driver_lookup only returns
    current env location for ENVOP_SAVE, no matter what the prio is. So the loop
    can't exit until the save is successful.

    Signed-off-by: Ye Li

    Ye Li
     

26 Apr, 2018

3 commits

  • The ENV_IS_IN_SATA config is missed, add it into env/Kconfig, that
    we can enable it for SATA boot.

    Signed-off-by: Ye Li

    Ye Li
     
  • Fix below build warning and errors:
    env/sata.c: In function ‘env_sata_save’:
    env/sata.c:59:9: warning: implicit declaration of function ‘sata_get_dev’ [-Wimplicit-function-declaration]
    sata = sata_get_dev(env_sata);
    ^~~~~~~~~~~~
    env/sata.c:59:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
    sata = sata_get_dev(env_sata);
    ^
    env/sata.c: In function ‘env_sata_load’:
    env/sata.c:101:10: warning: ‘return’ with a value, in function returning void
    return -EIO;
    ^
    env/sata.c:94:13: note: declared here
    static void env_sata_load(void)
    ^~~~~~~~~~~~~
    env/sata.c:105:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
    sata = sata_get_dev(env_sata);
    ^
    env/sata.c:108:10: warning: ‘return’ with a value, in function returning void
    return -EIO;
    ^
    env/sata.c:94:13: note: declared here
    static void env_sata_load(void)
    ^~~~~~~~~~~~~
    env/sata.c:113:10: warning: ‘return’ with a value, in function returning void
    return -EIO;
    ^
    env/sata.c:94:13: note: declared here
    static void env_sata_load(void)
    ^~~~~~~~~~~~~
    env/sata.c:116:9: warning: ‘return’ with a value, in function returning void
    return env_import(buf, 1);
    ^~~~~~~~~~~~~~~~~~
    env/sata.c:94:13: note: declared here
    static void env_sata_load(void)
    ^~~~~~~~~~~~~
    env/sata.c: At top level:
    env/sata.c:120:14: error: ‘ENVL_ESATA’ undeclared here (not in a function)
    .location = ENVL_ESATA,
    ^~~~~~~~~~
    env/sata.c:122:11: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
    .load = env_sata_load,

    Signed-off-by: Ye Li

    Ye Li
     
  • Wrong env buffer was passed into sata write function, so the saveenv can't work.
    Fix this issue.

    Signed-off-by: Ye Li
    (cherry picked from commit 0fe7573cffcb50d6bcb401f644cc37f5af28b388)

    Ye Li
     

20 Feb, 2018

1 commit


17 Feb, 2018

2 commits

  • With multiple environments, the 'get_char' callback for env
    drivers does not really make sense any more because it is
    only supported by two drivers (eeprom and nvram).

    To restore single character loading for these drivers,
    override 'env_get_char_spec'.

    Signed-off-by: Simon Goldschmidt
    Acked-by: Maxime Ripard

    Goldschmidt Simon
     
  • Commit 7d714a24d725 ("env: Support multiple environments") added
    static variable env_load_location. When saving environmental
    variables, this variable is presumed to have the value set before.
    In case the value was set before relocation and U-Boot runs from a
    NOR flash, this variable wasn't writable. This causes failure when
    saving the environment. To save this location, global data must be
    used instead.

    Signed-off-by: York Sun
    CC: Maxime Ripard

    York Sun
     

13 Feb, 2018

1 commit

  • When saving the environment on a platform which has DMA alignment
    larger than the natural alignment, env_fat_save triggers a debug
    message in file_fat_write:

    Saving Environment to FAT... writing uboot.env
    FAT: Misaligned buffer address (9df1c8e0)
    OK

    Signed-off-by: Alex Kiernan

    Alex Kiernan
     

01 Feb, 2018

4 commits

  • For the redundant environment configuration, env_sf_load still
    contained duplicate code instead of using env_import_redund().

    Simplify the code by only executing the load twice and delegating
    everything else to env_import_redund.

    Signed-off-by: Simon Goldschmidt
    Acked-by: Maxime Ripard

    Simon Goldschmidt
     
  • For multiple env drivers to correctly implement fallback when
    one environment fails to load (e.g. crc error), the return value
    of env_import has to be propagated by all env driver's load
    function.

    Without this change, the first driver that succeeds to load an
    environment with an invalid CRC return 0 (success) and no other
    drivers are checked.

    Signed-off-by: Simon Goldschmidt
    Acked-by: Maxime Ripard

    Simon Goldschmidt
     
  • There is more common code in mmc, nand and ubi env drivers that
    can be shared by moving to env_import_redund.

    For this, a status/error value whether the buffers were loaded
    are passed as additional parameters to env_import_redund.
    Ideally, these are already returned to the env driver by the
    storage driver. This is the case for mmc, nand and ubi, so for
    this change, code deduplicated.

    Signed-off-by: Simon Goldschmidt
    Acked-by: Maxime Ripard

    Simon Goldschmidt
     
  • env_import (and env_import_redund) currently return 1 on success
    and 0 on error. However, they are only used from functions
    returning 0 on success or a negative value on error.

    Let's clean this up by making env_import and env_import_redund
    return 0 on success and -EIO on error (as was the case for all
    users before).

    Users that cared for the return value are also updated. Funny
    enough, this only affects onenand.c and sf.c

    Signed-off-by: Simon Goldschmidt
    Acked-by: Maxime Ripard

    Simon Goldschmidt
     

27 Jan, 2018

14 commits

  • Now that we have everything in place to implement the transition scheme,
    let's enable it by default.

    Reviewed-by: Andre Przywara
    Reviewed-by: Lukasz Majewski
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • Allow boards and architectures to override the default environment lookup
    code by overriding env_get_location.

    Reviewed-by: Andre Przywara
    Reviewed-by: Lukasz Majewski
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • Now that we have everything in place in the code, let's allow to build
    multiple environments backend through Kconfig.

    Reviewed-by: Andre Przywara
    Reviewed-by: Lukasz Majewski
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • The raw MMC environment directly calls into the MMC framework. Make sure
    it's enabled before we can select it.

    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard
    Reviewed-by: Jaehoon Chung

    Maxime Ripard
     
  • Since we want to have multiple environments, we will need to initialise
    all the environments since we don't know at init time what drivers might
    fail when calling load.

    Let's init all of them, and only consider for further operations the ones
    that have not reported any errors at init time.

    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • Now that we have everything in place to support multiple environment, let's
    make sure the current code can use it.

    The priority used between the various environment is the same one that was
    used in the code previously.

    At read / init times, the highest priority environment is going to be
    detected, and we'll use the same one without lookup during writes. This
    should implement the same behaviour than we currently have.

    Reviewed-by: Andre Przywara
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • Since we have global messages to indicate what's going on, the custom
    messages in the environment drivers only make the output less readable.

    Make the common code play a little nicer by removing all the extra output
    in the standard case.

    Reviewed-by: Andre Przywara
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • Since we have global messages to indicate what's going on, the custom
    messages in the environment drivers only make the output less readable.

    Make MMC play a little nicer by removing all the extra \n and formatting
    that is redundant with the global output.

    Reviewed-by: Andre Przywara
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard
    Reviewed-by: Jaehoon Chung

    Maxime Ripard
     
  • Since we have global messages to indicate what's going on, the custom
    messages in the environment drivers only make the output less readable.

    Make FAT play a little nicer by removing all the extra \n and formatting
    that is redundant with the global output.

    Reviewed-by: Andre Przywara
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • Since we can have multiple environments now, it's better to provide a
    decent indication on what environments were tried and which were the one to
    fail and succeed.

    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • Since we'll soon have support for multiple environments, the environment
    saving message might end up being printed multiple times if the higher
    priority environment cannot be used.

    That might confuse the user, so let's make it explicit if the operation
    failed or not.

    Reviewed-by: Andre Przywara
    Reviewed-by: Lukasz Majewski
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • In preparation for the multiple environment support, let's introduce two
    new parameters to the environment driver lookup function: the priority and
    operation.

    The operation parameter is meant to identify, obviously, the operation you
    might want to perform on the environment.

    The priority is a number passed to identify the environment priority you
    want to retrieve. The lowest priority parameter (0) will be the primary
    source.

    Combining the two parameters allow you to support multiple environments
    through different priorities, and to change those priorities between read
    and writes operations.

    This is especially useful to implement migration mechanisms where you want
    to always use the same environment first, be it to read or write, while the
    common case is more likely to use the same environment it has read from to
    write it to.

    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • The env_driver_lookup_default and env_get_default_location functions are
    about to get refactored to support loading from multiple environment.

    The name is therefore not really well suited anymore. Drop the default
    part to be a bit more relevant.

    Reviewed-by: Andre Przywara
    Reviewed-by: Lukasz Majewski
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     
  • The nvedit command is the only user of env_driver_lookup_default outside of
    the environment code itself, and it uses it only to print the environment
    it's about to save to during env save.

    As we're about to rework the environment to be able to handle multiple
    environment sources, we might not have an idea of what environment backend
    is going to be used before trying (and possibly failing for some).

    Therefore, it makes sense to remove that message and move it to the
    env_save function itself. As a side effect, we also can get rid of the call
    to env_driver_lookup_default that is also about to get refactored.

    Reviewed-by: Andre Przywara
    Reviewed-by: Lukasz Majewski
    Reviewed-by: Simon Glass
    Signed-off-by: Maxime Ripard

    Maxime Ripard
     

23 Jan, 2018

1 commit

  • Make it select FS_FAT as well, because if it's not selected, enabling
    ENV_IS_IN_FAT causes a Kconfig warning:

    warning: (ENV_IS_IN_FAT) selects FAT_WRITE which has unmet direct dependencies (FS_FAT)

    This also allows dropping some code from config_fallbacks.

    Also drop the unnecessary help text about having to enable
    CONFIG_FAT_WRITE - Kconfig automatically handles that.

    Signed-off-by: Tuomas Tynkkynen

    Tuomas Tynkkynen
     

18 Jan, 2018

2 commits


16 Jan, 2018

1 commit

  • For example to store the environment in a file named "/uboot.env" in MMC
    "0", where partition "1" contains the EXT4 filesystem, the following
    configs should be added to the board's default config:

    CONFIG_ENV_IS_IN_EXT4=y
    CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
    CONFIG_ENV_EXT4_FILE="/uboot.env"
    CONFIG_ENV_EXT4_INTERFACE="mmc"

    Signed-off-by: Jorge Ramirez-Ortiz
    [trini: Fix some line over 80 chars issues]
    Signed-off-by: Tom Rini

    Jorge Ramirez-Ortiz
     

18 Dec, 2017

1 commit

  • This commit adds ENV_SIZE and ENV_OFFSET configuration items for
    ARCH_ROCKCHIP, but keeps these non-visible (i.e. not prompt is given).
    With these new items present, the configuration from the header files
    is moved to Kconfig.

    Keeping these non-visible is necessary to have the possibility to
    select new default values if CONFIG_IS_IN_* is changed (interactively
    or with oldconfig). Otherwise it will always be set to a previous
    value if used with a prompt. As an example if we do a defconfig with
    CONFIG_IS_IN_MMC and change it to CONFIG_IS_IN_SPI_FLASH via
    menuconfig, ENV_SIZE and ENV_OFFSET will not be changed to the correct
    values as defconfig will already have set them to the default values
    of CONFIG_IS_IN_MMC in .config.

    Signed-off-by: Klaus Goger
    Reviewed-by: Philipp Tomsich

    Klaus Goger
     

30 Nov, 2017

1 commit

  • GCC 7.1 seems to be smart enough to track val through the various
    static inline functions, but not smart enough to see that val will
    always be initialised when no error is returned. This triggers
    the following warning:
    env/mmc.c: In function 'mmc_get_env_addr':
    env/mmc.c:121:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]

    To make it easier for compiler to understand what is going on, let's
    initialise val.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     

21 Nov, 2017

1 commit


17 Nov, 2017

1 commit


27 Oct, 2017

1 commit


16 Oct, 2017

1 commit


15 Oct, 2017

1 commit


04 Oct, 2017

1 commit

  • U-Boot widely uses error() as a bit noisier variant of printf().

    This macro causes name conflict with the following line in
    include/linux/compiler-gcc.h:

    # define __compiletime_error(message) __attribute__((error(message)))

    This prevents us from using __compiletime_error(), and makes it
    difficult to fully sync BUILD_BUG macros with Linux. (Notice
    Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)

    Let's convert error() into now treewide-available pr_err().

    Done with the help of Coccinelle, excluing tools/ directory.

    The semantic patch I used is as follows:

    //
    @@@@
    -error
    +pr_err
    (...)
    //

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Simon Glass
    [trini: Re-run Coccinelle]
    Signed-off-by: Tom Rini

    Masahiro Yamada
     

09 Sep, 2017

1 commit

  • The underlying implementation for ENV_AES has security complications and
    is not recommended for use. Please see CVE-2017-3225 and CVE-2017-3226
    for more details. Mark this as deprecated now and delete this in the
    medium term if no one comes forward to re-work the support.

    Signed-off-by: Tom Rini

    Tom Rini