Question About Linux Memory Mapping

Question About Linux Memory Mapping

[Drasko DRASKOVIC]

Hi all,
in the article Booting ARM Linux :
http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
I can see that mem map is passed via ATAG_MEM. However, in the same
article it is mentioned that this information can also be passed via
kernel command line paramters,  mem=<size>[KM][,@<phys_offset>].

However, this does not seem to be true, as "mem" command line
parameter seems to be formated like this : mem= n[KMG] (i.e. no
offset), regarding to this reference :
http://oreilly.com/linux/excerpts/9780596100797/kernel-boot-command-line-parameter-reference.html.
Seems like memmap should be used instead.

I tried passing the parameters like memmap= n[KMG]@start[KMG] but that
had no effect at all - still the same amount of System Ram was read
from ATAGS and presented in the system via /proc/iomem.

What I needed it to reserve 1MB region for one FIFO at the end of RAM
(or somewhere else)
and protect it from the kernel. I tried passing memmap=
n[KMG]$start[KMG], but that did not worn neither.

So my questions are following :
1) Why commandlines are ignored and ATAGS are given priority ?
2) What is the most elegant way to protect one region in RAM :
 a) By giving less memory with ATAGS_MEM and thus making protected
region invisible to Linux, lying to it that RAM is smaller
 b) By changing somehow linker script
 c) By changing some configuration variables (which ?)

Thanks for the answers and best regards,
Drasko

Question About Linux Memory Mapping

[Russell King - ARM Linux]

On Fri, Feb 18, 2011 at 09:56:28PM +0100, Drasko DRASKOVIC wrote:
> Hi all,
> in the article Booting ARM Linux :
> http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
> I can see that mem map is passed via ATAG_MEM. However, in the same
> article it is mentioned that this information can also be passed via
> kernel command line paramters,  mem=<size>[KM][,@<phys_offset>].

Why do you discard this information soo lightly?  Did you try it?

> However, this does not seem to be true, as "mem" command line
> parameter seems to be formated like this : mem= n[KMG] (i.e. no
> offset), regarding to this reference :
> http://oreilly.com/linux/excerpts/9780596100797/kernel-boot-command-line-parameter-reference.html.
> Seems like memmap should be used instead.

Maybe O'Reilly is outdated?

Question About Linux Memory Mapping

[Nicolas Pitre]

On Fri, 18 Feb 2011, Drasko DRASKOVIC wrote:

> Hi all,
> in the article Booting ARM Linux :
> http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
> I can see that mem map is passed via ATAG_MEM. However, in the same
> article it is mentioned that this information can also be passed via
> kernel command line paramters,  mem=<size>[KM][,@<phys_offset>].
> 
> However, this does not seem to be true, as "mem" command line
> parameter seems to be formated like this : mem= n[KMG] (i.e. no
> offset), regarding to this reference :
> http://oreilly.com/linux/excerpts/9780596100797/kernel-boot-command-line-parameter-reference.html.
> Seems like memmap should be used instead.

I invite you to have a look at the code in arch/arm/kernel/setup.c 
especially the line that reads as:

early_param("mem", early_mem);

and also the function just above it.

Remember that the code is always the ultimate documentation.
It is open, you have it, so use it !

> So my questions are following :
> 1) Why commandlines are ignored and ATAGS are given priority ?

Probably because your command line didn't make it through to the kernel.

> 2) What is the most elegant way to protect one region in RAM :
>  a) By giving less memory with ATAGS_MEM and thus making protected
> region invisible to Linux, lying to it that RAM is smaller

That's the most common method at the moment.

>  b) By changing somehow linker script

The linker script has no impact on the available RAM.  This is not a 
deep embedded environment.

>  c) By changing some configuration variables (which ?)

That is also possible along with the kernel cmdline, and the answer is 
also in that arch/arm/kernel/setup.c source file.

Good luck!


Nicolas

Question About Linux Memory Mapping

[Marek Vasut]

On Friday 18 February 2011 21:56:28 Drasko DRASKOVIC wrote:
> Hi all,
> in the article Booting ARM Linux :
> http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
> I can see that mem map is passed via ATAG_MEM. However, in the same
> article it is mentioned that this information can also be passed via
> kernel command line paramters,  mem=<size>[KM][,@<phys_offset>].
> 
> However, this does not seem to be true, as "mem" command line
> parameter seems to be formated like this : mem= n[KMG] (i.e. no
> offset), regarding to this reference :
> http://oreilly.com/linux/excerpts/9780596100797/kernel-boot-command-line-pa
> rameter-reference.html. Seems like memmap should be used instead.
> 
> I tried passing the parameters like memmap= n[KMG]@start[KMG] but that
> had no effect at all - still the same amount of System Ram was read
> from ATAGS and presented in the system via /proc/iomem.
> 
> What I needed it to reserve 1MB region for one FIFO at the end of RAM
> (or somewhere else)
> and protect it from the kernel. I tried passing memmap=
> n[KMG]$start[KMG], but that did not worn neither.

