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.