Patchwork [U-Boot,2/6] nand: Add SPL_NAND support to mxc_nand_spl

login
register
mail settings
Submitter Philip Paeps
Date April 19, 2013, 2:48 p.m.
Message ID <20130419144840.GC246@twoflower.paeps.cx>
Download mbox | patch
Permalink /patch/238008/
State Not Applicable
Delegated to: Stefano Babic
Headers show

Comments

Philip Paeps - April 19, 2013, 2:48 p.m.
On 2013-04-19 15:00:13 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> On 2013-04-19 06:10:51 (+0200), Marek Vasut <marex@denx.de> wrote:
> > To avoid the old function which are used with the nand_spl/ stuff
> > getting in the way of NAND SPL framework, the macro
> > CONFIG_SPL_NAND_LEGACY was introduced and two remaining legacy
> > boards were adjusted. These board need to be either fixed or
> > removed in the long run, but I don't have either.
> 
> It sounds like "fixing" these boards is mainly a matter of confirming
> that a configuration for them based around CONFIG_SPL_FRAMEWORK will fit
> in 2K.  If so, I don't think there is any reason to keep legacy support
> around.

A first build with CONFIG_SPL_FRAMEWORK came out to nearly 4K.  Large
contributors being (unsurprisingly) libcommon and libgeneric.  I had to
get rid of a puts() in libspl to make it build without those libraries.
Unfortunately, that still came out to 2.2K.  Close. :-)

I couldn't identify any obvious 100 bytes to scrap from glancing at
u-boot-spl.map or objdump -D u-boot-spl, but I'll take a look.

 - Philip
Benoît Thébaudeau - April 19, 2013, 2:53 p.m.
Hi Philip,

On Friday, April 19, 2013 4:48:42 PM, Philip Paeps wrote:
> On 2013-04-19 15:00:13 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> > On 2013-04-19 06:10:51 (+0200), Marek Vasut <marex@denx.de> wrote:
> > > To avoid the old function which are used with the nand_spl/ stuff
> > > getting in the way of NAND SPL framework, the macro
> > > CONFIG_SPL_NAND_LEGACY was introduced and two remaining legacy
> > > boards were adjusted. These board need to be either fixed or
> > > removed in the long run, but I don't have either.
> > 
> > It sounds like "fixing" these boards is mainly a matter of confirming
> > that a configuration for them based around CONFIG_SPL_FRAMEWORK will fit
> > in 2K.  If so, I don't think there is any reason to keep legacy support
> > around.
> 
> A first build with CONFIG_SPL_FRAMEWORK came out to nearly 4K.  Large
> contributors being (unsurprisingly) libcommon and libgeneric.  I had to
> get rid of a puts() in libspl to make it build without those libraries.
> Unfortunately, that still came out to 2.2K.  Close. :-)
> 
> I couldn't identify any obvious 100 bytes to scrap from glancing at
> u-boot-spl.map or objdump -D u-boot-spl, but I'll take a look.

Cool. But don't forget that the build must also succeed whatever the toolchain,
so there must be a margin on the 2 kiB, perhaps 5% to 10%.

Another way around could be to just move nand_boot() to a more generic SPL
location so that other hardware having minimal SPL size requirements can use it
without duplicating it. As to hang(), it has already been handled by Andreas.

Best regards,
Benoît
Philip Paeps - April 19, 2013, 3:09 p.m.
On 2013-04-19 16:48:42 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> On 2013-04-19 15:00:13 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> > On 2013-04-19 06:10:51 (+0200), Marek Vasut <marex@denx.de> wrote:
> > > To avoid the old function which are used with the nand_spl/ stuff
> > > getting in the way of NAND SPL framework, the macro
> > > CONFIG_SPL_NAND_LEGACY was introduced and two remaining legacy
> > > boards were adjusted. These board need to be either fixed or
> > > removed in the long run, but I don't have either.
> > 
> > It sounds like "fixing" these boards is mainly a matter of confirming
> > that a configuration for them based around CONFIG_SPL_FRAMEWORK will fit
> > in 2K.  If so, I don't think there is any reason to keep legacy support
> > around.
> 
> A first build with CONFIG_SPL_FRAMEWORK came out to nearly 4K.  Large
> contributors being (unsurprisingly) libcommon and libgeneric.  I had to
> get rid of a puts() in libspl to make it build without those libraries.
> Unfortunately, that still came out to 2.2K.  Close. :-)
> 
> I couldn't identify any obvious 100 bytes to scrap from glancing at
> u-boot-spl.map or objdump -D u-boot-spl, but I'll take a look.

