On Mon, Aug 05, 2013 at 12:11:47AM +0200, Wolfgang Denk wrote:
Dear Tom,
In message 20130804214743.GJ5164@bill-the-cat you wrote:
I am not that pessimistic. The tools are all available and in place. "env import" (and other capabilities of the "env" command) allow to import any set of environment from any storage location U-Boot can handle. This allows to implement all kind of fancy features, like "user profiles", "reset to factory defaults", etc. etc. Of course it also allows to implement settings needed to support booting of a standard distribution.
How far back do we have an env import command available to all, is one the questions. ...
The support for this was added with commit ea882ba "New implementation for internal handling of environment variables." on Sun Jun 20, 2010, i. e. more than 2 years ago.
That's a long time, actually.
But not long enough in some cases. But a good point for a general solution going forward.
... I hadn't thought about saying part of the solution isthat distros should provide an environment file to import (and if applicable, saveenv'ing after). But what I mean is that we have a half dozen (it feels like) semi-flexible environments different boards/socs compile in, and it's not easy to share those. One of the requests is a "sane" default boot command, and we do have a number of boards out there without a savable environment.
Requests for a "sane" environment are comprehensible. However, it will be difficult to reach an agreement what exactly "sane" means here. For example, I have never been able to get accustomed to all the uEnv.txt, user.txt etc. scripts used with a number of boards; for me, all this seems way too complicated and inflexible, and I always try to get rid of this stuff. I'm aware that other people like the approach. OK - I see no problems with that: TIMTOWTDI.
I would only have a problem (and a serious one) if such an approach became standard, or even mandatory. Not to mention a large number of projects I know of.
Right. This would be an agreement between us and the generic Linux distros that want in about what "sane" means, in terms of enabling users to get up and running. We want the advanced users to be able to drop in and do what they want to do in U-Boot but let the new users get to their comfort ground (generic linux distro) without going crazy either.
You mean, as an external tool, to translate extlinux.conf into a set of U-Boot commands?
No, I mean as a run-time command in u-boot to, given a pointer to extlinux.conf in memory, translate to a set of boot commands. The use case here is that user installs (via package manager) a new kernel and just like on your desktop you can chose to boot it, easily enough.
Can we not rather do the translation on the host side, so we don;t have to add both the code and the runtime overhead for each boot process?
It's debatable, yes. As part of this, I'd like to leave the door open so that for example the default experience is that whatever kernel the user chose as the main kernel gets booted via falcon mode (so quick boot) and on pressing c (or whatever) they get full U-Boot that would (in this case of a generic linux distro, find all that is required to) show up a menu for them to pick from (as they didn't interrupt the autoboot command that would do all of this).
Define "reference platform"? Do you think, for example, systems in the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to run Fedora? Does Fedora actually support any targets below ARMv7 ?
Fedora (and Ubuntu) don't officialy support sub-v7 platforms but that hasn't deterred the RPi community from making it happen all the same. But yes, AM1808 and i.MX28 and anything else with community support, IOs and upstream support is quite useful for maker folks (again, see RPi). Debian, iirc, still supports ARMv5 out of the box, and I'm sure anything that makes "Just Working" out of the box would be welcome in OpenEmbedded/Yocto-land.
Well, OE and Yocto allow to build fine-tuned target environments; they really don't have any new requirements as "standard" distros like Fedroa do.
Yeah, and it's also true that less per machine hacking you have to do with each new board, the easier it is (and the better the out of box experience it is on their side). We just synced up the environment on wandboard with how OE likes to see it. If it was instead they just had to provide an environment text file in the machine overlay or even just generate a default one (since the image is only going to have one kernel most likely), it'd be a win on that side.