Hi Tom,
On Mon, Dec 9, 2019 at 12:47 PM Tom Rini trini@konsulko.com wrote:
On Mon, Dec 09, 2019 at 07:42:00PM +0100, Michael Walle wrote:
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?
In this case, Joe has it in the -net PR right now. Thanks!
It's actually excluded from the PR. I need to go back and review the rest of the v2 series.
Cheers, -Joe