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.
... 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.
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?
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.
I'm going to (in a while) hop on the other thread Dennis started and cross-posted to the cross-distro list, but I firmly believe an opt-in set of defaults that let distros have to care less about board specifics is important.
Of course, I agree here. But as I meantioned before, we should not try to solve all problems inside U-Boot only. The ARM kernel itself is still undergoing a lot of changes, and a number of issus could be solved in this environment, too. It's a real pity that distro makes appear to have much more influence there than any of the many embedded vendors.
Best regards,
Wolfgang Denk