Hi Tom, On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini <tr...@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 <tr...@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 <tr...@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.eib...@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? Thanks, -Joe _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
