[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren <swarren@wwwdotorg.org>]

On 02/19/2014 12:36 PM, Tom Rini wrote:
...
> I would put a generic distro knowing how to deal, genericially at least,
> with NAND on par with knowing how to deal with HW RAID or other not too
> uncommon desktop features.  If /dev/mtdblockN then offer UBI or a few
> other choices, else if /dev/sd* then offer ext* or btrfs or a few other

But how do /dev/mtdblockN get into existence? MTD partitions have
historically been defined on the kernel command-line haven't they, and
hence it'd require a board-specific cmdline to support that. Hmmm.
Perhaps they can be specified in DT nowadays? If so, then NAND should
indeed be pretty easy to deal with.

> One thing this series does have to cope with, some way or another, is to
> be able to say "Oh, you have other boot devices too, we must handle them
> somehow".  With my TI custodian hat on, it would be quite handy for
> Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's
> going to make me quite grumpy if I can't also easily support AM335x GP
> EVM and its NAND and I start to worry if QSPI, which I have a feeling is
> going to take off like eMMC did, is going to just get ignored and when
> Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI
> on-board we don't start kicking ourselves again.

I assume QSPI would be just the system boot flash, and not for
filesystem storage? As a general rule, I assert that distros shouldn't
have to know anything about installing/updating bootloaders; that should
be something that happens before you attempt to use a distro installer,
and most likely uses board-/SoC-specific tools. If QSPI is filesystem
storage, then assuming it shows up like any other block device, it
should work out just like NAND as we discussed above.

Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards
which require the firmware in a partition on the SD card, since there's
no other storage device. Still, hopefully that's as simple as detecting
the specific board based on DT compatible value, and installing a
particular extra package for it.