[U-Boot] [PATCH v4 19/20] SPL: NAND: Enhance drivers/mtd/nand/nand_spl_simple.c

[Tom Rini]

On Mon, Aug 27, 2012 at 12:08:14PM -0700, Tom Rini wrote:
> On Mon, Aug 27, 2012 at 01:02:56PM -0500, Scott Wood wrote:
> > On 08/27/2012 12:50 PM, Tom Rini wrote:
> > > On Mon, Aug 27, 2012 at 12:14:30PM -0500, Scott Wood wrote:
> > >> On 08/27/2012 12:07 PM, Tom Rini wrote:
> > >>> On Mon, Aug 27, 2012 at 11:16:45AM -0500, Scott Wood wrote:
> > >>>> On 08/27/2012 09:37 AM, Tom Rini wrote:
> > >>>>> On 08/24/2012 05:09 PM, Scott Wood wrote:
> > >>>>>> What is the benefit of putting this in nand_spl_simple.c versus another
> > >>>>>> file?  What if someone wants to use this with a different NAND boot
> > >>>>>> implementation?
> > >>>>>
> > >>>>> I would start by questioning the need of a 3rd SPL framework.
> > >>>>
> > >>>> The "simple" driver does not work for all hardware.  This is why we have
> > >>>> nand_spl/nand_boot_fsl_elbc.c and others in addition to
> > >>>> nand_spl/nand_boot.c.  It's not a "3rd SPL framework", just a different
> > >>>> NAND implementation.
> > >>>
> > >>> The question boils down to, what are your size constraints?  I guess
> > >>> what I'm saying is, if it's <4kb, it's not using this file nor the
> > >>> framework.
> > >>
> > >> 4K SPLs will use nand_spl_simple.c.  It is pretty much a copy of
> > >> nand_spl/nand_boot.c which 4K SPLs use, and Wolfgang is insisting that
> > >> no new boards be added to nand_spl, so they must use the new SPL (even
> > >> if there are no new 4xx boards, presumably such a stance by Wolfgang
> > >> indicates a desire to see nand_spl go away entirely at some point).
> > >>
> > >>> If we've got more than 4kb to work with, it's using the
> > >>> framework (with changes if needed, of course) and I guess we could move
> > >>> the function to common/spl/spl_nand.c and add
> > >>> drivers/mtd/nand/nand_spl_fsl_elbc.c and so on.  Now that I've had more
> > >>> coffee, do I follow your suggestion right?
> > >>
> > >> I think so.  eLBC is 4K-limited, but IFC is similar and can do an 8K SPL
> > >> (though we currently don't), and who knows what controllers will come
> > >> along in the future.
> > > 
> > > When do you plan to try and do the conversion? :) 
> > 
> > I started a conversion of an eLBC board recently, but ran into some bugs
> > that I couldn't squash by the end of the merge window -- at which point
> > the timeslice expiration hit and its priority dropped.
> > 
> > I may be able to resume next week (this week is Linux Plumbers).
> > 
> > > I kludged (but think it would still work) hawkboard to 887 bytes over 4kb and I see bamboo is
> > > 736 bytes under, leaving a 151 byte gap (in this very quick and somewhat
> > > silly SWAG).  So maybe we can use this framework for 4KB systems.
> > 
> > Perhaps for some of them.  How much does the framework add?
> 
> For hawkboard (davinci and NAND) we grew by 894 bytes.  Doing some
> re-organization of the code just now I've got that growth down to 766
> bytes.  Some of that reduction I had in the other quick swag I was doing
> however.

Whack out a few more prints (enabled still for debug) and we're at 711
byte growth now.  Will be part of v5.

-- 
Tom