u-boot.git/env, branch v2019.07-rc4

env: solve compilation error in SPL

2019-05-23T09:36:48+00:00

Solve compilation issue when cli_simple.o is used in SPL
and CONFIG_SPL_ENV_SUPPORT is not defined.

env/built-in.o:(.data.env_htab+0xc): undefined reference to `env_flags_validate'
u-boot/scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed
make[2]: *** [spl/u-boot-spl] Error 1
u-boot/Makefile:1649: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2

Signed-off-by: Patrick Delaunay

stm32mp1: Move ENV_SIZE and ENV_OFFSET to Kconfig

2019-05-23T09:36:46+00:00

Add arch stm32mp for ENV migration step and drop more
items from include/configs/xxx.h.

Signed-off-by: Patrick Delaunay

env: spi: Fix incorrect entry description

2019-05-09T23:52:55+00:00

Fix the max frequency entry description, it's incorrect.

Signed-off-by: Marek Vasut 
Cc: Chris Brandt 
Cc: Jagan Teki 
Cc: Tom Rini

env: Don't check CONFIG_ENV_OFFSET_REDUND for SPL build

2019-04-12T12:05:48+00:00

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
configuration.

Signed-off-by: Martyn Welch 
Reviewed-by: Tom Rini

fs: ext4: Add support for the creation of symbolic links

2019-04-10T00:03:30+00:00

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: Jean-Jacques Hiblot 
Reviewed-by: Tom Rini 
[trini: Fix ext4 env code]
Signed-off-by: Tom Rini

Convert CONFIG_ENV_SPI_* to Kconfig

2019-03-25T21:36:59+00:00

This converts the following to Kconfig:
  CONFIG_ENV_SPI_BUS
  CONFIG_ENV_SPI_CS
  CONFIG_ENV_SPI_MAX_HZ
  CONFIG_ENV_SPI_MODE

Most of time these value are not needed, CONFIG_SF_DEFAULT
with same value is used, so I introduced CONFIG_USE_ENV_SPI_*
to force the associated value for the environment.

Signed-off-by: Patrick Delaunay

Revert "env: add spi_flash_read_env function"

2019-03-14T00:32:09+00:00

This reverts commit 9a9d66f5eff0f443de4c2c6ca3e27771ed14b1b4.

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: Heiko Schocher 
Acked-by: Stefano Babic

Merge branch '2019-01-25-master-imports'

2019-01-27T03:47:55+00:00

- snapdragon 820c improvements
- poplar updates
- DFU + SPL cleanups
- Improve the mediatek mmc driver
- Other minor cleanups / improvements

env: Fix saving environment to "bad CRC" location

2019-01-26T13:13:56+00:00

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
from).

This issue began to reproduce after commit d30ba2315ae3 ("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
patch):

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: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko 
Reviewed-by: Simon Goldschmidt

env: common: Return specific error code on bad CRC

2019-01-26T13:13:56+00:00

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: Sam Protsenko 
Reviewed-by: Simon Goldschmidt