[U-Boot] Pull request: u-boot-net
Bin Meng
bmeng.cn at gmail.com
Tue Jan 5 05:18:35 CET 2016
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.
Regards,
Bin
More information about the U-Boot
mailing list