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

[Tom Rini]

On Sun, Dec 08, 2019 at 04:54:06PM -0700, Simon Glass wrote:
> 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.

We should probably look at getting the patch I sent the other day to
drop NFS from SPL when we have networking (like that board does) in as
soon as feasible.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191208/54b4f138/attachment.sig>