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

[Dennis Gilmore]

On Wed, 19 Feb 2014 12:43:49 -0700
Stephen Warren <swarren at wwwdotorg.org> wrote:

> 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.

I'm actually going to use raw space for the MLO and u-boot.img, in
Fedora 21, its easier and doesn't require special partitioning. I
assume that when a device with QSPI comes along we will write things in
a way that it can easily be extended to support and boards will ship
day one with working support.  That is assuming that there is QSPI
chips with enough size to be useful are readily available.

Dennis