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

[Tom Rini]

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.

-- 
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/10d24c53/attachment.sig>