
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.