mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: barebox@lists.infradead.org
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Subject: [RFC] ARM: mmu: Do not try to pick early TTB up
Date: Tue, 22 May 2018 22:10:12 -0700	[thread overview]
Message-ID: <20180523051012.26148-1-andrew.smirnov@gmail.com> (raw)

The call to create_flat_mapping() in mmu.c will change both memory
type and shareability of all RAM in use by barebox while MMU is on
when done in conjunction with CONFIG_MMU_EARLY. According to "ARM
Reference Manual. ARMv7-A and ARMv7-R edition", this warrants the use
of "break-before-make" algorithm for TTB entries replacement,
nontheless original code seemed to work well without any hint of a
problem in the case of running from DRAM.

Running it on VF610, when executing from SRAM (uploaded via JTAG),
however proved to be problematic, with the following patch:

-------------------- 8< -------------------------------------------

diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c
index aa1a7c09c..650e20828 100644
--- a/arch/arm/cpu/mmu.c
+++ b/arch/arm/cpu/mmu.c
@@ -419,6 +419,11 @@ static void vectors_init(void)
 	create_vector_table(ARM_LOW_VECTORS);
 }

+static void dump_bank(struct memory_bank *b)
+{
+	pr_crit("0x%08lx - 0x%08lx\n", b->start, b->start + b->size - 1);
+}
+
 /*
  * Prepare MMU for usage enable it.
  */
@@ -494,6 +499,7 @@ static int mmu_init(void)
 	 * below
 	 */
 	for_each_memory_bank(bank) {
+		dump_bank(bank);
 		create_sections(ttb, bank->start, bank->size,
 				PMD_SECT_DEF_CACHED);
 		__mmu_cache_flush();
@@ -501,6 +507,10 @@ static int mmu_init(void)

 	__mmu_cache_on();

+	pr_info("%s %d\n", __func__, __LINE__);
+	for_each_memory_bank(bank)
+		dump_bank(bank);
+
 	return 0;
 }
 mmu_initcall(mmu_init);

-------------------- >8 -------------------------------------------

when applied, produces the following output on Zii VF610 Dev board:

-------------------- 8< -------------------------------------------

barebox 2018.04.0-00195-ge7ba82254-dirty #552 Thu Apr 19 11:32:56 PDT 2018

Board: VF610 OCRAM
i.MX clk 9: register failed with -22
i.MX clk 10: register failed with -22
i.MX clk 160: register failed with -22
mmu: Critical Error: Can't request SDRAM region for ttb at 3f078000
mmu: 0x80000000 - 0x9fffffff
mmu: 0x80000000 - 0x9fffffff
mmu: mmu_init 510
unable to handle NULL pointer dereference at address 0x00000000
pc : [<3f01b7da>]    lr : [<3f01b7d1>]
sp : 3f07ff38  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 3f000009  r8 : 00000c0e
r7 : 3f0258aa  r6 : 3f0258aa  r5 : 3f413b80  r4 : 00000000
r3 : 3f02f1b4  r2 : b0000000  r1 : 0000000a  r0 : 00000012
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
[<3f01b7da>] (mmu_init+0xce/0x168) from [<3f000b9d>] (start_barebox+0x45/0x98)
[<3f000b9d>] (start_barebox+0x45/0x98) from [<3f01bb19>] (barebox_non_pbl_start+0x95/0xd4)
[<3f01bb19>] (barebox_non_pbl_start+0x95/0xd4) from [<3f01bb71>] (barebox_arm_entry+0x19/0x1c)

[<3f01d085>] (unwind_backtrace+0x1/0x58) from [<3f000e45>] (panic+0x1d/0x2c)
[<3f000e45>] (panic+0x1d/0x2c) from [<3f01b5d1>] (do_exception+0xd/0x10)
[<3f01b5d1>] (do_exception+0xd/0x10) from [<3f01b631>] (do_data_abort+0x21/0x2c)
[<3f01b631>] (do_data_abort+0x21/0x2c) from [<3f01b3d4>] (do_abort_6+0x48/0x54)
\### ERROR ### Please RESET the board ###

-------------------- 8< -------------------------------------------

every boot. Compared to regular output (no-MMU build):

barebox 2018.04.0-00195-ge7ba82254-dirty #553 Thu Apr 19 12:03:17 PDT 2018

