From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= Date: Fri, 19 Apr 2013 17:21:49 +0200 (CEST) Subject: [U-Boot] [PATCH 2/6] nand: Add SPL_NAND support to mxc_nand_spl In-Reply-To: <20130419150958.GD246@twoflower.paeps.cx> References: <1366344655-8535-1-git-send-email-marex@denx.de> <1366344655-8535-2-git-send-email-marex@denx.de> <20130419130013.GA246@twoflower.paeps.cx> <20130419144840.GC246@twoflower.paeps.cx> <20130419150958.GD246@twoflower.paeps.cx> Message-ID: <2085828848.1881827.1366384909238.JavaMail.root@advansee.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Philip, On Friday, April 19, 2013 5:09:59 PM,Philip Paeps wrote: > On 2013-04-19 16:48:42 (+0200), Philip Paeps wrote: > > On 2013-04-19 15:00:13 (+0200), Philip Paeps wrote: > > > On 2013-04-19 06:10:51 (+0200), Marek Vasut 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