On Fri, 28 Feb 2014 09:00:25 +0100, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > On Fri, Feb 21, 2014 at 10:47:09AM -0800, Olof Johansson wrote: > > On Fri, Feb 21, 2014 at 6:11 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > On Thu, Feb 20, 2014 at 05:07:12PM -0800, Frank Rowand wrote: > > > > >> Why are the changes not submitted upstream? (Or if they were submitted, why > > >> were they not accepted?) > > > > > > The descriptions where to find the environment are obviously barebox > > > specific and not acceptable upstream. > > > > Why not? Wouldn't it be useful if you could find where the environment > > is from the running Linux image so that you can change variables > > without rebooting into Barebox first? > > Indeed that would be very useful. Generally that would require some > generic binding for referring to partitions on mtd devices, partitions > on block devices and EEPROMs. If you think such a binding would have a > chance upstream I could try and come up with a binding. I agree. I want to explore doing the same thing for UEFI also. Currently the UEFI spec pretty much requires UEFI runtime services to 'own' the device that holds variable storage, but that doesn't work on cost-sensitive devices that can't afford separate flash dedicated to UEFI. I'd like to investigate a spec extension that defines the variable storage format on a block device so that Linux can directly manipulate it without a runtime services call. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
