From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Date: Tue, 19 Dec 2017 15:50:53 +0100 Subject: [U-Boot] ARM64 Allwinner Binary Size In-Reply-To: References: <11d6d712-610b-f972-1d5b-6ab062c07695@arm.com> <20171219131202.dkk4p4m27fv7jvdr@flea.lan> <7fea3496-99a5-cb94-256b-9b518d8be892@arm.com> <20171219142029.l7nqhcdy3hmj63ix@flea.lan> Message-ID: <20171219145053.jauexoxwvxpgs5gs@flea.lan> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Dec 19, 2017 at 10:41:23PM +0800, Chen-Yu Tsai wrote: > > All these trimming(if it fits) seems to be nice for now, but what if > > once driver-model MMC, reset, pinctrl, clk, regulator are IN? I guess a better question would be: what are we doing to fix an issue we had in a release already and will destroy the binary as soon as someone does a saveenv? > > of-course we can't do anything with SPL size because of SRAM > > constraints, but U-Boot proper size? why can't we increase the u-boot > > partition size? > > That is a really big if, given no one is actively working on it. > I reckon we deal with it when someone starts having patches merged. :) +1. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com