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

[Tom Rini <trini@konsulko.com>]

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.

-- 
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/c0b2aa00/attachment.sig>