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@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@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.