From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 4 Jan 2016 09:22:34 -0500 Subject: [U-Boot] Pull request: u-boot-net In-Reply-To: References: <20160102170929.GW4093@bill-the-cat> <20160104034659.GA4093@bill-the-cat> Message-ID: <20160104142234.GB4093@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote: > Hi Dirk, > > On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach wrote: > > Hi Bin, > > > >> ... > >> The simple fix is to change change iocon to a more larger size since > >> it has a 64MB flash. Dirk, can you please comment? > > > > The problem is the flash partition layout, coming from a time where > > u-boot was an order of magnitude smaller :) > > > > I guess so. > > > Updating partition layout in tens of thousands of devices in the field > > is not an option for us. > > > > I suspect 256KB won't fit anyway, if trying to make use of these new > U-Boot features,eg: using driver model adds some more footprints too. > So in your deployment, you just upgrade those devices in the field to > latest U-Boot (new version) but not changing partition layout, for fix > only? I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off. I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: