Re: memory consumed by kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dave,

Thanks for your reply.

On Tue, Sep 28, 2010 at 1:00 PM, Dave Hylands <dhylands@xxxxxxxxx> wrote:
> Hi Arun,
>
>>> I can definitely confirm that not all ARM processors start their RAM
>>> at physical address zero.
>>>
>>> If you have a kernel module (or you can rebuild your kernel to add a
>>> printk), you can have it print out the 4 bytes at virtual address
>>> 0xC0004000. The top 3 nibbles of this first word will be the top 3
>>> nibbles of the physical address of your first page of memory.
>>>
>>> So, something like:
>>>
>>> printk( "0x%08x\n", *(uint32_t *)0xc0004000 );
>>
>> I tried printing,
>>
>>  printk( "0x%08x\n", *(uint32_t *)0xc0004000 );
>>  printk("0x%08x\n", virt_to_phys(0xc0004000));
>>
>> Output:
>>  0x00000000
>>  0x13004000
>
> Ok - so this tells me that your SDRAM starts at 0x13000000
>
> I realized that printing 0xc0004000 corresponds to memory location zero.
>
> What we really wanted was the MMU entry which correponds to virtual
> address 0xc0000000. The high 3 nibbles is 0xc00, so we would have
> needed to do
>
>  printk( "0x%08x\n", *(uint32_t *)(0xc0004000 + ( 0xc00 * 4 ));
>
> and that should print
>
> 0x130xxxxx
>
>> So I initialized  the variable "i" in the kernel module to 0x13004000.
>> But still it is not entering the while loop.
>
> PFN's are equal to the physical address shifted right by 20.

Is this value 12?

>
> So the PFN for 0x13004000 would be 0x130 or 304 (base 10)

so PFN is 0x13004

Here is the output of the module when i is initialized to 0x13004.

<4>[ 1647.455344] 13004000 reserved: yes
<4>[ 1647.455373] 13008000 reserved: no
<4>[ 1647.455414] 1302c000 reserved: yes
<4>[ 1647.456213] 136b4000 reserved: no
<4>[ 1647.456241] 136b6000 reserved: yes
<4>[ 1647.456461] 1385a000 reserved: no
<4>[ 1647.457838] 143c5000 reserved: yes
<4>[ 1647.462746] 16bf2000 reserved: no
<4>[ 1647.462783] 16c00000 reserved: yes
<4>[ 1647.463083] 16e50000 reserved: no
<4>[ 1647.478204] 1ea0c000 reserved: yes
<4>[ 1647.478246] 1ea0f000 reserved: no
<4>[ 1647.478304] 1ea56000 reserved: yes
<4>[ 1647.478331] 1ea57000 reserved: no
<4>[ 1647.478391] 1eaa1000 reserved: yes
<4>[ 1647.478416] 1eaa2000 reserved: no
<4>[ 1647.478443] 1eaa3000 reserved: yes
<4>[ 1647.478468] 1eaa4000 reserved: no
<4>[ 1647.478499] 1eab0000 reserved: yes
<4>[ 1647.478529] 1eab9000 reserved: no
<4>[ 1647.480438] 1f9c0000 reserved: yes
<4>[ 1647.480471] 1f9c9000 reserved: no
<4>[ 1647.480591] 1fa94000 reserved: yes
<4>[ 1647.480618] 1fa95000 reserved: no
<4>[ 1647.480651] 1faa8000 reserved: yes
<4>[ 1647.480678] 1faa9000 reserved: no
<4>[ 1647.480756] 1fb1c000 reserved: yes
<4>[ 1647.480784] 1fb20000 reserved: no
<4>[ 1647.480826] 1fb46000 reserved: yes
<4>[ 1647.480853] 1fb47000 reserved: no
<4>[ 1647.480921] 1fba4000 reserved: yes
<4>[ 1647.480948] 1fba6000 reserved: no
<4>[ 1647.481391] 1ff28000 reserved: yes
<4>[ 1647.481418] 1ff2b000 reserved: no

Thanks for everyone. This helped me. :-)

Arun

>
>> Makefile.boot is saying
>>
>> zreladdr-y      := 0x13008000
>> params_phys-y      := 0x13000100
>
> This further confirms that physical memory starts at 0x13000000
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.DaveHylands.com/
>

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux