x86: fsp: Don't program MTRR for DRAM for FSP1
authorBin Meng <bmeng.cn@gmail.com>
Mon, 2 Aug 2021 09:45:21 +0000 (17:45 +0800)
committerBin Meng <bmeng.cn@gmail.com>
Mon, 2 Aug 2021 16:01:29 +0000 (00:01 +0800)
commit02541601cbc4adbb9a65b68faa9b8ce14dac7f1d
tree08cc7a1eb6bc1583bc2067c8869a811041dfb681
parent53094331ff3065c4ab51e1442927b1af2b276778
x86: fsp: Don't program MTRR for DRAM for FSP1

There are several outstanding issues as to why this does not apply
to FSP1:

* For FSP1, the system memory and reserved memory used by FSP are
  already programmed in the MTRR by FSP.
* The 'mtrr_top' mistakenly includes TSEG memory range that has the
  same RES_MEM_RESERVED resource type. Its address is programmed
  and reported by FSP to be near the top of 4 GiB space, which is
  not what we want for SDRAM.
* The call to mtrr_add_request() is not guaranteed to have its size
  to be exactly the power of 2. This causes reserved bits of the
  IA32_MTRR_PHYSMASK register to be written which generates #GP.

For FSP2, it seems this is necessary as without this, U-Boot boot
process on Chromebook Coral goes very slowly.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
arch/x86/lib/fsp/fsp_dram.c