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/
From: Gary Thomas <hidden> Date: 2001-01-04 03:14:04
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/
----- Original Message -----
From: Gary Thomas <redacted>
To: Rolf Liu <redacted>
Cc: <redacted>
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:
quoted
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
quoted
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/
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/
From: Dan Malek <hidden> Date: 2001-01-04 18:07:35
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/
From: Jerry Van Baren <hidden> Date: 2001-01-04 21:03:15
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)
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:
quoted
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/