[U-Boot] Unified u-boot feature set for simpler distro support

[Dennis Gilmore]

Hi Wolfgang,

On Mon, 05 Aug 2013 22:43:39 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Dennis,
> 
> In message <20130805145059.14c35ebf at adria.ausil.us> you wrote:
> >
> > right, but at the least it needs to be ext4 not all boards today
> > read ext4, btrfs may be something down the road also. u-boot doesnt
> > need to care too much. it just needs to look in / and /boot 
> 
> Where exactly do you raw the line here?  Do we have to support RAID /
> DM devices, too?  What about LVM?  If you look for "regular system
> usage", using such technologies is more or less standard today.  Will
> we need that?
I think not supporting dm or lvm is fine. raid1 mdraid for /boot would
be nice down the road. I say this from the view of an enterprise arm
based server hardware with a pair of sas drives for the filesystem. I
would think that the vendor that produces said hardware would be on the
hook for writing the support. what we need to ensure is that the
installer know what valid options it can support are. if we can't
do /boot on raid we cant do it. 

> > > The rest of the stuff (swap, LVM, ...) seems entirely related to
> > > the distro itself and/or whatever gets put into the initrd.
> > Mostly i was trying to show that where the other bits live doesn't
> > matter.
> 
> Well, what about the case where /boot resides - say - on a multi-drive
> RAID1 array?
usually you can read from one drive from an array without setting up the
raid array first. 

> > While this is a step forward, its still much more than we need to do
> > if we enable pxe support and use sysboot to load a config file the
> > says load this kernel and initramfs and pass these bootargs. My
> > initial post had a fully working example.
> 
> Is my understanding correct that boot times are only a secondary
> concern to you, if any?
boot times are not a primary concern, but that doesn't mean we need to
make it needlessly long. Interrupting a boot to provide input is
perfectly a valid option. Until a few minutes ago I did not know it was
an option. making it short and sweet for most cases and if you need to
do something different the user needs to do something. I can get behind
supporting.

> > for fedora 20 i plan to use raw MLO support for OMAP and have it
> > load the u-boot.img from the first bootable partition. SuSE are
> > doing this
> 
> Please look into Tom's proposal to got the SPL / Falcon mode way. I
> fully agre with him there.
It is going to be my afternoon reading.

Thank you

Dennis