[PATCH v6 000/102] x86: Add initial support for apollolake

[Simon Glass]

Hi,

On Sun, 8 Dec 2019 at 06:23, Tom Rini <trini at 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 <sjg at 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