Just as I hit 'send', it occurred to me that this configuration is with
a fairly lengthy lowlevel_init.S to support external boot.  Paring that
to the bare minimum gives a u-boot-spl.bin of 1821 bytes.

I'm not familiar enough with 'internal boot' and the 'imximage' format
to judge whether this leaves enough margin for telling the ROM loader to
do its thing usefully.  Benoît: do you have an idea how long a typically
useful imximage preamble gets?  Is ~230 bytes sufficient margin?

 - Philip
Benoît Thébaudeau - April 19, 2013, 3:21 p.m.
Hi Philip,

On Friday, April 19, 2013 5:09:59 PM,Philip Paeps wrote:
> On 2013-04-19 16:48:42 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> > On 2013-04-19 15:00:13 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> > > On 2013-04-19 06:10:51 (+0200), Marek Vasut <marex@denx.de> wrote:
> > > > To avoid the old function which are used with the nand_spl/ stuff
> > > > getting in the way of NAND SPL framework, the macro
> > > > CONFIG_SPL_NAND_LEGACY was introduced and two remaining legacy
> > > > boards were adjusted. These board need to be either fixed or
> > > > removed in the long run, but I don't have either.
> > > 
> > > It sounds like "fixing" these boards is mainly a matter of confirming
> > > that a configuration for them based around CONFIG_SPL_FRAMEWORK will fit
> > > in 2K.  If so, I don't think there is any reason to keep legacy support
> > > around.
> > 
> > A first build with CONFIG_SPL_FRAMEWORK came out to nearly 4K.  Large
> > contributors being (unsurprisingly) libcommon and libgeneric.  I had to
> > get rid of a puts() in libspl to make it build without those libraries.
> > Unfortunately, that still came out to 2.2K.  Close. :-)
> > 
> > I couldn't identify any obvious 100 bytes to scrap from glancing at
> > u-boot-spl.map or objdump -D u-boot-spl, but I'll take a look.
> 
> Just as I hit 'send', it occurred to me that this configuration is with
> a fairly lengthy lowlevel_init.S to support external boot.  Paring that
> to the bare minimum gives a u-boot-spl.bin of 1821 bytes.

