u-boot.git/env, branch v2024.10 Unnamed repository; edit this file 'description' to name the repository. ubi: allow to write to volume with offset 2024-08-08T07:27:58+00:00 Alexey Romanov avromanov@salutedevices.com 2024-07-18T05:45:24+00:00 25ee9c2005958e6f06609eef5c9d9915c77ece97 Introduce ubi_volume_offset_write() helper, which allow to write to ubi volume with specified offset. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Heiko Schocher <hs@denx.de> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> 
Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
ubi: allow to read from volume with offset 2024-08-08T07:27:55+00:00 Alexey Romanov avromanov@salutedevices.com 2024-07-18T05:45:23+00:00 cead69c528d4f107288717aeca6af52d0d9d47e9 Now user can pass an additional parameter 'offset' to ubi_volume_read() function. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Heiko Schocher <hs@denx.de> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> 
Now user can pass an additional parameter 'offset'
to ubi_volume_read() function.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
env_spi: support overriding spi dev from board code 2024-08-05T14:10:36+00:00 Venkatesh Yadav Abbarapu venkatesh.abbarapu@amd.com 2024-06-14T12:48:10+00:00 7d84ad1da0e32f4525cee9b35bc5a4f3b5585ed8 This enables boards to choose where to/from the environment should be saved/loaded. They can then for example support using the same device (dynamically) from which the bootloader was launched to load and save env data and do not have to define CONFIG_ENV_SPI_BUS statically. In my use case, the environment needs to be on the same device I booted from. It can be the QSPI or OSPI device. I therefore would override spi_get_env_dev in the board code, read the bootmode registers to determine where we booted from and return the corresponding device index. Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Link: https://lore.kernel.org/r/20240614124811.22945-2-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> # Move spi_get_env_dev to sf.c 
This enables boards to choose where to/from the environment
should be saved/loaded. They can then for example support using
the same device (dynamically) from which the bootloader was
launched to load and save env data and do not have to
define CONFIG_ENV_SPI_BUS statically.

In my use case, the environment needs to be on the same device I
booted from. It can be the QSPI or OSPI device.
I therefore would override spi_get_env_dev in the board code,
read the bootmode registers to determine where we booted from
and return the corresponding device index.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20240614124811.22945-2-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com> # Move spi_get_env_dev to sf.c
env: mmc: Fix env loading with CONFIG_SYS_MMC_ENV_PART 2024-07-31T17:19:20+00:00 Mattijs Korpershoek mkorpershoek@baylibre.com 2024-07-19T15:38:54+00:00 b2345dbdaa864b71cd58bd20b1b9e8440de639c7 When CONFIG_SYS_MMC_ENV_PART=2, the environment is loaded from the USER partition (hwpart=0) instead of from the BOOT1 partition (hwpart=2). IS_ENABLED() cannot be used for non-boolean KConfig options. Its documentation states: > * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y', > * 0 otherwise. So in our case, IS_ENABLED(CONFIG_SYS_MMC_ENV_PART) evaluates to 0. Because of this, the hwpart variable is never assigned and mmc_offset() ends up switching back to the USER hwpart (0) instead of BOOT1 (2). Fix it by using #define instead. Tested with: # have CONFIG_SYS_MMC_ENV_PART=2 in defconfig # 1. Erase mmc0boot1 => mmc dev 0 2 => mmc erase 0 400 => mmc read ${loadaddr} 0 400 => md ${loadaddr} 4 82000000: 00000000 00000000 00000000 00000000 ................ # 2. Restore default environment and save to MMC => env default -a -f => saveenv # 3. Read back mmc0boot1 and confirm the env is present => mmc read ${loadaddr} 0 400 => md ${loadaddr} 4 82000000: 13e0632e 72646461 7469665f 3978303d .c..addr_fit=0x9 Fixes: 5b4acb0ff79d ("env: mmc: Apply GPT only on eMMC user HW partition") Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
When CONFIG_SYS_MMC_ENV_PART=2, the environment is loaded from
the USER partition (hwpart=0) instead of from the
BOOT1 partition (hwpart=2).

IS_ENABLED() cannot be used for non-boolean KConfig options.
Its documentation states:

> * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y',
> * 0 otherwise.

So in our case, IS_ENABLED(CONFIG_SYS_MMC_ENV_PART) evaluates to 0.

Because of this, the hwpart variable is never assigned and mmc_offset()
ends up switching back to the USER hwpart (0) instead of BOOT1 (2).

Fix it by using #define instead.

Tested with:

  # have CONFIG_SYS_MMC_ENV_PART=2 in defconfig
  # 1. Erase mmc0boot1
  => mmc dev 0 2
  => mmc erase 0 400
  => mmc read ${loadaddr} 0 400
  => md ${loadaddr} 4
  82000000: 00000000 00000000 00000000 00000000  ................

  # 2. Restore default environment and save to MMC
  => env default -a -f
  => saveenv

  # 3. Read back mmc0boot1 and confirm the env is present
  => mmc read ${loadaddr} 0 400
  => md ${loadaddr} 4
  82000000: 13e0632e 72646461 7469665f 3978303d  .c..addr_fit=0x9

Fixes: 5b4acb0ff79d ("env: mmc: Apply GPT only on eMMC user HW partition")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Merge patch series "api: Remove duplicate newlines" 2024-07-15T18:28:22+00:00 Tom Rini trini@konsulko.com 2024-07-15T18:28:22+00:00 af3c2166d54cdb71914baece900095bad5a44862 This removes a number of duplicate newlines throughout the codebase. 
This removes a number of duplicate newlines throughout the codebase.
env: Remove duplicate newlines 2024-07-15T18:12:17+00:00 Marek Vasut marek.vasut+renesas@mailbox.org 2024-07-13T13:19:19+00:00 d9db7a847546720b7b0879baf3c2ecc85dc1c5ec Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> 
Drop all duplicate newlines. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
env: ENV_IS_IN_EXT4 should enable SYS_MMC_ENV_DEV 2024-07-14T07:56:24+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2024-03-31T02:37:16+00:00 5913c29fcbce9575fd6f6c1a45a019c733aca539 When enabling CONFIG_ENV_IS_IN_EXT4 the environment might be stored on an mmc device similar to the CONFIG_ENV_IS_IN_FAT case. Fixes: 7d080773347c ("Convert CONFIG_SYS_MMC_ENV_DEV et al to Kconfig") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
When enabling CONFIG_ENV_IS_IN_EXT4 the environment might be stored on
an mmc device similar to the CONFIG_ENV_IS_IN_FAT case.

Fixes: 7d080773347c ("Convert CONFIG_SYS_MMC_ENV_DEV et al to Kconfig")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
arm64: versal2: Add support for AMD Versal Gen 2 2024-06-17T14:02:29+00:00 Michal Simek michal.simek@amd.com 2024-05-29T14:47:58+00:00 40f5046c221a7b2719c49b51acefe12914b213e5 Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2 cpu core each. A lot of IPs are shared with previous families. There are couple of new IP blocks where the most interesting from user point of view is UFS. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/bc2b70831ce1031bd0fac32357bff84936e1310f.1716994063.git.michal.simek@amd.com 
Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2
cpu core each. A lot of IPs are shared with previous families. There are
couple of new IP blocks where the most interesting from user point of view
is UFS.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/bc2b70831ce1031bd0fac32357bff84936e1310f.1716994063.git.michal.simek@amd.com
Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet" 2024-05-20T19:35:03+00:00 Tom Rini trini@konsulko.com 2024-05-20T19:35:03+00:00 03de305ec48b0bb28554372abb40ccd46dbe0bf9 As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" 2024-05-19T14:16:36+00:00 Tom Rini trini@konsulko.com 2024-05-19T02:20:43+00:00 d678a59d2d719da9e807495b4b021501f2836ca5 When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>