From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 13 Jan 2016 18:01:40 -0500 Subject: [U-Boot] Pull request: u-boot-net In-Reply-To: References: <20160104034659.GA4093@bill-the-cat> <20160104142234.GB4093@bill-the-cat> <20160105131828.GI4093@bill-the-cat> <20160107162941.GD3359@bill-the-cat> Message-ID: <20160113230140.GT3359@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 Wed, Jan 13, 2016 at 02:58:41PM -0600, Joe Hershberger wrote: > Hi Tom, > > On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini wrote: > > On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote: > >> On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini wrote: > >> > On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote: > >> >> Hi Tom, > >> >> > >> >> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini wrote: > >> >> > 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. > >> >> > >> >> So, what's our best way to do with this PR? I am worried that since > >> >> this iocon board is already at an edge, any ramdom bug fix (to common > >> >> codes) in the future could be the next victim. > >> > > >> > For this PR, I think we need to push the fdt patch in question out and > >> > for the next release look at splitting up common/fdt_support.c into > >> > logical chunks. > >> > > >> > >> Do anyone volunteer to do this "splitting up common/fdt_support.c into > >> logical chunks"? I still cannot make ELDK work in my env thus cannot > >> make any further investigation :( > > > > I'll put it on my TODO list. I'll leave ELDK support up to the denx > > folks. > > Maybe Bin can make a patch to disable Ethernet on iocon and apply > before the fdt patch? Or would we rather wait on this until you rework > the fdt_support? Or just rebase this pr and apply as is? So, ELDK 5.3 requires a lot of lifting to get the size down to linking (and in fact fails locally either way). I did a bunch of easy non-FDT trimming now, let me see if that gets the -net PR linking still and work from there. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: