From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 19/20] SPL: NAND: Enhance drivers/mtd/nand/nand_spl_simple.c
Date: Mon, 27 Aug 2012 12:08:14 -0700 [thread overview]
Message-ID: <20120827190814.GH24666@bill-the-cat> (raw)
In-Reply-To: <503BB650.9070001@freescale.com>
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.
--
Tom
next prev parent reply other threads:[~2012-08-27 19:08 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 23:58 [U-Boot] [PATCH v4 0/20] ARM: SPL: Make more generic, merge DaVinci and OMAP Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 01/20] Makefile: Move SPL files to clobber, remove from clean Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 02/20] spl_mmc: Make FAT checks / calls guarded with CONFIG_SPL_FAT_SUPPORT Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 03/20] omap-common: SPL: Add CONFIG_SPL_DISPLAY_PRINT / spl_display_print() Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 04/20] omap-common: Fix typo in save_boot_params() in lowlevel_init.S Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 05/20] ARM: SPL: Rename omap_boot_device to spl_boot_device Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 06/20] ARM: SPL: Rename omap_boot_mode to spl_boot_mode() Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 07/20] ARM: SPL: Remove NAND_MODE_HW_ECC from spl_nand.c Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 08/20] ARM: SPL: Only call mem_malloc_init if configured Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 09/20] ARM: SPL: Add <asm/spl.h> and <asm/arch/spl.h> Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 10/20] ARM: SPL: Make spl_mmc.c more generic Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 11/20] ARM: SPL: Clean up spl.c / spl_nand.c slightly Tom Rini
2012-08-27 19:34 ` Sughosh Ganu
2012-08-27 20:17 ` Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 12/20] ARM: SPL: Start hooking in the current SPI SPL support Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 13/20] ARM: SPL: Move gpmc_init() to spl_board_init() Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 14/20] SPL: Move the omap SPL framework to common/spl Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 15/20] SPL: Create arch/arm/lib/spl.c for board_init_f and jump_to_image_linux Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 16/20] SPL: do not use fix value for u-boot size Tom Rini
2012-08-27 19:18 ` Sughosh Ganu
2012-08-27 20:14 ` Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 17/20] ARM: SPL: Convert davinci to CONFIG_SPL_FRAMEWORK Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 18/20] da850: Add README.da850 Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 19/20] SPL: NAND: Enhance drivers/mtd/nand/nand_spl_simple.c Tom Rini
2012-08-25 0:09 ` Scott Wood
2012-08-27 14:37 ` Tom Rini
2012-08-27 16:16 ` Scott Wood
2012-08-27 17:07 ` Tom Rini
2012-08-27 17:14 ` Scott Wood
2012-08-27 17:50 ` Tom Rini
2012-08-27 18:02 ` Scott Wood
2012-08-27 19:08 ` Tom Rini [this message]
2012-08-27 22:04 ` Tom Rini
2012-08-24 23:58 ` [U-Boot] [PATCH v4 20/20] SPL: SPI: Enhance spi_spl_load to match the other load functions Tom Rini
2012-08-27 19:02 ` [U-Boot] [PATCH v4 0/20] ARM: SPL: Make more generic, merge DaVinci and OMAP Sughosh Ganu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120827190814.GH24666@bill-the-cat \
--to=trini@ti.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.