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 trini@konsulko.com 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 trini@konsulko.com 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 trini@konsulko.com 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 dirk.eibach@gdsys.cc 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.