What are you exactly trying to achieve ? btw. if you really need to make a hole 
in RAM, you should reserve a bootmem node maybe?
> 
> So my questions are following :
> 1) Why commandlines are ignored and ATAGS are given priority ?
> 2) What is the most elegant way to protect one region in RAM :
>  a) By giving less memory with ATAGS_MEM and thus making protected
> region invisible to Linux, lying to it that RAM is smaller
>  b) By changing somehow linker script
>  c) By changing some configuration variables (which ?)
> 
> Thanks for the answers and best regards,
> Drasko
> 
> _______________________________________________
> linux-arm mailing list
> linux-arm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm

Question About Linux Memory Mapping

[hong zhang]

Drasko,

Command line can assign all physical memory or partial memory to kernel using one or few mem=. For example, if you have 1 GBytes memory with starting port at 0x80000000, and want to reserve 512M anywhere between 0x80000000 and 0xc0000000 saying at 0x90000000. Then command line should be
mem=256M at 0x80000000 mem=256M at 0xb0000000. At this format, kernel should not touch memory between 0x9000000 and 0xb0000000 and the memory can be used by other OS or firmware.

This is my understanding.

---henry

--- On Sat, 2/19/11, Marek Vasut <marek.vasut@gmail.com> wrote:

> From: Marek Vasut <marek.vasut@gmail.com>
> Subject: Re: Question About Linux Memory Mapping
> To: linux-arm at lists.infradead.org
> Cc: "Drasko DRASKOVIC" <drasko.draskovic@gmail.com>, linux-arm-kernel at lists.infradead.org
> Date: Saturday, February 19, 2011, 2:22 PM
> On Friday 18 February 2011 21:56:28
> Drasko DRASKOVIC wrote:
> > Hi all,
> > in the article Booting ARM Linux :
> > http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
> > I can see that mem map is passed via ATAG_MEM.
> However, in the same
> > article it is mentioned that this information can also
> be passed via
> > kernel command line paramters,?
> mem=<size>[KM][,@<phys_offset>].
> > 
> > However, this does not seem to be true, as "mem"
> command line
> > parameter seems to be formated like this : mem= n[KMG]
> (i.e. no
> > offset), regarding to this reference :
> > http://oreilly.com/linux/excerpts/9780596100797/kernel-boot-command-line-pa
> > rameter-reference.html. Seems like memmap should be
> used instead.
> > 
> > I tried passing the parameters like memmap=
> n[KMG]@start[KMG] but that
> > had no effect at all - still the same amount of System
> Ram was read
> > from ATAGS and presented in the system via
> /proc/iomem.
> > 
> > What I needed it to reserve 1MB region for one FIFO at
> the end of RAM
> > (or somewhere else)
> > and protect it from the kernel. I tried passing
> memmap=
> > n[KMG]$start[KMG], but that did not worn neither.
> 
> What are you exactly trying to achieve ? btw. if you really
> need to make a hole 
> in RAM, you should reserve a bootmem node maybe?
> > 
> > So my questions are following :
> > 1) Why commandlines are ignored and ATAGS are given
> priority ?
> > 2) What is the most elegant way to protect one region
> in RAM :
> >? a) By giving less memory with ATAGS_MEM and thus
> making protected
> > region invisible to Linux, lying to it that RAM is
> smaller
> >? b) By changing somehow linker script
> >? c) By changing some configuration variables
> (which ?)
> > 
> > Thanks for the answers and best regards,
> > Drasko
> > 
> > _______________________________________________
> > linux-arm mailing list
> > linux-arm at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm
> 
> _______________________________________________
> linux-arm mailing list
> linux-arm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm
> 


      

Question About Linux Memory Mapping

[Drasko DRASKOVIC]

Thanks for your answers.

I can see now that "mem" parameter is parsed in
arch/arm/kernel/setup.c, as Nicolas underlined. However, in my case
early_mem() is never called during the Linux boot.

Does anybody have an idea why ?

BR,
Drasko


