diff options
author | Bin Meng <bmeng.cn@gmail.com> | 2023-07-31 14:01:04 +0800 |
---|---|---|
committer | Bin Meng <bmeng.cn@gmail.com> | 2023-08-01 10:06:46 +0800 |
commit | 3dfa4115016de44410f7cc58fa5277ec39dcd4e1 (patch) | |
tree | 88cd19201e2187460c24f5e37941287453366ce0 /drivers | |
parent | 41fbb344695f224d70d3c469ea418015279ba55e (diff) | |
download | u-boot-3dfa4115016de44410f7cc58fa5277ec39dcd4e1.zip u-boot-3dfa4115016de44410f7cc58fa5277ec39dcd4e1.tar.gz u-boot-3dfa4115016de44410f7cc58fa5277ec39dcd4e1.tar.bz2 |
x86: fsp: Use mtrr_set_next_var() for graphics memory
At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:
- mtrr_commit() will re-initialize all MTRR registers from index 0,
using the settings previously added by mtrr_add_request() and saved
in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
has full control with MTRR programming (e.g.: U-Boot without any blob
that does all low-level initialization on its own, or using FSP2 which
does not touch MTRR), but this is not the case with FSP. FSP programs
some MTRRs during its execution but U-Boot does not have the settings
saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
corrupt what was already programmed previously.
Correct this to use mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions