
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.