Re: Reserving a fixed physical address page of RAM.

[Fawad Lateef]

On 11/30/06, Jon Ringle <JRingle@xxxxxxxxxxxx> wrote:
> Jon Ringle wrote:
> > Fawad Lateef wrote:
<snip>
> > > >
> > > > Index: linux/arch/arm/mm/init.c
> > > >
> > ===================================================================
> > > > --- linux.orig/arch/arm/mm/init.c       2006-11-30
> > > 11:03:00.000000000
> > > > -0500
> > > > +++ linux/arch/arm/mm/init.c    2006-11-30
> > 11:09:09.000000000 -0500
> > > > @@ -429,6 +429,10 @@
> > > >         unsigned long addr;
> > > >         void *vectors;
> > > >
> > > > +#ifdef CONFIG_MACH_VERTICAL_RSC4
> > > > +       reserve_bootmem (0x0ffff000, 0x1000); #endif
> > > > +
> > > >         /*
> > > >          * Allocate the vector page early.
> > > >          */
> > > >
> > > >
> > >
> > > I think you can do like this but can't say accurately
> > because I havn't
> > > worked on arm architecture and also you havn't mentioned your
> > > kernel-version or function (in file
> > > arch/arm/mm/init.c) which you are going to do call reserve_bootmem !
> >
> > Kernel version is 2.6.16.29 and the reserve_bootmem() call
> > above is at the top of the function devicemaps_init().
>
> Is there some way I can verify that the above works? I've tried the
> following to try to get info on the reservation:
>         # cat /proc/iomem
>         # cat /proc/meminfo
>         # cat /proc/slabinfo
>         # echo m > /proc/sysrq-trigger
>
> The only one that hints that this might have worked is the `echo m >
> /proc/sysrq-trigger` in that I see the reserved pages count one larger
> than using a kernel without this patch. Does this mean that the page I
> reserved won't get used by Linux for any purpose?

I havn't looked at " # echo m /proc/sysrq-trigger" till now but I am
almost sure that it will reserve/work because calling reserve_bootmem
internally sets the bit representing physical memory page (CMIIW).


--
Fawad Lateef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/