[U-Boot] [RFC 0/4] sunxi: Implement transition in environment

[U-Boot] [RFC 0/4] sunxi: Implement transition in environment

[Maxime Ripard]

Hi,

Here is an RFC to implement the transition from a raw environment in
the MMC to a FAT file in the first bootable partition.

This is based in a custom environment method that reuses the mmc and
fat codes as much as possible, and just deals with the fallbacks,
printing a warning when we're using the now legacy setup so that we
can warn our user of the future breakage.

This has just been compile tested, I'm mostly looking for feedback on
the appoach at this point.

Thanks!
Maxime

Maxime Ripard (4):
  env: Rework mmc environment ifdef
  env; fat: Allow the fat environment to be embedded by another one
  env: Create an environment transition method
  env: sunxi: Switch by default to the transition environment code

 cmd/nvedit.c                   |  1 +
 env/Kconfig                    | 14 +++++++---
 env/Makefile                   |  1 +
 env/fat.c                      | 12 +++++++--
 env/mmc.c                      | 24 +++++++++--------
 env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
 include/configs/sunxi-common.h |  2 +-
 include/environment.h          |  1 +
 8 files changed, 96 insertions(+), 18 deletions(-)
 create mode 100644 env/sunxi-transition.c

-- 
2.14.2

[U-Boot] [RFC 1/4] env: Rework mmc environment ifdef

[Maxime Ripard]

We want the MMC environment code to be compilable so that it can be used by
other environment methods, even if it's not the primary one.

Rework slightly the ifdef to do that.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 env/mmc.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/env/mmc.c b/env/mmc.c
index 3f3092d97560..ffbd1f7c0e59 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -143,7 +143,10 @@ static inline int write_env(struct mmc *mmc, unsigned long size,
 	return (n == blk_cnt) ? 0 : -1;
 }
 
-static int env_mmc_save(void)
+#ifdef CONFIG_ENV_IS_IN_MMC
+static
+#endif
+int env_mmc_save(void)
 {
 	ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
 	int dev = mmc_get_env_dev();
@@ -206,10 +209,13 @@ static inline int read_env(struct mmc *mmc, unsigned long size,
 	return (n == blk_cnt) ? 0 : -1;
 }
 
-#ifdef CONFIG_ENV_OFFSET_REDUND
-static int env_mmc_load(void)
+#ifdef CONFIG_ENV_IS_IN_MMC
+static
+#endif
+int env_mmc_load(void)
 {
 #if !defined(ENV_IS_EMBEDDED)
+#ifdef CONFIG_ENV_OFFSET_REDUND
 	struct mmc *mmc;
 	u32 offset1, offset2;
 	int read1_fail = 0, read2_fail = 0;
@@ -265,13 +271,7 @@ err:
 	if (ret)
 		set_default_env(errmsg);
 
-#endif
-	return ret;
-}
 #else /* ! CONFIG_ENV_OFFSET_REDUND */
-static int env_mmc_load(void)
-{
-#if !defined(ENV_IS_EMBEDDED)
 	ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE);
 	struct mmc *mmc;
 	u32 offset;
@@ -306,11 +306,12 @@ fini:
 err:
 	if (ret)
 		set_default_env(errmsg);
-#endif
+#endif /* CONFIG_ENV_OFFSET_REDUND */
+#endif /* ENV_IS_EMBEDDED */
 	return ret;
 }
-#endif /* CONFIG_ENV_OFFSET_REDUND */
 
