separate kernel as code segment and data segment for linux ppc ?

separate kernel as code segment and data segment for linux ppc ?

[Rolf Liu]

Hi,all,
I am planning to run linux-ppc on ppc823 FADS board.
As all know, the kernel is resided in flash rom, then upon power-on, kernel
is copied to RAM.
I wonder if I can just put data segment to ram and leave code segment to
FLASH, just as uClinux
has done. such method will save some ram space, which makes sense on
embedded solutions.
Can you give me a hint how to realize it ?
Any suggestion is appreciated !

BRs
Rolf Liu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

RE: separate kernel as code segment and data segment for linux p

[Gary Thomas]

On 04-Jan-2001 Rolf Liu wrote:
>
> Hi,all,
> I am planning to run linux-ppc on ppc823 FADS board.
> As all know, the kernel is resided in flash rom, then upon power-on, kernel
> is copied to RAM.
> I wonder if I can just put data segment to ram and leave code segment to
> FLASH, just as uClinux
> has done. such method will save some ram space, which makes sense on
> embedded solutions.
> Can you give me a hint how to realize it ?
> Any suggestion is appreciated !

This method is called XIP (for execute in place) and is available on
some other architectures.  I don't know what it would take for the PPC,
but you could look at the work done on the Hitachi SH - I know it's supported
there.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: separate kernel as code segment and data segment for linux p

[Rolf Liu]

----- Original Message -----
From: Gary Thomas <gthomas@redhat.com>
To: Rolf Liu <rolfl@sc.mcel.mot.com>
Cc: <linuxppc-dev@lists.linuxppc.org>
Sent: Thursday, January 04, 2001 11:14 AM
Subject: RE: separate kernel as code segment and data segment for linux p


>
> On 04-Jan-2001 Rolf Liu wrote:
> >
> > Hi,all,
> > I am planning to run linux-ppc on ppc823 FADS board.
> > As all know, the kernel is resided in flash rom, then upon power-on,
kernel
> > is copied to RAM.
> > I wonder if I can just put data segment to ram and leave code segment to
> > FLASH, just as uClinux
> > has done. such method will save some ram space, which makes sense on
> > embedded solutions.
> > Can you give me a hint how to realize it ?
> > Any suggestion is appreciated !
>
> This method is called XIP (for execute in place) and is available on
> some other architectures.  I don't know what it would take for the PPC,
> but you could look at the work done on the Hitachi SH - I know it's
supported
> there.
Thanks a lot !
but where can I find the work about "Hitachi SH - " ?
Is there some data accessable through www ?
Best Regards


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Critical section - pSOS+

[Srinivas Rao.M]

Hi to all,

 I am sorry, This question is not releated to the list directly.

 We have a custom board built using MPC860 processor and running the
pSOS+ kernel. We are running a multitasking application on this. we are
facing a problem with the critical section.
we have in pSOS+, splx(1) and splx(0) calls for disabling and enabling the
interrupts respectively. Having multiple tasks running on the kernel,
suppose if one task disables the interrupt by calling splx(1),
The other task can enable the interrupts back to the old posture by
calling splx(0). Hence the critical section code is left in the non
critical section area. Unlike UNIX, pSOS+ doesnot provide, the interrupts
locking (and unlocking) mechanism at the task level.
In such contexts how can we solve this problem.

Thanks in advance.
Srini...

--

The beginning of knowledge is the discovery of something we do not understand.
-Frank Herbert
(contributed by Chris Johnston)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Critical section - pSOS+

[Jerry Van Baren]

I forgot if splx() returns the current value of the interrupt enable
bit.  If it doesn't, modify it to do so.  If I recall correctly, the
routine is in the BSP (been a little while since I messed with PPC
pSOS).  If I recall wrongly, you may need to write your own version of
splx(), naming it something else to avoid name collisions, and use it
instead of the provided splx().

Once your splx() routine returns the current value of the EE flag, save
it in a variable, and restore the value when you exit your critical region.

Something like...

void foo()
{
     int ee;

     ee = splix(1);      /* mask interrupts */
     bar()
     splx(ee);           /* restore the interrupt level */
}

gvb


At 09:37 AM 1/4/01 +0530, Srinivas Rao.M wrote:

>Hi to all,
>
>  I am sorry, This question is not releated to the list directly.
>
>  We have a custom board built using MPC860 processor and running the
>pSOS+ kernel. We are running a multitasking application on this. we are
>facing a problem with the critical section.
>we have in pSOS+, splx(1) and splx(0) calls for disabling and enabling the
>interrupts respectively. Having multiple tasks running on the kernel,
>suppose if one task disables the interrupt by calling splx(1),
>The other task can enable the interrupts back to the old posture by
>calling splx(0). Hence the critical section code is left in the non
>critical section area. Unlike UNIX, pSOS+ doesnot provide, the interrupts
>locking (and unlocking) mechanism at the task level.
>In such contexts how can we solve this problem.
>
>Thanks in advance.
>Srini...
>
>--
>
>The beginning of knowledge is the discovery of something we do not
>understand.
>-Frank Herbert
>(contributed by Chris Johnston)
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Critical section - pSOS+

