On Fri, Aug 02, 2013 at 11:14:22AM +0200, Stefano Babic wrote: > Hi Rob, Dennis, > > On 01/08/2013 19:19, Rob Herring wrote: > > You both are missing the point. This patch doesn't address the problem, > > but does highlight it. > > I am aware of it - I have already pointed out that we get many patches > that have increased the default environment to something hard to > maintain. This patch makes it more obvious. > > > The distros want to get out of having to know the > > u-boot environment details for every single board and need some level of > > standardization across platforms. The distros should only have to > > specify "boot the kernel at path/name X on device Y." They should not > > need to know what address to load the kernel to, but only that > > $kernel_addr_r is already setup. Variables are the first step. The > > second step is standardizing the boot commands. > > I understand the point - but is the way to hard code together with > u-boot the right way ? Do we have some other possibilities to do this ? > > Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an > environment image from a simple ASCII text. The resulting image could be > concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we > could have for all boards a way to load it. Only a first idea, but as we > recognize the issue, any idea to solve it ?
Distros generally hate the thought of having the user update U-Boot. Part of why I asked Dennis to post his patches here is that we need to start the conversation at least, and come up with a way that boards are likely to ship out of the box in a way that can be worked from, consistently at least across different vendor same arch SoCs. This would require some opt-in per board, certainly. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
