env_mmc: support overriding mmc dev from board code

PATCH In review Clemens Gruber 4 participants 9 messages Jan 20, 2016 – Jan 26, 2016

Share & tools

Clemens Gruber

author

2016-01-20 14:43 UTC #0 lore raw

PATCH 1/1 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 <[email protected]>

Cc Stephen Warren <[email protected]>

Cc Tim Harvey <[email protected]>

Cc Simon Glass <[email protected]>

Cc Hans de Goede <[email protected]>

Signed-off-by Clemens Gruber <[email protected]>

---
 common/env_mmc.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

common/env_mmc.c +12 -7

index 15aa43d..bdb452e 100644
@@ -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

Signature · 1 line

2.7.0

Stephen Warren

2016-01-20 16:57 UTC #1 lore raw

PATCH 1/1 env_mmc: support overriding mmc dev from board code

Quoted 10 lines · Clemens Gruber

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 <[email protected]>

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:-)

Tom Rini

2016-01-21 19:10 UTC #2 lore raw

PATCH 1/1 env_mmc: support overriding mmc dev from board code

In reply to Clemens Gruber

Quoted 11 lines · Clemens Gruber

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.

Quoted 8 lines

Cc Tom Rini <[email protected]>
Cc Stephen Warren <[email protected]>
Cc Tim Harvey <[email protected]>
Cc Simon Glass <[email protected]>
Cc Hans de Goede <[email protected]>
Signed-off-by Clemens Gruber <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160121/cfbff8ac/attachment.sig>

Tom Rini

2016-01-25 21:28 UTC #3 lore raw

In reply to Clemens Gruber

Quoted 17 lines · Clemens Gruber

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 <[email protected]>
Cc Stephen Warren <[email protected]>
Cc Tim Harvey <[email protected]>
Cc Simon Glass <[email protected]>
Cc Hans de Goede <[email protected]>

Quoted 3 lines

Signed-off-by Clemens Gruber <[email protected]>
Reviewed-by Stephen Warren <[email protected]>
Reviewed-by Tom Rini <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160125/d523c869/attachment.sig>

Peng Fan

2016-01-26 01:42 UTC #4 lore raw

Quoted 19 lines · Tom Rini

Quoted 17 lines · Clemens Gruber
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 <[email protected]>
Cc Stephen Warren <[email protected]>
Cc Tim Harvey <[email protected]>
Cc Simon Glass <[email protected]>
Cc Hans de Goede <[email protected]>

Quoted 5 lines

Quoted 3 lines
Signed-off-by Clemens Gruber <[email protected]>
Reviewed-by Stephen Warren <[email protected]>
Reviewed-by Tom Rini <[email protected]>
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.

Quoted 10 lines

Signature · 9 lines

-- 
Tom



_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Tom Rini

2016-01-26 02:13 UTC #5 lore raw

Quoted 20 lines · Peng Fan

Quoted 19 lines · Tom Rini
Quoted 17 lines · Clemens Gruber
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 <[email protected]>
Cc Stephen Warren <[email protected]>
Cc Tim Harvey <[email protected]>
Cc Simon Glass <[email protected]>
Cc Hans de Goede <[email protected]>

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
Signed-off-by Clemens Gruber <[email protected]>
Reviewed-by Stephen Warren <[email protected]>
Reviewed-by Tom Rini <[email protected]>
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.

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160125/055992a7/attachment.sig>

Peng Fan

2016-01-26 02:53 UTC #6 lore raw

Quoted 25 lines · Tom Rini

Quoted 24 lines · Peng Fan
Quoted 23 lines · Tom Rini
Quoted 20 lines · Clemens Gruber
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 <[email protected]>
Cc Stephen Warren <[email protected]>
Cc Tim Harvey <[email protected]>
Cc Simon Glass <[email protected]>
Cc Hans de Goede <[email protected]>
Signed-off-by Clemens Gruber <[email protected]>
Reviewed-by Stephen Warren <[email protected]>
Reviewed-by Tom Rini <[email protected]>

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
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.

Quoted 3 lines

Signature · 2 lines
-- 
Tom

Clemens Gruber

author

2016-01-26 09:52 UTC #7 lore raw

Quoted 8 lines · Peng Fan

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

Tom Rini

2016-01-26 15:00 UTC #8 lore raw

Quoted 14 lines · Clemens Gruber

Quoted 8 lines · Peng Fan
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.

Quoted 8 lines

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!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160126/eb1cad5c/attachment.sig>