On Mon, Dec 28, 2015 at 09:02:02PM -0600, Joe Hershberger wrote: > Hi Tom, > > On Wed, Dec 23, 2015 at 9:47 PM, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote: > > > >> A few patches that came in during the merge window and appear harmless. > > > > so.. > > Hmm... With the buildman toolchains I'm using nothing broke.
What one(s) are that? ELDK 5.3 has failed for a while for me and ELDK 5.6 just started with this PR. > >> These cause no additional build warnings or errors. > >> > >> Thanks, > >> -Joe > >> > >> The following changes since commit > >> 4832e17787acb29734d895751bc7a594908aecc6: > >> > >> Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze > >> (2015-12-18 07:28:24 -0500) > >> > >> are available in the git repository at: > >> > >> > >> git://git.denx.de/u-boot-net.git master > >> > >> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c: > >> > >> net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused > >> (2015-12-21 20:01:57 -0600) > >> > >> ---------------------------------------------------------------- > >> Bin Meng (5): > >> fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() > >> fdt: Rewrite the logic in fdt_fixup_ethernet() > > > > This one here pushes "iocon" just over the edge, again, with ELDK 5.6. > > > > First off, let me say that I eagarly await the gcc that will finally let > > strings of garbage collected functions also be collected and dropped. > > My first very quick _hack_ here to gain a tiny bit of space back was to > > remove from the common case some functions in common/fdt_support.c > > > > I really don't know a good fix for today and as Dirk has pointed out > > (and I frankly agree, and have been poked about in some other places), > > we really do need to take care with our image sizes when adding all of > > these neat new features. > > That's a fine goal, but features aren't free. We can have a goal of > not bloating grossly or making easily separable functionality > disable-able by adding ifdefs, but requiring that any given Yes, this is where I do agree and wonder if we perhaps haven't been giving enough care here. Especially since until another big gcc release or two we won't have the stupid string consolidation bug fixed. We may need to keep that bug in mind and re-think how we structure some of the code. > combination of ifdefs in a config never grow even a few bytes seems > unwieldy. Surely keeping any target so close to the limit is a waste > of everyone's time and energy. Why not take advantage of the enormous > numbers of ifdefs and start disabling some features to get these > targets off the ledge? The problem with "iocon" is that we have an active board maintainer and I'm not immediately seeing a bunch of waste that could just be turned off here. Perhaps Dirk will see something or another. > > -Joe -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
