[U-Boot] [PATCH 1/1] Broadwell-DE Implementation

[Peter Tyser]

Hi Vincenzo,

On Thu, 2018-01-25 at 13:58 -0500, vnktux wrote:
> Hi all,
> 
> This patch contain a working implementation of Broadwell-DE for U-
> Boot, and support memory down with external SPD binary file. However
> there is only one issue that I couldn't solve, the booting process
> takes 1 hour. When the FSP reach "DDRIO Initialization" it take a lot
> before the memory is initialized and you can reach the U-Boot shell.
> I would like a review of my implementation since I am out of options.
> I tried to Enable/Disable MRC Cache and ACPI Resume but the problem
> is still there.

Thanks for the Broadwell-DE work.  It'd be nice to have a port!  I
tried your code on one of our Broadwell-DE board this weekend and saw
similar behavior to you with the slow boot time.  I believe this is
related to cache configuration.  A modification like the following
makes my board boot quickly (sub 10 seconds):

--- a/arch/x86/lib/fsp/fsp_car.S
+++ b/arch/x86/lib/fsp/fsp_car.S
@@ -106,5 +106,5 @@ _dt_ucode_base_size:
 ucode_base:    /* Declared in micrcode.h */
        .long   0                       /* microcode base */
        .long   0                       /* microcode size */
-       .long   CONFIG_SYS_MONITOR_BASE /* code region base */
-       .long   CONFIG_SYS_MONITOR_LEN  /* code region size */
+       .long   0xffffffff - 0x1000000 + 1      /* code region base */
+       .long   0x1000000                       /* code region size */

The above is just a proof of concept meant to show the problem area - a
more elegant solution should likely be used.  The "code region" above
is passed into the FSP, which I believe enables caching in that region.
 Increasing it from 1MB to 16MB (the size of my SPI flash) made the
boot time more sane.

The latest patch series also seems to have whitespace issues so that it
can't apply cleanly without modification.  As an example,
arch/x86/dts/u-boot.dtsi has indentation that is not present in  https:
//patchwork.ozlabs.org/patch/866257/ which makes it not apply.  It'd be
good to fix that on future submissions.

The patch series seemed to mostly work out of the box to get up to a
command prompt, which is great!  It could boot a Linuz zImage as well.
 There seemed to be some rough edges (eg multi processor support), but
I didn't kick the tires too much and assume those edges shouldn't be
too bad to smooth out later.

Regards,
Peter