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

Michael Walle michael at walle.cc
Fri Dec 6 01:39:29 CET 2019


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).

-michael


More information about the U-Boot mailing list