[Srinivas Rao.M]

Hi Jerry,
Thanks for your reply.
   I have the splx() routine given from pSOS+, I am also having the
wrapper code which calls the psos 's system call to disable the
preemption of the task. I can do this successfully. But My problem is,
how can i implement the interrupts enabling/disabling mechanism at the
task level.

 Present mechanism has got a loophole: whenever we disable interrupts any
other task enables it. I want to have a mechanism, which is there UNIX.
something like splnet,splclock,splhigh,splimp,splx, at each task level.

any suggestions...
-Srini...



On Thu, 4 Jan 2001, Jerry Van Baren wrote:

>
> I forgot if splx() returns the current value of the interrupt enable
> bit.  If it doesn't, modify it to do so.  If I recall correctly, the
> routine is in the BSP (been a little while since I messed with PPC
> pSOS).  If I recall wrongly, you may need to write your own version of
> splx(), naming it something else to avoid name collisions, and use it
> instead of the provided splx().
>
> Once your splx() routine returns the current value of the EE flag, save
> it in a variable, and restore the value when you exit your critical region.
>
> Something like...
>
> void foo()
> {
>      int ee;
>
>      ee = splix(1);      /* mask interrupts */
>      bar()
>      splx(ee);           /* restore the interrupt level */
> }
>
> gvb
>
>
> At 09:37 AM 1/4/01 +0530, Srinivas Rao.M wrote:
>
> >Hi to all,
> >
> >  I am sorry, This question is not releated to the list directly.
> >
> >  We have a custom board built using MPC860 processor and running the
> >pSOS+ kernel. We are running a multitasking application on this. we are
> >facing a problem with the critical section.
> >we have in pSOS+, splx(1) and splx(0) calls for disabling and enabling the
> >interrupts respectively. Having multiple tasks running on the kernel,
> >suppose if one task disables the interrupt by calling splx(1),
> >The other task can enable the interrupts back to the old posture by
> >calling splx(0). Hence the critical section code is left in the non
> >critical section area. Unlike UNIX, pSOS+ doesnot provide, the interrupts
> >locking (and unlocking) mechanism at the task level.
> >In such contexts how can we solve this problem.
> >
> >Thanks in advance.
> >Srini...
> >
> >--
> >
> >The beginning of knowledge is the discovery of something we do not
> >understand.
> >-Frank Herbert
> >(contributed by Chris Johnston)
> >
>
>
>

--

There is one thing even more vital to science than intelligent methods; and
that is, the sincere desire to find out the truth, whatever it may be.
-Charles Sanders Pierce


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: separate kernel as code segment and data segment for linux p

[Dan Malek]

Gary Thomas wrote:

> This method is called XIP (for execute in place) and is available on
> some other architectures.  I don't know what it would take for the PPC,

We have it running on a couple of MPC8xx systems.  It requires some
careful memory mapping of the rom and the kernel, but almost no
code changes in the kernel.  Lots of hacking in the vmlinux.lds file :-).
It is only XIP for the kernel, not any applications.

One cool performance hack it allows on the MPC8xx is using a
dedicated 8M TLB entry to map the kernel text, so no TLB misses when
running in the kernel (although, no one should be running in the
kernel anyway :-).

I don't understand the cost tradeoff, but I have been told that in
high volume consumer products that can use a masked rom it is actually
less expensive than RAM.  You can also put lots of the filesystem
in there as well.  In one case it saved just enough ram that the
product didn't have to include the next larger increment.  Pennies
counted.

I have not yet found a way to make this build "automatically".  You
need some addressing knowledge prior to building the kernel, then
some "hand waving" magic you manually code into 'head.S', then you
can make vmlinux.  Once I am able to simply set some configuration
variables and 'make romxip', I'll check it into the mainstream
kernel sources.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: separate kernel as code segment and data segment for linux ppc ?

[Wolfgang Denk]

In message <017b01c075f0$15265b50$bf0102c8@sc.mcel.mot.com> you wrote:
>
> As all know, the kernel is resided in flash rom, then upon power-on, kernel
> is copied to RAM.
> I wonder if I can just put data segment to ram and leave code segment to
> FLASH, just as uClinux
> has done. such method will save some ram space, which makes sense on
> embedded solutions.

Does it really make sense? Flash is  more  expensive  than  RAM,  and
sometimes slower (especially if you have just a 8 or 16 bit wide boot
device). For all systems I've seen so far it was more efficient to be
able  to  store  a  compressed  image  in  flash, to reduce the flash
footprint on the expense of some RAM.

This has been discussed several times before on  this  mailing  list;
you might want to search the archives for all the other arguments pro
and contra.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                  - Wernher von Braun

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/