Hi, On Sun, 8 Dec 2019 at 06:23, Tom Rini <tr...@konsulko.com> wrote: > > On Sun, Dec 08, 2019 at 04:56:21PM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Sat, Dec 7, 2019 at 12:43 PM Simon Glass <s...@chromium.org> wrote: > > > > > > Apollo Lake is an Intel SoC generation aimed at relatively low-end > > > embedded systems. It was released in 2016 but has become more popular > > > recently with some embedded boards using it. > > > > > > This series adds support for Apollo Lake. As an example it adds an > > > implementation of chromebook_coral (a large range of Chromebooks released > > > in 2017). > > > > > > The series provides enough support to boot to a prompt. with LCD display, > > > storage, USB, EC and keyboard. > > > > > > Since this is the first time U-Boot has used FSP2 there is quite a bit of > > > refactoring needed. > > > > > > This series is available at u-boot-dm/coral-working > > > > > > > I applied the first 85 patches in the v6 series to u-boot-x86/next, > > except the following 2 patches: > > > > [v6,015/102] Revert "RFC: sandbox: net: Suppress the MAC-address warnings > > [v6,014/102] RFC: sandbox: net: Suppress the MAC-address warnings > > > > I believe this needs to be handled by Joe? > > > > The patches unfortunately break am335x_evm. > > > > Azure logs: > > arm: + am335x_evm > > +arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not > > fit in region `.sram' > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 8 bytes > > +make[2]: *** [spl/u-boot-spl] Error 1 > > +make[1]: *** [spl/u-boot-spl] Error 2 > > +make: *** [sub-make] Error 2 > > > > GitLab logs: > > arm: + am335x_evm > > +arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not > > fit in region `.sram' > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 76 bytes > > +make[2]: *** [spl/u-boot-spl] Error 1 > > +make[1]: *** [spl/u-boot-spl] Error 2 > > +make: *** [sub-make] Error 2 > > > > Would you please take a look, and propose a fix so that I can squash > > into the one that breaks this board? > > https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/37696 > > > > @Tom, not sure why Azure and GitLab reported different size > > overflowed? (8 vs 76). Is this caused by build directory path? > > Seems likely to be a path size overflow, yeah.
The use of BUG(), WARN_ON() and friends brings in __FILE__. I'll send a patch to help with that. At least with gcc 7.3 it builds OK for me. There are about 13KB of strings in SPL for this board. I hate to say it, but it seems that the gcc rodata bug has returned. For example, it brings in the compat_name[] when building SPL, even though that is not actually used. I vaguely recall that this only happens when partial linking is used, but I cannot easily change U-Boot to use archives these days. Regards, SImon
