Boot time memory allocation

Boot time memory allocation

[Alex Gonzalez]

Hi,

I have two independent processors with access to a shared memory
region, mapped in the 256MB to 512MB region (kseg0).

One is running a propietary OS, and the second one is running Linux 2.6.12.

How would I arrange to leave that shared memory region out of the
scope of Linux's memory management system, but at the same time make
it possible for a driver to access it?

I have done similar things before with the help of alloc_bootmem, but
this time I don't want the kernel to reserve the memory, I want the
kernel to be completely unaware of it, and I need to specify its start
and end.

Any idea very much welcomed, thanks
Alex

Re: Boot time memory allocation

[Ralf Baechle]

On Tue, May 09, 2006 at 03:35:14PM +0100, Alex Gonzalez wrote:

> I have two independent processors with access to a shared memory
> region, mapped in the 256MB to 512MB region (kseg0).
> 
> One is running a propietary OS, and the second one is running Linux 2.6.12.
> 
> How would I arrange to leave that shared memory region out of the
> scope of Linux's memory management system, but at the same time make
> it possible for a driver to access it?
> 
> I have done similar things before with the help of alloc_bootmem, but
> this time I don't want the kernel to reserve the memory, I want the
> kernel to be completely unaware of it, and I need to specify its start
> and end.

At kernel initialization time just don't tell the kernel about the
existence of your memory region.  For many systems that just means you
shrink the memory region passed to the add_memory_region() call to
something that suits your platform.

  Ralf

Re: Boot time memory allocation

[Mark.Zhan]

Ralf Baechle wrote:
> On Tue, May 09, 2006 at 03:35:14PM +0100, Alex Gonzalez wrote:
> 
>> I have two independent processors with access to a shared memory
>> region, mapped in the 256MB to 512MB region (kseg0).
>>
>> One is running a propietary OS, and the second one is running Linux 2.6.12.
>>
>> How would I arrange to leave that shared memory region out of the
>> scope of Linux's memory management system, but at the same time make
>> it possible for a driver to access it?
>>
>> I have done similar things before with the help of alloc_bootmem, but
>> this time I don't want the kernel to reserve the memory, I want the
>> kernel to be completely unaware of it, and I need to specify its start
>> and end.
> 
> At kernel initialization time just don't tell the kernel about the
> existence of your memory region.  For many systems that just means you
> shrink the memory region passed to the add_memory_region() call to
> something that suits your platform.
> 
>   Ralf
> 

Maybe it is a more flexible way to specify the memory regions via 
command line. You know, this will produce User-defined memory regions to 
kernel.

Re: Boot time memory allocation

[Alex Gonzalez]

Thanks for the answers.

I wrongly assumed I wouldn't be able to access unspecified memory
regions, or that I'd have to tweak it somehow.

Regards,
Alex

On 5/10/06, Mark.Zhan <rongkai.zhan@windriver.com> wrote:
> Ralf Baechle wrote:
> > On Tue, May 09, 2006 at 03:35:14PM +0100, Alex Gonzalez wrote:
> >
> >> I have two independent processors with access to a shared memory
> >> region, mapped in the 256MB to 512MB region (kseg0).
> >>
> >> One is running a propietary OS, and the second one is running Linux 2.6.12.
> >>
> >> How would I arrange to leave that shared memory region out of the
> >> scope of Linux's memory management system, but at the same time make
> >> it possible for a driver to access it?
> >>
> >> I have done similar things before with the help of alloc_bootmem, but
> >> this time I don't want the kernel to reserve the memory, I want the
> >> kernel to be completely unaware of it, and I need to specify its start
> >> and end.
> >
> > At kernel initialization time just don't tell the kernel about the
> > existence of your memory region.  For many systems that just means you
> > shrink the memory region passed to the add_memory_region() call to
> > something that suits your platform.
> >
> >   Ralf
> >
>
> Maybe it is a more flexible way to specify the memory regions via
> command line. You know, this will produce User-defined memory regions to
> kernel.
>

SOAP

[Ratin]

Is there an implementation of SOAP (Simple Object Access Protocol) for 
linux-mips?

Ratin 

SOAP

[Ratin]

Is there an implementation of SOAP (Simple Object Access Protocol) for 
linux-mips?

Ratin 

Re: SOAP

[Leon Zhang]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

AFAIK, it is machine independence. You should search it in freshmeat.net or
sourceforge.net.



2006/5/12, Ratin <mrahman@sypixx.com>:
>
> Is there an implementation of SOAP (Simple Object Access Protocol) for
> linux-mips?
>
> Ratin
>
>
>

[-- Attachment #2: Type: text/html, Size: 570 bytes --]

Re: SOAP

[Ralf Roesch]

we have successfully used gSOAP since years now on a mips based embedded
target runing linux from mips-org.
Further related information about the gSOAP project you can find at
http://www.cs.fsu.edu/~engelen/soap.html

Ralf

Roesch & Walter___________________________________________
Industrie-Elektronik GmbH * Tel.: +49-7824 / 6628-0
Im Heidenwinkel 5         * Fax:  +49-7824 / 6628-29
D-77963 Schwanau          * mailto:ralf.roesch@rw-gmbh.de
Germany                   * WWW: http://www.rw-gmbh.de




Ratin wrote:
> Is there an implementation of SOAP (Simple Object Access Protocol) for
> linux-mips?
>
> Ratin
>

Re: Boot time memory allocation

[Ralf Baechle]

On Wed, May 10, 2006 at 10:21:03AM +0800, Mark.Zhan wrote:

> >At kernel initialization time just don't tell the kernel about the
> >existence of your memory region.  For many systems that just means you
> >shrink the memory region passed to the add_memory_region() call to
> >something that suits your platform.

> Maybe it is a more flexible way to specify the memory regions via 
> command line. You know, this will produce User-defined memory regions to 
> kernel.

Maybe for a specific application or platform.  For a sourcebase like
linux-mips.org's with a very large number of users on sometimes very
complex platforms I'd never ever think of exposing such details.

  Ralf