On Mon, Feb 21, 2011 at 6:27 AM, hong zhang <henryzhang62@yahoo.com> wrote:
> Drasko,
>
> Command line can assign all physical memory or partial memory to kernel using one or few mem=. For example, if you have 1 GBytes memory with starting port at 0x80000000, and want to reserve 512M anywhere between 0x80000000 and 0xc0000000 saying at 0x90000000. Then command line should be
> mem=256M at 0x80000000 mem=256M at 0xb0000000. At this format, kernel should not touch memory between 0x9000000 and 0xb0000000 and the memory can be used by other OS or firmware.
>
> This is my understanding.
>
> ---henry
>
> --- On Sat, 2/19/11, Marek Vasut <marek.vasut@gmail.com> wrote:
>
>> From: Marek Vasut <marek.vasut@gmail.com>
>> Subject: Re: Question About Linux Memory Mapping
>> To: linux-arm at lists.infradead.org
>> Cc: "Drasko DRASKOVIC" <drasko.draskovic@gmail.com>, linux-arm-kernel at lists.infradead.org
>> Date: Saturday, February 19, 2011, 2:22 PM
>> On Friday 18 February 2011 21:56:28
>> Drasko DRASKOVIC wrote:
>> > Hi all,
>> > in the article Booting ARM Linux :
>> > http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
>> > I can see that mem map is passed via ATAG_MEM.
>> However, in the same
>> > article it is mentioned that this information can also
>> be passed via
>> > kernel command line paramters,
>> mem=<size>[KM][,@<phys_offset>].
>> >
>> > However, this does not seem to be true, as "mem"
>> command line
>> > parameter seems to be formated like this : mem= n[KMG]
>> (i.e. no
>> > offset), regarding to this reference :
>> > http://oreilly.com/linux/excerpts/9780596100797/kernel-boot-command-line-pa
>> > rameter-reference.html. Seems like memmap should be
>> used instead.
>> >
>> > I tried passing the parameters like memmap=
>> n[KMG]@start[KMG] but that
>> > had no effect at all - still the same amount of System
>> Ram was read
>> > from ATAGS and presented in the system via
>> /proc/iomem.
>> >
>> > What I needed it to reserve 1MB region for one FIFO at
>> the end of RAM
>> > (or somewhere else)
>> > and protect it from the kernel. I tried passing
>> memmap=
>> > n[KMG]$start[KMG], but that did not worn neither.
>>
>> What are you exactly trying to achieve ? btw. if you really
>> need to make a hole
>> in RAM, you should reserve a bootmem node maybe?
>> >
>> > So my questions are following :
>> > 1) Why commandlines are ignored and ATAGS are given
>> priority ?
>> > 2) What is the most elegant way to protect one region
>> in RAM :
>> >? a) By giving less memory with ATAGS_MEM and thus
>> making protected
>> > region invisible to Linux, lying to it that RAM is
>> smaller
>> >? b) By changing somehow linker script
>> >? c) By changing some configuration variables
>> (which ?)
>> >
>> > Thanks for the answers and best regards,
>> > Drasko
>> >
>> > _______________________________________________
>> > linux-arm mailing list
>> > linux-arm at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm
>>
>> _______________________________________________
>> linux-arm mailing list
>> linux-arm at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm
>>
>
>
>
>

Question About Linux Memory Mapping

[Russell King - ARM Linux]

On Mon, Feb 21, 2011 at 01:13:16PM +0100, Drasko DRASKOVIC wrote:
> Thanks for your answers.
> 
> I can see now that "mem" parameter is parsed in
> arch/arm/kernel/setup.c, as Nicolas underlined. However, in my case
> early_mem() is never called during the Linux boot.
> 
> Does anybody have an idea why ?

Maybe the command line setting is being ignored by your boot loader
and the one built-in to the kernel is being used?

Maybe your kernel is configured to ignore the command line supplied
by your boot loader?

Maybe you're setting it in the kernel build but not realising that
the boot loader passed one is being used instead?

If you provide the kernel configuration and the kernel boot messages
for the last kernel you tried, it may be possible to work out what's
going on.

Question About Linux Memory Mapping

[Drasko DRASKOVIC]

On Mon, Feb 21, 2011 at 2:13 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Feb 21, 2011 at 01:13:16PM +0100, Drasko DRASKOVIC wrote:
>> Thanks for your answers.
>>
>> I can see now that "mem" parameter is parsed in
>> arch/arm/kernel/setup.c, as Nicolas underlined. However, in my case
>> early_mem() is never called during the Linux boot.
>>
>> Does anybody have an idea why ?
>
> Maybe the command line setting is being ignored by your boot loader
> and the one built-in to the kernel is being used?
>
> Maybe your kernel is configured to ignore the command line supplied
> by your boot loader?
>
> Maybe you're setting it in the kernel build but not realising that
> the boot loader passed one is being used instead?

Turns out that I had badly formatted command line parameters. After
correcting this everything works fine.

Thanks again for the help.

BR,
Drasko