| Message ID | 20130419144840.GC246@twoflower.paeps.cx |
|---|---|
| State | Not Applicable |
| Delegated to: | Stefano Babic |
| Headers | show |
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
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
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
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
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
-----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-----
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 (;;) ; }