[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>