+#ifdef CONFIG_ENV_IS_IN_MMC
 U_BOOT_ENV_LOCATION(mmc) = {
 	.location	= ENVL_MMC,
 	ENV_NAME("MMC")
@@ -319,3 +320,4 @@ U_BOOT_ENV_LOCATION(mmc) = {
 	.save		= env_save_ptr(env_mmc_save),
 #endif
 };
+#endif /* CONFIG_ENV_IS_IN_MMC */
-- 
2.14.2

[U-Boot] [RFC 2/4] env; fat: Allow the fat environment to be embedded by another one

[Maxime Ripard]

The fat environment is currently only buildable as the primary environment,
but other environment methods might need to use it as a secondary
environment (for example to implement fallback mechanisms).

Make sure the environment can be compiled and that the functions are not
static when the configuration option is not enabled, and that we will
register it only when it is our primary environment method.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 env/fat.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/env/fat.c b/env/fat.c
index ec49c3905369..acdea664dd2c 100644
--- a/env/fat.c
+++ b/env/fat.c
@@ -34,7 +34,10 @@
 DECLARE_GLOBAL_DATA_PTR;
 
 #ifdef CMD_SAVEENV
-static int env_fat_save(void)
+#ifdef CONFIG_ENV_IS_IN_FAT
+static
+#endif
+int env_fat_save(void)
 {
 	env_t	env_new;
 	struct blk_desc *dev_desc = NULL;
@@ -74,7 +77,10 @@ static int env_fat_save(void)
 #endif /* CMD_SAVEENV */
 
 #ifdef LOADENV
-static int env_fat_load(void)
+#ifdef CONFIG_ENV_IS_IN_FAT
+static
+#endif
+int env_fat_load(void)
 {
 	ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE);
 	struct blk_desc *dev_desc = NULL;
@@ -112,6 +118,7 @@ err_env_relocate:
 }
 #endif /* LOADENV */
 
+#ifdef CONFIG_ENV_IS_IN_FAT
 U_BOOT_ENV_LOCATION(fat) = {
 	.location	= ENVL_FAT,
 	ENV_NAME("FAT")
@@ -122,3 +129,4 @@ U_BOOT_ENV_LOCATION(fat) = {
 	.save		= env_save_ptr(env_fat_save),
 #endif
 };
+#endif
-- 
2.14.2

[U-Boot] [RFC 3/4] env: Create an environment transition method

[Maxime Ripard]

The current environment has been hardcoded to an offset that starts to be
an issue given the current size of our main U-Boot binary.

Introduce an environment method from storing the environment raw in the MMC
to a file in a FAT partition. Eventually, and hopefully before we reach
that limit again, we will have most of our users using that setup, and
we'll be able to retire the raw environment, and gain more room for the
U-Boot binary.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 cmd/nvedit.c                   |  1 +
 env/Kconfig                    | 12 ++++++---
 env/Makefile                   |  1 +
 env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
 include/configs/sunxi-common.h |  2 +-
 include/environment.h          |  1 +
 6 files changed, 72 insertions(+), 4 deletions(-)
 create mode 100644 env/sunxi-transition.c

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 4e79d03856fe..7b89ee428859 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -52,6 +52,7 @@ DECLARE_GLOBAL_DATA_PTR;
 	!defined(CONFIG_ENV_IS_IN_SPI_FLASH)	&& \
 	!defined(CONFIG_ENV_IS_IN_REMOTE)	&& \
 	!defined(CONFIG_ENV_IS_IN_UBI)		&& \
+	!defined(CONFIG_ENV_IS_SUNXI_TRANSITION)	&& \
 	!defined(CONFIG_ENV_IS_NOWHERE)
 # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|MMC|FAT|EXT4|\
 NAND|NVRAM|ONENAND|SATA|SPI_FLASH|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
diff --git a/env/Kconfig b/env/Kconfig
index 02cb7cbb751d..fdd68fdfbdb6 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -30,6 +30,9 @@ choice
 	  partition on the device) or a filesystem (where the environment
 	  information is written to a file).
 
+config ENV_IS_SUNXI_TRANSITION
+	bool "Environment transition for Allwinner SoCs"
+
 config ENV_IS_NOWHERE
 	bool "Environment is not stored"
 	help
@@ -369,17 +372,20 @@ config ENV_AES
 
 config ENV_FAT_INTERFACE
 	string "Name of the block device for the environment"
-	depends on ENV_IS_IN_FAT
+	depends on ENV_IS_IN_FAT || ENV_IS_SUNXI_TRANSITION
 	default "mmc" if TI_COMMON_CMD_OPTIONS || ARCH_ZYNQMP || ARCH_AT91
+	default "mmc" if ARCH_SUNXI
 	help
 	  Define this to a string that is the name of the block device.
 
 config ENV_FAT_DEVICE_AND_PART
 	string "Device and partition for where to store the environemt in FAT"
-	depends on ENV_IS_IN_FAT
+	depends on ENV_IS_IN_FAT || ENV_IS_SUNXI_TRANSITION
 	default "0:1" if TI_COMMON_CMD_OPTIONS
 	default "0:auto" if ARCH_ZYNQMP
 	default "0" if ARCH_AT91
+	default "0:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1
+	default "1:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1
 	help
 	  Define this to a string to specify the partition of the device. It can
 	  be as following:
@@ -397,7 +403,7 @@ config ENV_FAT_DEVICE_AND_PART
 
 config ENV_FAT_FILE
 	string "Name of the FAT file to use for the environemnt"
-	depends on ENV_IS_IN_FAT
+	depends on ENV_IS_IN_FAT || ENV_IS_SUNXI_TRANSITION
 	default "uboot.env"
 	help
 	  It's a string of the FAT file name. This file use to store the
diff --git a/env/Makefile b/env/Makefile
index 7ce8231d9a70..09ad342e6161 100644
--- a/env/Makefile
+++ b/env/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_ENV_IS_IN_SPI_FLASH) += sf.o
 obj-$(CONFIG_ENV_IS_IN_REMOTE) += remote.o
 obj-$(CONFIG_ENV_IS_IN_UBI) += ubi.o
 obj-$(CONFIG_ENV_IS_NOWHERE) += nowhere.o
+obj-$(CONFIG_ENV_IS_SUNXI_TRANSITION) += fat.o mmc.o sunxi-transition.o
 endif
 
 ifdef CONFIG_SPL_BUILD
diff --git a/env/sunxi-transition.c b/env/sunxi-transition.c
new file mode 100644
index 000000000000..fae0603a897a
--- /dev/null
+++ b/env/sunxi-transition.c
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2017 Maxime Ripard
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+/* #define DEBUG */
+
+#include <common.h>
+#include <environment.h>
+
+int env_fat_load(void);
+int env_fat_save(void);
+
+int env_mmc_load(void);
+int env_mmc_save(void);
+
+static int env_sunxi_save(void)
+{
+	int ret;
+
+	ret = env_fat_save();
+	if (!ret) {
+		debug("Wrote env in FAT file\n");
+		return 0;
+	}
+
+	ret = env_mmc_save();
+	if (!ret)
+		printf("The env is raw, this will be broken in the future, please upgrade to file-based env\n");
+
+	return ret;
+}
+
+static int env_sunxi_load(void)
+{
+	int ret;
+
+	ret = env_fat_load();
+	if (!ret) {
+		debug("Found env in FAT partition, bailing out\n");
+		return 0;
+	}
+
+	ret = env_mmc_load();
+	if (!ret)
+		printf("The env is raw, this will be broken in the future, please upgrade to file-based env\n");
+
+	return ret;
+}
+
+U_BOOT_ENV_LOCATION(sunxi) = {
+	.location	= ENVL_SUNXI_TRANSITION,
+	ENV_NAME("SUNXI")
+	.load		= env_sunxi_load,
+#ifndef CONFIG_SPL_BUILD
+	.save		= env_save_ptr(env_sunxi_save),
+#endif
+};
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 91751171ec2b..c894131576e2 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -147,7 +147,7 @@
 #define CONFIG_MMC_SUNXI_SLOT		0
 #endif
 
-#if defined(CONFIG_ENV_IS_IN_MMC)
+#if defined(CONFIG_ENV_IS_IN_MMC) || defined (CONFIG_ENV_IS_SUNXI_TRANSITION)
 #if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
 /* If we have two devices (most likely eMMC + MMC), favour the eMMC */
 #define CONFIG_SYS_MMC_ENV_DEV		1
