[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:16:13PM -0700, Stephen Warren wrote:
> On 02/19/2014 12:10 PM, Tom Rini wrote:
> ...
> >> A generic Linux distro wouldn't be installing a kernel to NAND, but
> >> would rather put it into the /boot filesystem. NAND boot is something
> >> that'd be best supported by the custom hook we discussed above.
> > 
> > Wait, why would a generic Linux distro be installing to eMMC but not to
> > NAND ?  Not that this series needs to be the final point in the
> > discussion and all.
> 
> I should point out that I was talking about raw NAND MTD partitions
> rather than a NAND device with a regular partition table and normal
> filesystems within it.
> 
> If the NAND is exposed as a regular block device with a regular
> filesystem, then it'd look just like any other block device to a generic
> distro installer, and hence it could put /boot there, and this patch (or
> future enhancement) could certainly usefully contain a generic
> bootcmd_nand that used it.
> 
> However, if the NAND has hard-coded MTD partitions, and/or the
> partitions have no filesystem but rather contain e.g. a raw
> zImage/uImage, then that would require board-/SoC-specific support in
> the distro kernel and installer, and hence we wouldn't be talking about
> a *generic* installer/distro, and *generic* installers/distros are what
> this patch series is all about.

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
choices.  But I think that's also getting off-topic for us at least (and
yes, am335x is doing raw kernel storage today, fixing that is on my
list).

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.

-- 
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/e806f0e7/attachment.pgp>