Hi Tom, Hi Joe,
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@walle.cc wrote:
Provide functions to read and write the Atheros debug registers.
Signed-off-by: Michael Walle michael@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. 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.
So do I need to do something now? I guess removing the NFS stuff will make enough room to fit this. But how do we make sure, it will be applied with this series?
-michael