diff --git a/include/environment.h b/include/environment.h
index 7b9821638960..20c9cd13f11c 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -208,6 +208,7 @@ enum env_location {
 	ENVL_ONENAND,
 	ENVL_REMOTE,
 	ENVL_SPI_FLASH,
+	ENVL_SUNXI_TRANSITION,
 	ENVL_UBI,
 	ENVL_NOWHERE,
 
-- 
2.14.2

[U-Boot] [RFC 4/4] env: sunxi: Switch by default to the transition environment code

[Maxime Ripard]

Now that we have some code to smoothly transition from a raw environment to
a file, make that the default.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 env/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/env/Kconfig b/env/Kconfig
index fdd68fdfbdb6..95ab988552bb 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -2,7 +2,7 @@ menu "Environment"
 
 choice
 	prompt "Select the location of the environment"
-	default ENV_IS_IN_MMC if ARCH_SUNXI
+	default ENV_IS_SUNXI_TRANSITION if ARCH_SUNXI
 	default ENV_IS_IN_MMC if ARCH_EXYNOS4
 	default ENV_IS_IN_MMC if MX6SX || MX7D
 	default ENV_IS_IN_MMC if TEGRA30 || TEGRA124
-- 
2.14.2

[U-Boot] [RFC 3/4] env: Create an environment transition method

[Wolfgang Denk]

Dear Maxime,

In message <20171025122601.28224-4-maxime.ripard@free-electrons.com> you wrote:
> The current environment has been hardcoded to an offset that starts to be
> an issue given the current size of our main U-Boot binary.
> 
> Introduce an environment method from storing the environment raw in the MMC
> to a file in a FAT partition. Eventually, and hopefully before we reach
> that limit again, we will have most of our users using that setup, and
> we'll be able to retire the raw environment, and gain more room for the
> U-Boot binary.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  cmd/nvedit.c                   |  1 +
>  env/Kconfig                    | 12 ++++++---
>  env/Makefile                   |  1 +
>  env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
>  include/configs/sunxi-common.h |  2 +-
>  include/environment.h          |  1 +
>  6 files changed, 72 insertions(+), 4 deletions(-)
>  create mode 100644 env/sunxi-transition.c

I wonder why you need such a lot of code, and especiallay many
changes in global files for a feature which is probably of no use to
anybody else.

Can the same not be acchieved by a little scripting and clever use of
"env export", file write, and "env import" commands?

Such scripting would have a lot of benefits: no need to touch any
code (especially not global code), and you don't need a new
version of U-Boot to "fix" all existing systems.

I guess I must be missing some key requirement but I can't see it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot] [RFC 0/4] sunxi: Implement transition in environment

[Tom Rini]

On Wed, Oct 25, 2017 at 02:25:57PM +0200, Maxime Ripard wrote:
> Hi,
> 
> Here is an RFC to implement the transition from a raw environment in
> the MMC to a FAT file in the first bootable partition.
> 
> This is based in a custom environment method that reuses the mmc and
> fat codes as much as possible, and just deals with the fallbacks,
> printing a warning when we're using the now legacy setup so that we
> can warn our user of the future breakage.
> 
> This has just been compile tested, I'm mostly looking for feedback on
> the appoach at this point.
> 
> Thanks!
> Maxime
> 
> Maxime Ripard (4):
>   env: Rework mmc environment ifdef
>   env; fat: Allow the fat environment to be embedded by another one
>   env: Create an environment transition method
>   env: sunxi: Switch by default to the transition environment code
> 
>  cmd/nvedit.c                   |  1 +
>  env/Kconfig                    | 14 +++++++---
>  env/Makefile                   |  1 +
>  env/fat.c                      | 12 +++++++--
>  env/mmc.c                      | 24 +++++++++--------
>  env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
>  include/configs/sunxi-common.h |  2 +-
>  include/environment.h          |  1 +
>  8 files changed, 96 insertions(+), 18 deletions(-)
>  create mode 100644 env/sunxi-transition.c

So, it looks like a lot of what Simon did so that we could have more
than one environment type compiled in was a step in the right direction.
What we should be able to move forward on is being able to link in both
FAT and MMC and whatever is found work, along with a Kconfig choice for
what should be the default one, or some other way that's not just link
order to control that.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171025/13bae6b2/attachment.sig>

[U-Boot] [RFC 0/4] sunxi: Implement transition in environment

[Maxime Ripard]

Hi Tom,

Thanks for your feedback.

On Wed, Oct 25, 2017 at 11:32:03AM -0400, Tom Rini wrote:
> On Wed, Oct 25, 2017 at 02:25:57PM +0200, Maxime Ripard wrote:
> > Hi,
> > 
> > Here is an RFC to implement the transition from a raw environment in
> > the MMC to a FAT file in the first bootable partition.
> > 
> > This is based in a custom environment method that reuses the mmc and
> > fat codes as much as possible, and just deals with the fallbacks,
> > printing a warning when we're using the now legacy setup so that we
> > can warn our user of the future breakage.
> > 
> > This has just been compile tested, I'm mostly looking for feedback on
> > the appoach at this point.
> > 
> > Thanks!
> > Maxime
> > 
> > Maxime Ripard (4):
> >   env: Rework mmc environment ifdef
> >   env; fat: Allow the fat environment to be embedded by another one
> >   env: Create an environment transition method
> >   env: sunxi: Switch by default to the transition environment code
> > 
> >  cmd/nvedit.c                   |  1 +
> >  env/Kconfig                    | 14 +++++++---
> >  env/Makefile                   |  1 +
> >  env/fat.c                      | 12 +++++++--
> >  env/mmc.c                      | 24 +++++++++--------
> >  env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
> >  include/configs/sunxi-common.h |  2 +-
> >  include/environment.h          |  1 +
> >  8 files changed, 96 insertions(+), 18 deletions(-)
> >  create mode 100644 env/sunxi-transition.c
> 
> So, it looks like a lot of what Simon did so that we could have more
> than one environment type compiled in was a step in the right direction.
> What we should be able to move forward on is being able to link in both
> FAT and MMC and whatever is found work, along with a Kconfig choice for
> what should be the default one, or some other way that's not just link
> order to control that.

Yeah, I thought about that some more yesterday, and I guess having
multiple environments and a way for boards to change the ordering of
both load and store the environment.

Do you have a link to that serie from Simon?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171026/126bcf7f/attachment.sig>

[U-Boot] [RFC 0/4] sunxi: Implement transition in environment

[Tom Rini]

On Thu, Oct 26, 2017 at 10:38:45AM +0200, Maxime Ripard wrote:
> Hi Tom,
> 
> Thanks for your feedback.
> 
> On Wed, Oct 25, 2017 at 11:32:03AM -0400, Tom Rini wrote:
> > On Wed, Oct 25, 2017 at 02:25:57PM +0200, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > Here is an RFC to implement the transition from a raw environment in
> > > the MMC to a FAT file in the first bootable partition.
> > > 
> > > This is based in a custom environment method that reuses the mmc and
> > > fat codes as much as possible, and just deals with the fallbacks,
> > > printing a warning when we're using the now legacy setup so that we
> > > can warn our user of the future breakage.
> > > 
> > > This has just been compile tested, I'm mostly looking for feedback on
> > > the appoach at this point.
> > > 
> > > Thanks!
> > > Maxime
> > > 
> > > Maxime Ripard (4):
> > >   env: Rework mmc environment ifdef
> > >   env; fat: Allow the fat environment to be embedded by another one
> > >   env: Create an environment transition method
> > >   env: sunxi: Switch by default to the transition environment code
> > > 
> > >  cmd/nvedit.c                   |  1 +
> > >  env/Kconfig                    | 14 +++++++---
> > >  env/Makefile                   |  1 +
> > >  env/fat.c                      | 12 +++++++--
> > >  env/mmc.c                      | 24 +++++++++--------
> > >  env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
> > >  include/configs/sunxi-common.h |  2 +-
> > >  include/environment.h          |  1 +
> > >  8 files changed, 96 insertions(+), 18 deletions(-)
> > >  create mode 100644 env/sunxi-transition.c
> > 
> > So, it looks like a lot of what Simon did so that we could have more
> > than one environment type compiled in was a step in the right direction.
> > What we should be able to move forward on is being able to link in both
> > FAT and MMC and whatever is found work, along with a Kconfig choice for
> > what should be the default one, or some other way that's not just link
> > order to control that.
> 
> Yeah, I thought about that some more yesterday, and I guess having
> multiple environments and a way for boards to change the ordering of
> both load and store the environment.
> 
> Do you have a link to that serie from Simon?

I don't _think_ he got things to the point where multiple worked, but
that your series was rather small is due to the groundwork he did :)

