[U-Boot] [PATCH 1/9] phy: atheros: introduce debug read and write functions

[Tom Rini]

On Fri, Dec 06, 2019 at 01:39:29AM +0100, Michael Walle wrote:
> Hi Tom,
> 
> Am 2019-12-06 00:58, schrieb Tom Rini:
> > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote:
> > > Hi Joe, Hi Tom,
> > > 
> > > Am 2019-12-05 16:55, schrieb Joe Hershberger:
> > > > Hi Michael,
> > > >
> > > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael at walle.cc> wrote:
> > > > >
> > > > > Provide functions to read and write the Atheros debug registers.
> > > > >
> > > > > Signed-off-by: Michael Walle <michael at walle.cc>
> > > >
> > > > This series is adding too much size to several of the boards' SPL it
> > > > seems.
> > > >
> > > > https://travis-ci.org/jhershbe/u-boot/builds/620804934
> > > >
> > > > Please address this and resend.
> > > 
> > > So first of all, this was the old series. There was a v2 series, but
> > > unfortunately, I've forgot to add the mailing to the recipients, so it
> > > never ended up in the patchwork system. sorry :(
> > > 
> > > I've resend the v2 series here:
> > > https://patchwork.ozlabs.org/project/uboot/list/?series=146771
> > > 
> > > Now coming to the real problem here. The sizes, or like some boards
> > > handle
> > > the SPL stuff. Btw. I could not reproduce it on the
> > > am335x_boneblack_vboot
> > > board with a gcc-8. I've seen the travis ci job uses the gcc-7 so
> > > this also
> > > depends on the gcc. gcc-8 seems to produce smaller code, because on
> > > the
> > > am335x_evm the overflow was only by some 100 bytes.
> > > 
> > > So taking the am335x_evm board for example. It has the following
> > > options
> > > set:
> > >   CONFIG_DM_ETH=y
> > >   CONFIG_SPL_NET_SUPPORT=y
> > >   CONFIG_PHY_ATHEROS=y (this one is set in the config.h!)
> > > 
> > > So adding a new binding for the phy obviously increases the code
> > > size. But
> > > the hard question is, how could that be fixed. IMHO the board has
> > > wrong
> > > settings. I really don't know how that could be "fixed" other than not
> > > applying this series. Well, we could make the additions conditional
> > > and
> > > introduce a new Kconfig setting, but that is a relly ugly hack and
> > > won't
> > > last long, would it? Doh!
> > 
> > So, the gcc-7 from kernel.org is the min required and must work
> > toolchain.
> 
> Ok.
> 
> > Maybe once gcc-9 is mature enough for people to have made
> > stand-alone toolchains for it we'll move up to that but gcc-8 for
> > everyone ends up being too hard.  For the boneblack_vboot config, we
> > could just drop SPL networking, it's not super critical to that
> > particular example.  But am335x_evm is the kitchen-sink EVM and it is
> > used and supported there.
> > 
> > That said, looking over the u-boot-spl.map, it looks like nfs stuff
> > doesn't get discarded for some reason, I'm going to look in to that.
> 
> Well but that is just some kind of band aid. These two boards were just
> an example. There were also other boards which failed. I doubt the DM
> stuff is getting smaller (I know there is some discussion how to
> improve the situation). But there seems to be no way to disable the
> ethernet device model for the SPL, correct? And unfortunately, this
> also pulls the PHY library (with potential DM bindings).

So, yes, keeping in mind that SPL matters for networking and we need to
keep that in mind when adding features.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191205/a6ee7e14/attachment.sig>