[Top] [All Lists]

Re: Setting the physical RAM map

To: David VomLehn <>
Subject: Re: Setting the physical RAM map
From: Adam Nielsen <>
Date: Tue, 01 Dec 2009 08:35:28 +1000
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv: Gecko/20090809 Thunderbird/ Mnenhy/
   Determined physical RAM map:
    memory: 00800000 @ 40250000 (usable)
    memory: 00040000 @ 9fc00000 (ROM data)
   Wasting 8407552 bytes for tracking 262736 unused pages

These are kernel messages, so you are getting into the kernel, but this
looks odd to me.  The MIPS processor needs memory mapped in the first
512 MiB to execute. This first 512 MiB will be mapped as cached memory
at virtual address 0x80000000 (known as kseg0) and as uncached memory at
virtual address 0x0a0000000 (known as kseg1). Perhaps you system is like
mine, where I have memory above 512 MiB aliased into the first 512 MiB
of physical space.

The second odd thing is the ROM data physical address. This is a good virtual
address but as a physical address it is not accessible by the MIPS processor
without mapping to with a TLB entry.

Are these supposed to be physical addresses? Maybe that's where I'm going wrong. I only know the virtual addresses from some experimentation, but I've got no idea how to find out the physical addresses.

The system won't accept the kernel unless its virtual load address is 0x40020000. If I use the 'sm' (show memory) command in the boot loader it tells me there is 16MB of RAM starting at 0x20000000 and 8MB starting at 0x21000000, so but if memory is supposed to start at 0x0 then those don't look like physical addresses either.

   TLB refill exception PC = 40024094 address = 7FFFF000

This is not too surprising since the kernel is executing at an address
must have a TLB entry to be accessible.

From my other experiments here, 0x40024094 is fine, the problem is that the kernel is trying to access the unmapped address at 0x7FFFF000 and I'm not sure why. It looks like an unusual address - is it trying to trigger an exception to test whether some exception handler has been installed correctly?

My guess, and since I don't have a lot of information this is a pretty
wild guess, is that you are actually running your kernel at 0x40020000,
and that the reason you can do this is that the bootloader has left the
TLBs in such a state that the first few pages are mapped. Then, when it
leaves the mapped area, it dies with the TLB refill exception.

Another possibility is that you actually start off at reasonable 0x8xxxxxxx
address, but then use a pointer that takes you off to 0x40024094.

I'm pretty sure execution starts at 0x40020000. With some testing code I have successfully written at 0x40040000 so it looks like that's where the boot loader has mapped a fair chunk of memory. 0x40024094 shouldn't be a problem, but 0x7FFFF000 probably would be.

One suggestion is to look at the code at 0x40024094 to see what it's doing.
Then, use a JTAG debugger or add printk() statements to see exactly what's

I think that's probably the best bet. Unfortunately figuring out where that address ends up in the C source is a little tricky for me, and I'm still a bit slow at reading MIPS assembly!

Thanks for your helpful reply.


<Prev in Thread] Current Thread [Next in Thread>