To rephrase what I was saying, how much work would it be so that:
1) Both FAT and MMC can be compiled in, but it's still probably
link-order on what gets used
2) If first-attempted env isn't found, we gracefully try the next (and
so on).
3) We can at least control what env location is tried first.

And I'm setting aside the other problems of MMC location X vs MMC
location Y and try N different filesystems.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171026/1239d4ff/attachment.sig>

[U-Boot] [RFC 0/4] sunxi: Implement transition in environment

[Maxime Ripard]

Hi Tom,

On Thu, Oct 26, 2017 at 10:09:10AM -0400, Tom Rini wrote:
> On Thu, Oct 26, 2017 at 10:38:45AM +0200, Maxime Ripard wrote:
> > Hi Tom,
> > 
> > Thanks for your feedback.
> > 
> > On Wed, Oct 25, 2017 at 11:32:03AM -0400, Tom Rini wrote:
> > > On Wed, Oct 25, 2017 at 02:25:57PM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > > 
> > > > Here is an RFC to implement the transition from a raw environment in
> > > > the MMC to a FAT file in the first bootable partition.
> > > > 
> > > > This is based in a custom environment method that reuses the mmc and
> > > > fat codes as much as possible, and just deals with the fallbacks,
> > > > printing a warning when we're using the now legacy setup so that we
> > > > can warn our user of the future breakage.
> > > > 
> > > > This has just been compile tested, I'm mostly looking for feedback on
> > > > the appoach at this point.
> > > > 
> > > > Thanks!
> > > > Maxime
> > > > 
> > > > Maxime Ripard (4):
> > > >   env: Rework mmc environment ifdef
> > > >   env; fat: Allow the fat environment to be embedded by another one
> > > >   env: Create an environment transition method
> > > >   env: sunxi: Switch by default to the transition environment code
> > > > 
> > > >  cmd/nvedit.c                   |  1 +
> > > >  env/Kconfig                    | 14 +++++++---
> > > >  env/Makefile                   |  1 +
> > > >  env/fat.c                      | 12 +++++++--
> > > >  env/mmc.c                      | 24 +++++++++--------
> > > >  env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
> > > >  include/configs/sunxi-common.h |  2 +-
> > > >  include/environment.h          |  1 +
> > > >  8 files changed, 96 insertions(+), 18 deletions(-)
> > > >  create mode 100644 env/sunxi-transition.c
> > > 
> > > So, it looks like a lot of what Simon did so that we could have more
> > > than one environment type compiled in was a step in the right direction.
> > > What we should be able to move forward on is being able to link in both
> > > FAT and MMC and whatever is found work, along with a Kconfig choice for
> > > what should be the default one, or some other way that's not just link
> > > order to control that.
> > 
> > Yeah, I thought about that some more yesterday, and I guess having
> > multiple environments and a way for boards to change the ordering of
> > both load and store the environment.
> > 
> > Do you have a link to that serie from Simon?
> 
> I don't _think_ he got things to the point where multiple worked, but
> that your series was rather small is due to the groundwork he did :)

