[U-Boot] [PATCH] env_mmc: support overriding mmc dev from board code
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_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index.
Cc: Tom Rini trini@konsulko.com Cc: Stephen Warren swarren@nvidia.com Cc: Tim Harvey tharvey@gateworks.com Cc: Simon Glass sjg@chromium.org Cc: Hans de Goede hdegoede@redhat.com
Signed-off-by: Clemens Gruber clemens.gruber@pqgruber.com
--- common/env_mmc.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/common/env_mmc.c b/common/env_mmc.c index 15aa43d..bdb452e 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -54,6 +54,11 @@ __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr) return 0; }
+__weak int mmc_get_env_dev(void) +{ + return CONFIG_SYS_MMC_ENV_DEV; +} + int env_init(void) { /* use default */ @@ -74,7 +79,7 @@ static unsigned char env_mmc_orig_hwpart; static int mmc_set_env_part(struct mmc *mmc) { uint part = mmc_get_env_part(mmc); - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev(); int ret = 0;
#ifdef CONFIG_SPL_BUILD @@ -109,7 +114,7 @@ static const char *init_mmc_for_env(struct mmc *mmc) static void fini_mmc_for_env(struct mmc *mmc) { #ifdef CONFIG_SYS_MMC_ENV_PART - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev();
#ifdef CONFIG_SPL_BUILD dev = 0; @@ -140,7 +145,8 @@ static unsigned char env_flags; int saveenv(void) { ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1); - struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV); + int dev = mmc_get_env_dev(); + struct mmc *mmc = find_mmc_device(dev); u32 offset; int ret, copy = 0; const char *errmsg; @@ -167,8 +173,7 @@ int saveenv(void) goto fini; }
- printf("Writing to %sMMC(%d)... ", copy ? "redundant " : "", - CONFIG_SYS_MMC_ENV_DEV); + printf("Writing to %sMMC(%d)... ", copy ? "redundant " : "", dev); if (write_env(mmc, CONFIG_ENV_SIZE, offset, (u_char *)env_new)) { puts("failed\n"); ret = 1; @@ -212,7 +217,7 @@ void env_relocate_spec(void) int crc1_ok = 0, crc2_ok = 0; env_t *ep; int ret; - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev(); const char *errmsg = NULL;
ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env1, 1); @@ -298,7 +303,7 @@ void env_relocate_spec(void) struct mmc *mmc; u32 offset; int ret; - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev(); const char *errmsg;
#ifdef CONFIG_SPL_BUILD
On 01/20/2016 07:43 AM, Clemens Gruber wrote:
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_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index.
Reviewed-by: Stephen Warren swarren@nvidia.com
I was going to ask: What about the HW partition number and offset, but it appears that there is already a method to override those at run-time:-)
On Wed, Jan 20, 2016 at 03:43:37PM +0100, Clemens Gruber wrote:
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_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index.
Cc: Tom Rini trini@konsulko.com Cc: Stephen Warren swarren@nvidia.com Cc: Tim Harvey tharvey@gateworks.com Cc: Simon Glass sjg@chromium.org Cc: Hans de Goede hdegoede@redhat.com
Signed-off-by: Clemens Gruber clemens.gruber@pqgruber.com
Reviewed-by: Tom Rini trini@konsulko.com
On Wed, Jan 20, 2016 at 03:43:37PM +0100, Clemens Gruber wrote:
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_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index.
Cc: Tom Rini trini@konsulko.com Cc: Stephen Warren swarren@nvidia.com Cc: Tim Harvey tharvey@gateworks.com Cc: Simon Glass sjg@chromium.org Cc: Hans de Goede hdegoede@redhat.com
Signed-off-by: Clemens Gruber clemens.gruber@pqgruber.com Reviewed-by: Stephen Warren swarren@nvidia.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
On Mon, Jan 25, 2016 at 04:28:55PM -0500, Tom Rini wrote:
On Wed, Jan 20, 2016 at 03:43:37PM +0100, Clemens Gruber wrote:
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_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index.
Cc: Tom Rini trini@konsulko.com Cc: Stephen Warren swarren@nvidia.com Cc: Tim Harvey tharvey@gateworks.com Cc: Simon Glass sjg@chromium.org Cc: Hans de Goede hdegoede@redhat.com
Signed-off-by: Clemens Gruber clemens.gruber@pqgruber.com Reviewed-by: Stephen Warren swarren@nvidia.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Oh. I missed this patch. I have a more complete patch, still in patch work. https://patchwork.ozlabs.org/patch/558056/.
Regards, Peng.
-- Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Tue, Jan 26, 2016 at 09:42:38AM +0800, Peng Fan wrote:
On Mon, Jan 25, 2016 at 04:28:55PM -0500, Tom Rini wrote:
On Wed, Jan 20, 2016 at 03:43:37PM +0100, Clemens Gruber wrote:
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_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index.
Cc: Tom Rini trini@konsulko.com Cc: Stephen Warren swarren@nvidia.com Cc: Tim Harvey tharvey@gateworks.com Cc: Simon Glass sjg@chromium.org Cc: Hans de Goede hdegoede@redhat.com
Signed-off-by: Clemens Gruber clemens.gruber@pqgruber.com Reviewed-by: Stephen Warren swarren@nvidia.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Oh. I missed this patch. I have a more complete patch, still in patch work. https://patchwork.ozlabs.org/patch/558056/.
Bah. They look to cover the same areas to me at least.
On Mon, Jan 25, 2016 at 09:13:00PM -0500, Tom Rini wrote:
On Tue, Jan 26, 2016 at 09:42:38AM +0800, Peng Fan wrote:
On Mon, Jan 25, 2016 at 04:28:55PM -0500, Tom Rini wrote:
On Wed, Jan 20, 2016 at 03:43:37PM +0100, Clemens Gruber wrote:
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_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index.
Cc: Tom Rini trini@konsulko.com Cc: Stephen Warren swarren@nvidia.com Cc: Tim Harvey tharvey@gateworks.com Cc: Simon Glass sjg@chromium.org Cc: Hans de Goede hdegoede@redhat.com
Signed-off-by: Clemens Gruber clemens.gruber@pqgruber.com Reviewed-by: Stephen Warren swarren@nvidia.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Oh. I missed this patch. I have a more complete patch, still in patch work. https://patchwork.ozlabs.org/patch/558056/.
Bah. They look to cover the same areas to me at least.
Yeah. The patch I wrote include fix write_env, and a function prototype in header file.
If the current patch already applied, I can write a follow up patch.
Thanks, Peng.
-- Tom
On Tue, Jan 26, 2016 at 10:53:58AM +0800, Peng Fan wrote:
Yeah. The patch I wrote include fix write_env, and a function prototype in header file.
If the current patch already applied, I can write a follow up patch.
Thanks, Peng.
Hi Peng,
sorry, I did not know there was already a similar patch.
However, now when looking over your patch, it tries to fix read_env and write_env, which is not necessary, because the device number is stored in struct mmc.
What's missing though is the function prototype in the header.
Tom, should I send a v2 of the patch or a follow-up? Or do you want to fix this up, Peng?
Thanks. Clemens
On Tue, Jan 26, 2016 at 10:52:39AM +0100, Clemens Gruber wrote:
On Tue, Jan 26, 2016 at 10:53:58AM +0800, Peng Fan wrote:
Yeah. The patch I wrote include fix write_env, and a function prototype in header file.
If the current patch already applied, I can write a follow up patch.
Thanks, Peng.
Hi Peng,
sorry, I did not know there was already a similar patch.
However, now when looking over your patch, it tries to fix read_env and write_env, which is not necessary, because the device number is stored in struct mmc.
What's missing though is the function prototype in the header.
Tom, should I send a v2 of the patch or a follow-up? Or do you want to fix this up, Peng?
Ah, yes, a prototype would be good, go ahead and do it, thanks!
participants (4)
-
Clemens Gruber -
Peng Fan -
Stephen Warren -
Tom Rini