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

[Tom Rini]

On Wed, Feb 19, 2014 at 12:43:49PM -0700, Stephen Warren 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.

They've been in the device tree since before ARM started converting :)

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

QSPI is another MTD block device, and can be of "reasonable" size.

My point being that we don't want to say that the only use cases for
"generic distro" are SD/SATA/"network".  If we say from the outset that
we won't even try and expose $FOO because it's not something they deal
with today, people certainly won't.

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

What I'm saying is that while Beaglebone Black ships with eMMC today
(and oh, hey, duh, Beagleboard not-xM ships with NAND), tomorrows hot
commodity board quite well include a different on-baord storage, but one
we can worry about a bit today.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/c71ba159/attachment.pgp>