[U-Boot] [U-Boot, V4, 10/13] spl: add support for alternative boot device

[Tom Rini]

On Thu, Nov 19, 2015 at 01:19:39PM +0200, Nikita Kiryanov wrote:
> Hi Tom,
> 
> On Wed, Nov 18, 2015 at 05:33:20PM -0500, Tom Rini wrote:
> > On Sun, Nov 08, 2015 at 05:11:51PM +0200, Nikita Kiryanov wrote:
> > 
> > > Introduce spl_boot_list array, which defines a list of boot devices
> > > that SPL will try before hanging. By default this list will consist
> > > of only spl_boot_device(), but board_boot_order() can be overridden
> > > by board code to populate the array with custom values.
> > > 
> > > Signed-off-by: Nikita Kiryanov <nikita at compulab.co.il>
> > > Cc: Igor Grinberg <grinberg at compulab.co.il>
> > > Cc: Tom Rini <trini at konsulko.com>
> > > Cc: Simon Glass <sjg at chromium.org>
> > > Reviewed-by: Tom Rini <trini at konsulko.com>
> > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > 
> > So, a problem with this patch is that we push the x600 board, which is
> > an 8KiB SPL target, over the line.  I feel like maybe we need a
> > follow-up patch that makes announcing depend not on libcommon (which
> > x600 needs) but something else to know that there's a reason to
> > announce.
> 
> Based on the content of your reply I'm guessing you're referring to the
> next patch, not this one.

Oh yes, oops.

> I suppose that announcing can be made into an optional feature. However,
> I also think that since printing is an optional feature that can greatly
> increase binary size, it shouldn't be coupled with other, often
> non-optional libcommon features the way it currently is via
> CONFIG_SPL_LIBCOMMON_SUPPORT. The best fix in my opinion would be to
> implement a way to exclude printing support from SPL even if libcommon
> is included (CONFIG_SPL_SILENT that replaces printfs with empty stubs?).
> 
> This will also make it possible to remove all those #ifdef
> CONFIG_SPL_LIBCOMMON_SUPPORT checks that appear all over the SPL code.

So the reason I'm thinking that we want this announce thing separate is
that (due to the way you re-worked it I think, based on Simons' request)
this added a huge amount of space.  We went from OK to overflowing by
more than 1KiB.  So I'm not immediately sure that we can regain that
space with a more (space) efficient printing infrastructure.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151119/8c906c6b/attachment.sig>