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.