[U-Boot] Pull request: u-boot-net

[Tom Rini]

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 at 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 at 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 at 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 at 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/73d2e06f/attachment.sig>