Oh, I see, sorry.

> To rephrase what I was saying, how much work would it be so that:
> 1) Both FAT and MMC can be compiled in, but it's still probably
> link-order on what gets used
> 2) If first-attempted env isn't found, we gracefully try the next (and
> so on).
> 3) We can at least control what env location is tried first.
> 
> And I'm setting aside the other problems of MMC location X vs MMC
> location Y and try N different filesystems.

That would work, I'll try to implement that.

Thanks for the suggestion!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171031/0aa0cdf0/attachment.sig>

[U-Boot] [RFC 3/4] env: Create an environment transition method

[Maxime Ripard]

Hi Wolfgang,

On Wed, Oct 25, 2017 at 05:26:46PM +0200, Wolfgang Denk wrote:
> Dear Maxime,
> 
> In message <20171025122601.28224-4-maxime.ripard@free-electrons.com> you wrote:
> > The current environment has been hardcoded to an offset that starts to be
> > an issue given the current size of our main U-Boot binary.
> > 
> > Introduce an environment method from storing the environment raw in the MMC
> > to a file in a FAT partition. Eventually, and hopefully before we reach
> > that limit again, we will have most of our users using that setup, and
> > we'll be able to retire the raw environment, and gain more room for the
> > U-Boot binary.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> >  cmd/nvedit.c                   |  1 +
> >  env/Kconfig                    | 12 ++++++---
> >  env/Makefile                   |  1 +
> >  env/sunxi-transition.c         | 59 ++++++++++++++++++++++++++++++++++++++++++
> >  include/configs/sunxi-common.h |  2 +-
> >  include/environment.h          |  1 +
> >  6 files changed, 72 insertions(+), 4 deletions(-)
> >  create mode 100644 env/sunxi-transition.c
> 
> I wonder why you need such a lot of code, and especiallay many
> changes in global files for a feature which is probably of no use to
> anybody else.
> 
> Can the same not be acchieved by a little scripting and clever use of
> "env export", file write, and "env import" commands?

I guess we'd need to compile support for multiple environments in this
case so that we can import from either the old (raw MMC) or the new
one (FS-based), and then save it to either of them.

> Such scripting would have a lot of benefits: no need to touch any
> code (especially not global code), and you don't need a new
> version of U-Boot to "fix" all existing systems.
> 
> I guess I must be missing some key requirement but I can't see it?

One thing I'd really like would be to make it as smooth and without
intervention as possible.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171031/664cd8b8/attachment.sig>