public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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


  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