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, just the hush.c patch is enough now, I'll take that and the current PR. I'll also post as patches some of what I've done locally.