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

[Bin Meng]

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 :(

Regards,
Bin