From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 27 Aug 2012 13:02:56 -0500 Subject: [U-Boot] [PATCH v4 19/20] SPL: NAND: Enhance drivers/mtd/nand/nand_spl_simple.c In-Reply-To: <20120827175037.GG24666@bill-the-cat> References: <1345852714-13138-1-git-send-email-trini@ti.com> <1345852714-13138-20-git-send-email-trini@ti.com> <503817B0.6080109@freescale.com> <503B8623.4040905@ti.com> <503B9D6D.90302@freescale.com> <20120827170705.GF24666@bill-the-cat> <503BAAF6.7000104@freescale.com> <20120827175037.GG24666@bill-the-cat> Message-ID: <503BB650.9070001@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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? > And, I'll split things out for now so we can move past this. OK, thanks. -Scott