But this requires a board-specific lowlevel_init() and a hack for puts() (which
is perhaps already solved by Andreas' series), just to bloat the SPL with
stuff useless for those boards, vs. a simple nand_boot() that can be made common
to all SPLs with size restrictions.

> I'm not familiar enough with 'internal boot' and the 'imximage' format
> to judge whether this leaves enough margin for telling the ROM loader to
> do its thing usefully.  Benoît: do you have an idea how long a typically
> useful imximage preamble gets?  Is ~230 bytes sufficient margin?

What do you mean? mx31pdk and tx25, contrary to m53evk, use external NAND boot,
hence the 2-kiB SPL size limit (which could actually be extended to 4 kiB for
tx25, but not for mx31pdk), and they don't require any imximage.

Best regards,
Benoît
Benoît Thébaudeau - April 19, 2013, 3:28 p.m.
On Friday, April 19, 2013 5:21:49 PM, Benoît Thébaudeau wrote:
> Hi Philip,
> 
> On Friday, April 19, 2013 5:09:59 PM,Philip Paeps wrote:
> > On 2013-04-19 16:48:42 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> > > On 2013-04-19 15:00:13 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> > > > On 2013-04-19 06:10:51 (+0200), Marek Vasut <marex@denx.de> wrote:
> > > > > To avoid the old function which are used with the nand_spl/ stuff
> > > > > getting in the way of NAND SPL framework, the macro
> > > > > CONFIG_SPL_NAND_LEGACY was introduced and two remaining legacy
> > > > > boards were adjusted. These board need to be either fixed or
> > > > > removed in the long run, but I don't have either.
> > > > 
> > > > It sounds like "fixing" these boards is mainly a matter of confirming
> > > > that a configuration for them based around CONFIG_SPL_FRAMEWORK will
> > > > fit
> > > > in 2K.  If so, I don't think there is any reason to keep legacy support
> > > > around.
> > > 
> > > A first build with CONFIG_SPL_FRAMEWORK came out to nearly 4K.  Large
> > > contributors being (unsurprisingly) libcommon and libgeneric.  I had to
> > > get rid of a puts() in libspl to make it build without those libraries.
> > > Unfortunately, that still came out to 2.2K.  Close. :-)
> > > 
> > > I couldn't identify any obvious 100 bytes to scrap from glancing at
> > > u-boot-spl.map or objdump -D u-boot-spl, but I'll take a look.
> > 
> > Just as I hit 'send', it occurred to me that this configuration is with
> > a fairly lengthy lowlevel_init.S to support external boot.  Paring that
> > to the bare minimum gives a u-boot-spl.bin of 1821 bytes.
> 
> But this requires a board-specific lowlevel_init() and a hack for puts()
> (which
> is perhaps already solved by Andreas' series), just to bloat the SPL with
> stuff useless for those boards, vs. a simple nand_boot() that can be made
> common
> to all SPLs with size restrictions.

Or, with Andreas' series to get rid of puts(), and with an option to make the
use of spl_parse_image_header() an option (i.e. to be able to force raw binary
SPL payload format), the change would be almost equivalent to using the current
nand_boot(), so the size should follow.

Best regards,
Benoît
Philip Paeps - April 19, 2013, 3:41 p.m.
On 2013-04-19 17:21:49 (+0200), Benoît Thébaudeau <benoit.thebaudeau@advansee.com> wrote:
> On Friday, April 19, 2013 5:09:59 PM,Philip Paeps wrote:
> > On 2013-04-19 16:48:42 (+0200), Philip Paeps <philip@paeps.cx> wrote:
> > > A first build with CONFIG_SPL_FRAMEWORK came out to nearly 4K.  Large
> > > contributors being (unsurprisingly) libcommon and libgeneric.  I had to
> > > get rid of a puts() in libspl to make it build without those libraries.
> > > Unfortunately, that still came out to 2.2K.  Close. :-)
> > > 
> > > I couldn't identify any obvious 100 bytes to scrap from glancing at
> > > u-boot-spl.map or objdump -D u-boot-spl, but I'll take a look.
> > 
> > Just as I hit 'send', it occurred to me that this configuration is with
> > a fairly lengthy lowlevel_init.S to support external boot.  Paring that
> > to the bare minimum gives a u-boot-spl.bin of 1821 bytes.
> 
> But this requires a board-specific lowlevel_init() and a hack for puts() (which
> is perhaps already solved by Andreas' series), just to bloat the SPL with
> stuff useless for those boards, vs. a simple nand_boot() that can be made common
> to all SPLs with size restrictions.

Comparing the contents of "framework" SPL with "old" SPL, it looks like
the only thing we gain is support for booting uImage files.  At the cost
of significantly reduced room for flexibility in lowlevel_init().

I agree that a simple nand_boot() is probably the way forward.

> > I'm not familiar enough with 'internal boot' and the 'imximage' format
> > to judge whether this leaves enough margin for telling the ROM loader to
> > do its thing usefully.  Benoît: do you have an idea how long a typically
> > useful imximage preamble gets?  Is ~230 bytes sufficient margin?
> 
> What do you mean? mx31pdk and tx25, contrary to m53evk, use external NAND boot,
> hence the 2-kiB SPL size limit (which could actually be extended to 4 kiB for
> tx25, but not for mx31pdk), and they don't require any imximage.

Mmm.  Oh.  It looks like I was looking at the wrong lowlevel_init()
functions.  They could be made to work with a very stripped down
lowlevel_init(), but it's a _very_ tight fit.

 - Philip
Tom Rini - April 19, 2013, 4:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/19/2013 11:41 AM, Philip Paeps wrote:
> On 2013-04-19 17:21:49 (+0200), Benoît Thébaudeau
> <benoit.thebaudeau@advansee.com> wrote:
>> On Friday, April 19, 2013 5:09:59 PM,Philip Paeps wrote:
>>> On 2013-04-19 16:48:42 (+0200), Philip Paeps <philip@paeps.cx>
>>> wrote:
>>>> A first build with CONFIG_SPL_FRAMEWORK came out to nearly
>>>> 4K.  Large contributors being (unsurprisingly) libcommon and
>>>> libgeneric.  I had to get rid of a puts() in libspl to make
>>>> it build without those libraries. Unfortunately, that still
>>>> came out to 2.2K.  Close. :-)
>>>> 
>>>> I couldn't identify any obvious 100 bytes to scrap from
>>>> glancing at u-boot-spl.map or objdump -D u-boot-spl, but I'll
>>>> take a look.
>>> 
>>> Just as I hit 'send', it occurred to me that this configuration
>>> is with a fairly lengthy lowlevel_init.S to support external
>>> boot.  Paring that to the bare minimum gives a u-boot-spl.bin
>>> of 1821 bytes.
>> 
>> But this requires a board-specific lowlevel_init() and a hack for
>> puts() (which is perhaps already solved by Andreas' series), just
>> to bloat the SPL with stuff useless for those boards, vs. a
>> simple nand_boot() that can be made common to all SPLs with size
>> restrictions.
> 
> Comparing the contents of "framework" SPL with "old" SPL, it looks
> like the only thing we gain is support for booting uImage files.
> At the cost of significantly reduced room for flexibility in
> lowlevel_init().
> 
> I agree that a simple nand_boot() is probably the way forward.

Note that PowerPC has had to deal with this as well, see
drivers/mtd/nand/fsl_elbc_spl.c and I suspect some amount of that
should be made more easily borrowable for the case where SPL doesn't
(or can't/won't) deal with image headers.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRcW7JAAoJENk4IS6UOR1Wmx4P/iIJS8QXZfdO7FNpeZz7Zet6
UNwsFoZeZ1jq+7DhFoA+o5Vwafys+AcYXX2uP0pVC9TJAbGBGSprYao6NE8tA0oo
OWFWktUHoNn5vPedcrZuN6fxcBT9p+7MCo76YojSnWWd2DuwODODY6G3MX7I9iMi
qbsBxJ9R13ubvd3rXGLltDFmR3hZx6wNRv/ke7Mk1dTycEKFbQIFmYhyXLHJLB6+
wxon4knbYcz1GmISUioGDX+hmc4NmKapydSeolmN1wE2tY9+0Mw+OINXcrYTjAN+
8HpeuDsY2d/MzFdfgf9XvrZh2BFWmT7infK09udd6mbxosQYmEc8jIDnk+3DtA1I
blcLjHOkxdVBS1665D0rWVGHs41CQcJfaaSdb3+pZSAbRwNzh2vivuLwdI//LyHf
oMivbM8fLWkSpMSAxu517rfutF+KiJRr0Bns/QqQn4JmIs3qLfjPvpdPST/BaaI9
CAzlpz9c+iZaFvmfutvXhkPOZOKsjAfvT/04SAdXiruf83tn5ceU3/Z/adVxycth
i8UdVqjAG4wtZtGaGjwd7SsW5cFlNy0ODZHMY+QqxD+XSD6T+3L815QpPZDhM2T2
obhgujYC6gg6vAlFp5nWnRxjeL0vB5k/HqV+4k9V9dAcpOyhWRvLeKgaiGyQMSpL
xTyf7qQrf4ZkGFjO1zU/
=lMuD
-----END PGP SIGNATURE-----

Patch

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 6a5a136..c061ab4 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -50,7 +50,6 @@  static bd_t bdata __attribute__ ((section(".data")));
 
 inline void hang(void)
 {
-       puts("### ERROR ### Please RESET the board ###\n");
        for (;;)
                ;
 }