From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC][PATCH 17/19] arm cp15: setup mmu and enable dcache
Date: Fri, 30 Jul 2010 11:32:48 +0200 [thread overview]
Message-ID: <4C529C40.6090002@denx.de> (raw)
In-Reply-To: <4C529758.2020600@ge.com>
Hello Nick,
Nick Thompson wrote:
> On 29/07/10 11:45, Heiko Schocher wrote:
>> This has been tested on at91sam9263 and STN8815.
>> Again, I didn't check if it has bad effects
>> on non-arm926 cores.
>>
>> Initially I had a "done" bit to only set up page tables
>> at the beginning. However, since the aligmnent requirement
>> was for the whole object file, this extra integer tool 16kB
>> in BSS, so I chose to remove it.
>>
>> Also, note not all boards use PHYS_SDRAM, but it looks like
>> it's the most used name (more than CONFIG_SYS_DRAM_BASE for
>> example).
>>
>> rebased for full arm relocation from Heiko Schocher <hs@denx.de>
>>
>> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
>> ---
>> arch/arm/lib/cache-cp15.c | 38 ++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 38 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
>> index 62ed54f..11e64d8 100644
>> --- a/arch/arm/lib/cache-cp15.c
>> +++ b/arch/arm/lib/cache-cp15.c
>> @@ -32,6 +32,36 @@ static void cp_delay (void)
>> /* copro seems to need some delay between reading and writing */
>> for (i = 0; i < 100; i++)
>> nop();
>> + asm volatile("" : : : "memory");
>> +}
>> +
>> +/* to activate the MMU we need to set up virtual memory: use 1M areas in bss */
>> +static inline void mmu_setup(void)
>> +{
>> + static u32 __attribute__((aligned(16384))) page_table[4096];
>> + int i;
>> + u32 reg;
>> +
>> + /* Set up an identity-mapping for all 4GB, rw for everyone */
>> + for (i = 0; i < 4096; i++)
>> + page_table[i] = i << 20 | (3 << 10) | 0x12;
>> + /* Then, enable cacheable and bufferable for RAM only */
>> + for (i = PHYS_SDRAM >> 20;
>> + i < ( PHYS_SDRAM + PHYS_SDRAM_SIZE) >> 20;
>
> As you noted, not all boards define these two symbols. I don't see where you
> have added them in the config.h files. You do seem to have created a new
> symbol CONFIG_SYS_SDRAM_BASE which you could use, but you would still need
> a CONFIG_SYS_SDRAM_SIZE wouldn't you?
Ah, you are right. Here we should use CONFIG_SYS_SDRAM_BASE,
as I introduced this define as a "must be defined" in this
patch series (and to be in sync for example with powerpc).
The size of ram should be in gd->ram_size ... or better for
arm architecture, we should use here the ram info in bd_t.
something like this:
for (j = 0 < CONFIG_NR_DRAM_BANKS; j++) {
for (i = bd->bi_dram[0].start >> 20;
i < ( bd->bi_dram[0].start + bd->bi_dram[0].size) >> 20;
i++) {
I fix this issue in v2, if nobody else objects.
>> + i++) {
>> + page_table[i] = i << 20 | (3 << 10) | 0x1e;
>
> These numbers ought to be defines, no?
>
> The 0x1e will not work on da8xx as the data cache is broken. The d-cache can
> still be used in write back mode, so the value 0x1a should be used. It would
> be good to have symbols to define the caching modes: none, wr-thru', wr-back
> or some such, similar to Linux.
Ah, Ok, good hint!
What with:
if !defined(CONFIG_SYS_ARM_CACHE_SETUP)
#define CONFIG_SYS_ARM_CACHE_SETUP 0x1e
#endif
page_table[i] = i << 20 | (3 << 10) | CONFIG_SYS_ARM_CACHE_SETUP;
So boards/architectures can define there own values?
>> + }
>> + /* Copy the page table address to cp15 */
>> + asm volatile("mcr p15, 0, %0, c2, c0, 0"
>> + : : "r" (page_table) : "memory");
>> + /* Set the access control to all-supervisor */
>> + asm volatile("mcr p15, 0, %0, c3, c0, 0"
>> + : : "r" (~0));
>> + /* and enable the mmu */
>> + reg = get_cr(); /* get control reg. */
>> + cp_delay();
>> + set_cr(reg | CR_M);
>> +
>> }
>
> I have previously tested this patch on da830 and it works fine, bar the two
> issues above.
Thanks!
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2010-07-30 9:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-29 10:45 [U-Boot] [RFC][PATCH 17/19] arm cp15: setup mmu and enable dcache Heiko Schocher
2010-07-30 9:11 ` Nick Thompson
2010-07-30 9:31 ` Alessandro Rubini
2010-07-30 9:32 ` Heiko Schocher [this message]
2010-07-30 9:57 ` Nick Thompson
2010-07-30 10:13 ` Heiko Schocher
2010-08-03 10:16 ` [U-Boot] [RFC][PATCH v2 " Heiko Schocher
2010-08-05 18:22 ` Ben Gardiner
2010-08-06 5:29 ` Heiko Schocher
2010-08-06 15:41 ` Ben Gardiner
2010-08-06 15:46 ` Wolfgang Denk
2010-08-06 16:14 ` Ben Gardiner
2010-08-06 16:27 ` Reinhard Meyer
2010-08-06 16:32 ` Reinhard Meyer
2010-08-06 16:44 ` Ben Gardiner
2010-08-10 17:45 ` Ben Gardiner
2010-08-11 5:56 ` Heiko Schocher
2010-08-11 13:31 ` Ben Gardiner
2010-08-11 13:53 ` Ben Gardiner
2010-08-11 17:06 ` Heiko Schocher
2010-08-11 19:56 ` Wolfgang Denk
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=4C529C40.6090002@denx.de \
--to=hs@denx.de \
--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