All of lore.kernel.org
 help / color / mirror / Atom feed
From: mpeg.blue@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM page tables
Date: Tue, 09 Dec 2014 23:59:22 +0100	[thread overview]
Message-ID: <54877ECA.6050501@free.fr> (raw)
In-Reply-To: <20141209172729.GK11285@n2100.arm.linux.org.uk>

Hello Russel,

On 09/12/2014 18:27, Russell King - ARM Linux wrote:
> On Tue, Dec 09, 2014 at 06:21:32PM +0100, Mason wrote:
>> On my SoC, we have two MMIO regions mapped at init:
>>
>>  {
>>   .virtual = (0xf0000000 + 0x00800000),
>>   .pfn =((unsigned long)((0x20000000) >> 12)),
>>   .length = 0x00200000,
>>   .type = 0,
>>  },
>>  {
>>   .virtual = (0xf0000000 +(0)),
>>   .pfn =((unsigned long)((0) >> 12)),
>>   .length = 0x00800000,
>>   .type = 0,
>>  },
>>
>> I dumped the L1 page table descriptors, expecting to find
>> entries for the MMIO regions:
>> (AFAICT, the page table starts at 0xc0007000)
> 
> No, it starts at 0xc0004000.

I should have suspected that I had the wrong start address. Thanks!
What's the name of the symbolic constant for that address?

The page table is allocated in pgd_alloc, right?
  new_pgd = __pgd_alloc();
#define __pgd_alloc()   (pgd_t *)__get_free_pages(GFP_KERNEL | __GFP_REPEAT, 2)

If that's the correct init code, how does it guarantee to always
return 0xc0004000?

>> col_1 = entry number (hex)
>> col_2 = entry value
>> col_3 = string for (desc & 3)
>>
>> 300 00011452 SECTION
>> 301 00111452 SECTION
>> 302 00211452 SECTION
>> 303 00311452 SECTION
>> 304 00411452 SECTION
>> 305 00511452 SECTION
>> 306 00611452 SECTION
>> 307 00711452 SECTION
>> 308 20011452 SECTION
>> 309 20111452 SECTION
>>
>> If I understand correctly, entry 308 means:
>> VIRTUAL ADDRESS 0x3080_0000 is mapped to PHYSICAL ADDRESS 0x2000_0000
>> (Is my reading correct?)
> 
> No.  If you're talking about 0x308 from an offset of 0x3000 into the
> page table, that's 0x308 * 1MB + 0xc0000000 = 0xf0800000.
> 
>> But we asked to map PA 0x2000_0000 to VA 0xf080_0000 in iotable_init,
>> so I'm confused...
> 
> So, with the right starting point, it works out correctly.

Indeed!

I am investigating this issue:

As I described, we map PA 0-8MB. But some code actually accesses
address 0xf0920000 (from kernel space) and I was expecting very
nasty things, like the equivalent of SIGSEGV in the kernel.
But nothing happens, no page fault, no BUG_ON, no panic, no
implosion... (Writes seem ignored, and reads always return 0)

I don't understand how it is possible to access unmapped virtual
addresses without the MMU throwing a fit... That's why I'm looking
at the page table.

Regards.

  reply	other threads:[~2014-12-09 22:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 17:21 ARM page tables Mason
2014-12-09 17:27 ` Russell King - ARM Linux
2014-12-09 22:59   ` Mason [this message]
2014-12-10  0:16     ` Russell King - ARM Linux
2014-12-10  9:41       ` Mason

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=54877ECA.6050501@free.fr \
    --to=mpeg.blue@free.fr \
    --cc=linux-arm-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.