From: Bin Meng <bmeng.cn@gmail.com>
To: Simon Glass <sjg@chromium.org>, u-boot@lists.denx.de
Cc: Bin Meng <bmeng.cn@gmail.com>
Subject: [PATCH 1/7] x86: fsp: Don't program MTRR for DRAM
Date: Sat, 31 Jul 2021 16:45:23 +0800 [thread overview]
Message-ID: <20210731084529.7524-2-bmeng.cn@gmail.com> (raw)
In-Reply-To: <20210731084529.7524-1-bmeng.cn@gmail.com>
This actually reverts the following 2 commits:
commit 427911001809 ("x86: Set up the MTRR for SDRAM")
commit d46c0932a9d4 ("x86: fsp: Adjust calculations for MTRR range and DRAM top")
There are several outstanding issues as to why:
* 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.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
arch/x86/lib/fsp/fsp_dram.c | 35 ++++++++++-------------------------
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
index 8ad9aeedac..928c5225cd 100644
--- a/arch/x86/lib/fsp/fsp_dram.c
+++ b/arch/x86/lib/fsp/fsp_dram.c
@@ -11,7 +11,6 @@
#include <asm/e820.h>
#include <asm/global_data.h>
#include <asm/mrccache.h>
-#include <asm/mtrr.h>
#include <asm/post.h>
#include <dm/ofnode.h>
@@ -42,10 +41,8 @@ int fsp_scan_for_ram_size(void)
int dram_init_banksize(void)
{
- efi_guid_t fsp = FSP_HOB_RESOURCE_OWNER_FSP_GUID;
const struct hob_header *hdr;
struct hob_res_desc *res_desc;
- phys_addr_t mtrr_top;
phys_addr_t low_end;
uint bank;
@@ -53,47 +50,35 @@ int dram_init_banksize(void)
gd->bd->bi_dram[0].start = 0;
gd->bd->bi_dram[0].size = gd->ram_size;
- mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
return 0;
}
- low_end = 0; /* top of low memory usable by U-Boot */
- mtrr_top = 0; /* top of low memory (even if reserved) */
+ low_end = 0;
for (bank = 1, hdr = gd->arch.hob_list;
bank < CONFIG_NR_DRAM_BANKS && !end_of_hob(hdr);
hdr = get_next_hob(hdr)) {
if (hdr->type != HOB_TYPE_RES_DESC)
continue;
res_desc = (struct hob_res_desc *)hdr;
- if (!guidcmp(&res_desc->owner, &fsp))
- low_end = res_desc->phys_start;
if (res_desc->type != RES_SYS_MEM &&
res_desc->type != RES_MEM_RESERVED)
continue;
if (res_desc->phys_start < (1ULL << 32)) {
- mtrr_top = max(mtrr_top,
- res_desc->phys_start + res_desc->len);
- } else {
- gd->bd->bi_dram[bank].start = res_desc->phys_start;
- gd->bd->bi_dram[bank].size = res_desc->len;
- mtrr_add_request(MTRR_TYPE_WRBACK, res_desc->phys_start,
- res_desc->len);
- log_debug("ram %llx %llx\n",
- gd->bd->bi_dram[bank].start,
- gd->bd->bi_dram[bank].size);
+ low_end = max(low_end,
+ res_desc->phys_start + res_desc->len);
+ continue;
}
+
+ gd->bd->bi_dram[bank].start = res_desc->phys_start;
+ gd->bd->bi_dram[bank].size = res_desc->len;
+ log_debug("ram %llx %llx\n", gd->bd->bi_dram[bank].start,
+ gd->bd->bi_dram[bank].size);
}
/* Add the memory below 4GB */
gd->bd->bi_dram[0].start = 0;
gd->bd->bi_dram[0].size = low_end;
- /*
- * Set up an MTRR to the top of low, reserved memory. This is necessary
- * for graphics to run at full speed in U-Boot.
- */
- mtrr_add_request(MTRR_TYPE_WRBACK, 0, mtrr_top);
-
return 0;
}
@@ -166,7 +151,7 @@ unsigned int install_e820_map(unsigned int max_entries,
#if CONFIG_IS_ENABLED(HANDOFF) && IS_ENABLED(CONFIG_USE_HOB)
int handoff_arch_save(struct spl_handoff *ho)
{
- ho->arch.usable_ram_top = gd->bd->bi_dram[0].size;
+ ho->arch.usable_ram_top = fsp_get_usable_lowmem_top(gd->arch.hob_list);
ho->arch.hob_list = gd->arch.hob_list;
return 0;
--
2.25.1
next prev parent reply other threads:[~2021-07-31 8:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-31 8:45 [PATCH 0/7] x86: Various fixes to MTRR and FSP codes Bin Meng
2021-07-31 8:45 ` Bin Meng [this message]
2021-08-01 19:19 ` [PATCH 1/7] x86: fsp: Don't program MTRR for DRAM Simon Glass
2021-08-02 2:53 ` Bin Meng
2021-07-31 8:45 ` [PATCH 2/7] x86: mtrr: Do not clear the unused ones in mtrr_commit() Bin Meng
2021-08-01 19:19 ` Simon Glass
2021-08-02 2:50 ` Bin Meng
2021-07-31 8:45 ` [PATCH 3/7] x86: mtrr: Skip MSRs that were already programmed " Bin Meng
2021-08-01 19:19 ` Simon Glass
2021-08-02 2:50 ` Bin Meng
2021-07-31 8:45 ` [PATCH 4/7] x86: mtrr: Abort if requested size is not power of 2 Bin Meng
2021-08-01 19:19 ` Simon Glass
2021-08-02 2:50 ` Bin Meng
2021-07-31 8:45 ` [PATCH 5/7] x86: cmd: hob: Fix the command usage and help messages Bin Meng
2021-08-01 19:19 ` Simon Glass
2021-08-02 2:50 ` Bin Meng
2021-07-31 8:45 ` [PATCH 6/7] x86: cmd: hob: Fix display of resource type for system memory Bin Meng
2021-08-01 19:19 ` Simon Glass
2021-08-02 2:50 ` Bin Meng
2021-07-31 8:45 ` [PATCH 7/7] x86: fsp: Only FSP2 has INIT_PHASE_END_FIRMWARE Bin Meng
2021-08-01 19:19 ` Simon Glass
2021-08-02 2:53 ` Bin Meng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210731084529.7524-2-bmeng.cn@gmail.com \
--to=bmeng.cn@gmail.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox