| Message ID | 20171025122601.28224-1-maxime.ripard@free-electrons.com |
|---|---|
| Headers | show |
| Series | sunxi: Implement transition in environment | expand |
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
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
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
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