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.

Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to