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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
