From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Pull request: u-boot-net
Date: Tue, 5 Jan 2016 08:18:28 -0500 [thread overview]
Message-ID: <20160105131828.GI4093@bill-the-cat> (raw)
In-Reply-To: <CAEUhbmUjT-xKbmp0DSSD42VbGXHDs=qU_fUwC+BCn3HvWSG_Eg@mail.gmail.com>
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.
--
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/20160105/362a3b49/attachment.sig>
next prev parent reply other threads:[~2016-01-05 13:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 17:58 [U-Boot] Pull request: u-boot-net Joe Hershberger
2015-12-24 3:47 ` Tom Rini
2015-12-29 3:02 ` Joe Hershberger
2015-12-29 14:09 ` Tom Rini
2016-01-02 17:09 ` Tom Rini
2016-01-04 2:35 ` Bin Meng
2016-01-04 3:46 ` Tom Rini
2016-01-04 3:56 ` Bin Meng
2016-01-04 8:31 ` Bin Meng
2016-01-04 14:24 ` Tom Rini
2016-01-05 4:08 ` Bin Meng
2016-01-05 13:18 ` Tom Rini
2016-01-04 11:46 ` Dirk Eibach
2016-01-04 13:48 ` Bin Meng
2016-01-04 14:22 ` Tom Rini
2016-01-05 4:18 ` Bin Meng
2016-01-05 13:18 ` Tom Rini [this message]
2016-01-07 2:49 ` Bin Meng
2016-01-07 16:29 ` Tom Rini
2016-01-13 20:58 ` Joe Hershberger
2016-01-13 23:01 ` Tom Rini
2016-01-13 23:10 ` Tom Rini
2016-01-14 13:20 ` Tom Rini
2016-01-04 14:32 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2012-04-04 16:06 Joe Hershberger
2012-04-09 15:16 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160105131828.GI4093@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox