1. 12 Jul, 2019 1 commit
  2. 09 Jul, 2019 3 commits
  3. 13 Jun, 2019 1 commit
  4. 06 Jun, 2019 2 commits
  5. 23 May, 2019 2 commits
  6. 10 May, 2019 1 commit
  7. 12 Apr, 2019 1 commit
    • Martyn Welch's avatar
      env: Don't check CONFIG_ENV_OFFSET_REDUND for SPL build · f2fae512
      Martyn Welch authored
      When booting using an SPL on am335x, if we want to support booting with
      the boot ROM loader via USB (which uses RNDIS, making bootp and tftp
      calls) we need to enable gadget eth in the SPL to load the main U-Boot
      image. To enable CONFIG_SPL_ETH_SUPPORT, we must enable
      CONFIG_SPL_ENV_SUPPORT as the environment is used by the eth support, but
      we don't actually need to have environment variables saved in the SPL
      environment. We do however have environment variables saved in the main
      U-Boot image and enable CONFIG_ENV_OFFSET_REDUND (we are storing in raw
      NAND). In such instances, even with the build config enabling both
      CONFIG_CMD_SAVEENV and CONFIG_CMD_NAND, these options aren't set when
      building the SPL, but CONFIG_ENV_OFFSET_REDUND still is.
      Don't check this configuration option for SPL builds to enable the above
      Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
  8. 10 Apr, 2019 1 commit
    • Jean-Jacques Hiblot's avatar
      fs: ext4: Add support for the creation of symbolic links · 5efc0686
      Jean-Jacques Hiblot authored
      Re-use the functions used to write/create a file, to support creation of a
      symbolic link.
      The difference with a regular file are small:
      - The inode mode is flagged with S_IFLNK instead of S_IFREG
      - The ext2_dirent's filetype is FILETYPE_SYMLINK instead of FILETYPE_REG
      - Instead of storing the content of a file in allocated blocks, the path
      to the target is stored. And if the target's path is short enough, no block
      is allocated and the target's path is stored in ext2_inode.b.symlink
      As with regulars files, if a file/symlink with the same name exits, it is
      unlinked first and then re-created.
      Signed-off-by: default avatarJean-Jacques Hiblot <jjhiblot@ti.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      [trini: Fix ext4 env code]
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
  9. 25 Mar, 2019 1 commit
  10. 14 Mar, 2019 1 commit
    • Heiko Schocher's avatar
      Revert "env: add spi_flash_read_env function" · 9ba5e5bc
      Heiko Schocher authored
      This reverts commit 9a9d66f5.
      because it breaks fw_setenv and U-Boot interworking, if
      U-Boot environment is stored in a SPI-NOR.
      Reproduce it with:
      boot linux with empty Environment and store a variable
      with fw_setenv into it, the Environment is now filled
      with 0xff:
      root@ckey5e:10:8e:~# hexdump -C /dev/mtd4
      00000000  e9 e8 07 fa 01 62 6f 6f  74 63 6d 64 3d 72 75 6e  |.....bootcmd=run|
      00000f30  7d 00 75 62 69 62 6f 6f  74 76 6f 6c 3d 32 00 00  |}.ubibootvol=2..|
      00000f40  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
      Boot now U-Boot prints:
      Loading Environment from SPI Flash... SF: Detected s25fl128l with page size 256 Bytes, erase size 4 KiB, total 16 MiB
      *** Warning - bad CRC, using default environment
      Reason is the above commit, as it only reads until \0\0
      is found, and assumes the rest of the Environment
      space is filled with 0x00, which is not the case when
      saving an Environment under linux with fw_setenv.
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Acked-by: default avatarStefano Babic <sbabic@denx.de>
  11. 26 Jan, 2019 2 commits
    • Sam Protsenko's avatar
      env: Fix saving environment to "bad CRC" location · 293a172b
      Sam Protsenko authored
      In case when the environment on some location is malformed (CRC isn't
      matching), there is a chance we won't be able to save the environment to
      that location. For example, consider the case when we only have the
      environment on eMMC, but it's zeroed out. In that case, we won't be able
      to "env save" to it, because of "bad CRC" error. That's happening
      because in env_load() function we consider malformed environment as
      incorrect one, and  defaulting to the location with highest (0)
      priority, which can be different from one we are dealing with right now
      (e.g., highest priority can be ENV_FAT on SD card, which is not
      inserted, but we want to use ENV_MMC on eMMC, where we were booted
      This issue began to reproduce after commit d30ba231 ("u-boot: remove
      driver lookup loop from env_save()") on BeagleBone Black, but that
      commit didn't introduce the wrong logic, it just changed the behavior
      for default location to use, merely revealing this issue.
      To fix that, let's implement next logic in env_load():
        1. Try to find out correct environment; if found -- use it
        2. If working environment wasn't found, but we found malformed one
           (with bad CRC), let's use it for further "env save". But make sure
           to use malformed environment location with highest priority.
        3. If neither correct nor malformed environment was found, let's
           default to environment location with highest priority (0)
      Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
      1. Boot from SD card and erase eMMC in U-Boot shell:
         => mmc dev 1
         => mmc erase 0 100000
         => gpt write mmc 1 $partitions
      2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
         with zeroes
      3. Boot from eMMC; try to do:
         => env save
      4. Observe the error (incorrect behavior). Correct behavior: environment
         should be stored correctly on eMMC, in spite of it has "bad CRC"
      Fixes: d30ba231 ("u-boot: remove driver lookup loop from env_save()")
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Reviewed-by: default avatarSimon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
    • Sam Protsenko's avatar
      env: common: Return specific error code on bad CRC · 49d04c58
      Sam Protsenko authored
      Callers of env_import*() functions might want to check the case when we
      have incorrect environment (with bad CRC). For example, when environment
      location is being defined in env_load(), call chain may look like this:
          env_load() -> drv->load() = env_mmc_load() -> env_import()
      Return code will be passed from env_import() all way up to env_load().
      Right now both env_mmc_load() and env_import() return -EIO error code,
      so env_load() can't differentiate between two cases:
        1. Driver reports the error, because device is not accessible
        2. Device is actually accessible, but environment is broken
      Let's return -ENOMSG in env_import(), so we can distinguish two cases
      mentioned above. It will make it possible to continue working with "bad
      CRC" environment (like doing "env save"), instead of considering it not
      functional (implemented in subsequent patch).
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Reviewed-by: default avatarSimon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
  12. 25 Jan, 2019 1 commit
  13. 21 Jan, 2019 1 commit
  14. 18 Jan, 2019 1 commit
  15. 16 Jan, 2019 1 commit
    • Horatiu Vultur's avatar
      env: add spi_flash_read_env function · 9a9d66f5
      Horatiu Vultur authored
      The spi_flash_read_env function is a wrapper over spi_flash_read, which
      enables the env to read multiple flash page size from flash until '\0\0'
      is read or the end of env partition is reached. Instead of reading the
      entire env size. When it reads '\0\0', it stops reading further the env
      and assumes that the rest of env is '\0'.
      This is an optimization for large environments that contain few bytes
      environment variables. In this case it doesn't need to read the entire
      environment and only few pages.
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
  16. 15 Jan, 2019 1 commit
  17. 09 Jan, 2019 2 commits
  18. 04 Dec, 2018 2 commits
  19. 16 Oct, 2018 1 commit
    • Michal Simek's avatar
      arm64: versal: Add support for new Xilinx Versal ACAPs · ec48b6c9
      Michal Simek authored
      Xilinx is introducing Versal, an adaptive compute acceleration platform
      (ACAP), built on 7nm FinFET process technology. Versal ACAPs combine
      Scalar Processing Engines, Adaptable Hardware Engines, and Intelligent
      Engines with leading-edge memory and interfacing technologies to deliver
      powerful heterogeneous acceleration for any application. The Versal AI
      Core series has five devices, offering 128 to 400 AI Engines. The series
      includes dual-core Arm Cortex-A72 application processors, dual-core Arm
      Cortex-R5 real-time processors, 256KB of on-chip memory with ECC, more
      than 1,900 DSP engines optimized for high-precision floating point with
      low latency.
      The patch is adding necessary infrastructure in place without enabling
      platform which is done in separate patch.
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
  20. 19 Sep, 2018 1 commit
    • Konstantin Porotchkin's avatar
      fix: env: Fix the SPI flash device setup for DM mode · 25a17652
      Konstantin Porotchkin authored
      For some reason the spi_flash_probe_bus_cs() is called
      inside the setup_flash_device() with zero values in place
      of configurated SPI flash mode and maximum flash speed.
      This code causes HALT error during startup environment
      relocation on some platforms - namely Armada-38x-GP board.
      Fix the function call by replacing zeros with the appropriate
      Signed-off-by: default avatarKonstantin Porotchkin <kostap@marvell.com>
      Cc: Igal Liberman <igall@marvell.com>
      Cc: Stefan Roese <sr@denx.de>
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
  21. 24 Aug, 2018 1 commit
  22. 19 Aug, 2018 1 commit
  23. 10 Aug, 2018 1 commit
    • Sam Protsenko's avatar
      env: Don't show "Failed" error message · 13bbfb4a
      Sam Protsenko authored
      "Failed" error message from env_load() only clutters the log with
      unnecessary details, as we already have all needed warnings by that
      time. Example:
          Loading Environment from FAT... MMC: no card present
          ** Bad device mmc 0 **
          Failed (-5)
      Let's only print it in case when DEBUG is defined to keep log clear.
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
  24. 30 Jul, 2018 1 commit
  25. 21 Jul, 2018 2 commits
  26. 20 Jul, 2018 1 commit
  27. 19 Jul, 2018 4 commits
    • Yaniv Levinsky's avatar
      env: common: accept flags on reset to default env · c5d548a9
      Yaniv Levinsky authored
      The function set_default_env() sets the hashtable flags for import_r().
      Formally set_default_env() doesn't accept flags from its callers. In
      practice the caller can (un)set the H_INTERACTIVE flag, but it has to be
      done using the first character of the function's string argument. Other
      flags like H_FORCE can't be set by the caller.
      Change the function to accept flags argument. The benefits are:
      1. The caller will have to explicitly set the H_INTERACTIVE flag,
         instead of un-setting it using a special char in a string.
      2. Add the ability to propagate flags from the caller to himport(),
         especially the H_FORCE flag from do_env_default() in nvedit.c that
         currently gets ignored for "env default -a -f" commands.
      3. Flags and messages will not be coupled together. A caller will be
         able to set flags without passing a string and vice versa.
      Please note:
      The propagation of H_FORCE from do_env_default() does not introduce any
      functional changes, because currently himport_r() is set to destroy the
      old environment regardless if H_FORCE flag is set or not. More changes
      are needed to utilize the propagation of H_FORCE.
      Signed-off-by: default avatarYaniv Levinsky <yaniv.levinsky@compulab.co.il>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
    • Yaniv Levinsky's avatar
      cmd: nvedit: set H_INTERACTIVE in do_env_default · 5a04264e
      Yaniv Levinsky authored
      The function set_default_vars() in common.c adds H_INTERACTIVE to the
      h_import() flag, but the function has no way of telling if the command
      actually was user directed like this flag suggest. The flag should be
      set by the calling function do_env_default() in nvedit.c instead, where
      the command is certainty user directed.
      Move the H_INTERACTIVE flag from set_default_vars() to do_env_default().
      Signed-off-by: default avatarYaniv Levinsky <yaniv.levinsky@compulab.co.il>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
    • Yaniv Levinsky's avatar
      cmd: nvedit: propagate envflag to set_default_vars · 477f8116
      Yaniv Levinsky authored
      The env_flag in do_env_default() doesn't get propagated and therefore
      gets ignored by himport_r(). This breaks to ability to "forcibly" reset
      variables to their default values using the environment command.
      Scenario example of the problem:
      	# setenv kernel uImage
      	# setenv .flags kernel:so
      	# env default -f kernel
      	## Error: Can't overwrite "kernel"
      	himport_r: can't insert "kernel=zImage" into hash table
      Change the call path so it will pass the flag correctly.
      Signed-off-by: default avatarYaniv Levinsky <yaniv.levinsky@compulab.co.il>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
    • Vipul Kumar's avatar
      env: Added support to save env to spi through Kconfig · 2a30809c
      Vipul Kumar authored
      This patch added support to enable CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET
      and CONFIG_ENV_SECT_SIZE through Kconfig for Zynq and Zynqmp.
      Signed-off-by: default avatarVipul Kumar <vipul.kumar@xilinx.com>
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
  28. 13 Jun, 2018 2 commits