| Message ID | 1453301017-6705-1-git-send-email-clemens.gruber@pqgruber.com |
|---|---|
| State | Accepted |
| Commit | e92029c0f4e88ae3e738d83b25ef2d3c178ea082 |
| Delegated to: | Tom Rini |
| Headers | show |
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!
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
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(-)