Board: VF610 OCRAM
i.MX clk 9: register failed with -22
i.MX clk 10: register failed with -22
i.MX clk 160: register failed with -22
mmu: 0x80000000 - 0x9fffffff
mmu: mmu_init 493
mmu: 0x80000000 - 0x9fffffff
Error: Cannot request SDRAM region for stack
Warning: Using dummy clocksource
malloc space: 0x3f400000 -> 0x3f47ffff (size 512 KiB)
environment load /dev/env0: No such file or directory
Maybe you have to create the partition.
running /env/bin/init...

Hit any key to stop autoboot:    3
barebox@VF610 OCRAM:/

-------------------- >8 -------------------------------------------

Note that, in the first listing, buggy execution starts from "mmu:
0x80000000 - 0x9fffffff mmu: 0x80000000 - 0x9fffffff" is printed
twice. Compiling with CONFIG_MMU_EARLY=n make the issue go
aways. The following patch:

-------------------- 8< -------------------------------------------

@@ -479,6 +479,7 @@ static int mmu_init(void)

 	create_flat_mapping(ttb);
 	__mmu_cache_flush();
+	tlb_invalidate();

 	vectors_init();

-------------------- >8 -------------------------------------------

seem to fix the issue as well. This patch however, opts to implement a
third solution and converts the code to disable MMU as a first step,
because it seems to be a safer approach and it also allows us to drop
a lot of extra code needed for error handling.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---

Sascha:

The precise mechanics of this failure are not 100% clear to me and
both solutions to this problem were discovered through trial and
error.

I am more than happy to run more experiments to diagnose this issue if
anyone has any suggestinons.

Feedback is wellcome!

Thanks,
Andrey Smirnov

 arch/arm/cpu/mmu.c | 27 +++++----------------------
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c
index a89f420f2..bb25f6b4f 100644
--- a/arch/arm/cpu/mmu.c
+++ b/arch/arm/cpu/mmu.c
@@ -450,36 +450,20 @@ static int mmu_init(void)
 
 	if (get_cr() & CR_M) {
 		/*
-		 * Early MMU code has already enabled the MMU. We assume a
-		 * flat 1:1 section mapping in this case.
+		 * Early MMU code has already enabled the MMU. To
+		 * start form a clean slate we need to disable it
+		 * first.
 		 */
-		asm volatile ("mrc  p15,0,%0,c2,c0,0" : "=r"(ttb));
-
-		/* Clear unpredictable bits [13:0] */
-		ttb = (uint32_t *)((unsigned long)ttb & ~0x3fff);
-
-		if (!request_sdram_region("ttb", (unsigned long)ttb, SZ_16K))
-			/*
-			 * This can mean that:
-			 * - the early MMU code has put the ttb into a place
-			 *   which we don't have inside our available memory
-			 * - Somebody else has occupied the ttb region which means
-			 *   the ttb will get corrupted.
-			 */
-			pr_crit("Critical Error: Can't request SDRAM region for ttb at %p\n",
-					ttb);
-	} else {
-		ttb = xmemalign(ARM_TTB_SIZE, ARM_TTB_SIZE);
+		mmu_disable();
 	}
 
+	ttb = xmemalign(ARM_TTB_SIZE, ARM_TTB_SIZE);
 	pr_debug("ttb: 0x%p\n", ttb);
 
 	set_ttbr(ttb);
 	set_domain(DOMAIN_MANAGER);
 
 	create_flat_mapping(ttb);
-	__mmu_cache_flush();
-
 	vectors_init();
 
 	/*
@@ -490,7 +474,6 @@ static int mmu_init(void)
 	for_each_memory_bank(bank) {
 		create_sections(ttb, bank->start, bank->start + bank->size - 1,
 				PMD_SECT_DEF_CACHED);
-		__mmu_cache_flush();
 	}
 
 	__mmu_cache_on();
-- 
2.17.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

             reply	other threads:[~2018-05-23  5:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-23  5:10 Andrey Smirnov [this message]
2018-05-23  8:43 ` Sascha Hauer
2018-05-25  3:14   ` Andrey Smirnov
2018-05-25  9:01     ` Sascha Hauer
2018-05-25  9:09       ` Lucas Stach
2018-05-25 17:07         ` Andrey Smirnov
2018-05-25 17:09       ` Andrey Smirnov
2018-05-25 17:35         ` Sam Ravnborg
2018-05-28 12:05         ` Sascha Hauer
2018-05-28 18:08           ` Andrey Smirnov

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=20180523051012.26148-1-andrew.smirnov@gmail.com \
    --to=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    /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